Excellent. Thank you, I will look forward to that.
I still haven't worked out how to isolate my VLAN from the IPv6 packets I am experiencing.
As I say, they appear to be being generated by 2 of the the routers interfaces even though IPv6 is disabled, and they are making their way onto the VLAN somehow.
These are multicast packets that do not come from the router itself but from a WLAN client with IPv6 enabled.
In my case I captured such a packet on eth1 and on the LAN interface of my PC, the source MAC clearly says the packet comes from a WLAN client / my FireTV.
Sorry but I still doubt that the packets are coming from the router.
If you disable ipv6 it will be disabled directly in the kernel so your ip6table attempts will not work because ipv6 is not supported.
Do the interfaces have an ipv6 address at all ? (ifconfig)
In your Wireshark dump you have the corresponding ipv6 addresses...
What you can try is to delete your bridge and set the VLAN interface to unbridged.
The MAC addresses can be some SNAT stuff, we still do not know how the router is configured ... station or station bridge?
In the GUI, IPv6 show's as disabled. So that's good to know that the ip6tables will not work, as I had been trying them with no effect.
I have nothing else turned on now that could possibly be causing those packets.
I am thinking of starting from scratch, and seeing if that rectifies the issue, as I could really do with a clean wire to the device I need to test that is running 10mbps (which I can currently achieve with a dumb hub that the router is happy to negotiate with), and without spurious traffic on it of whichever origins these are coming from.
By rights, on a VLAN with a different subnet, I sort of didn't expect to have these issues.
I completely understand the Sunday thing. I have to say I have just about had enough of it for today. I will have a look at your other comments later, and answer those. My eyes have gone a little square for now though.
Just a very quick one, I have removed the bridge, and set the VLAN to unbridged, and it's still happening, only I think from just the eth1 mac address now. I will leave it running and confirm that later.
There is nothing else plugged into the back of the router other than this one device.
I have just checked the router interfaces, and they all have IPv6 addresses, and the 2 addresses that the Router Solicitation is coming from match the IPv6 source addresses.
I will have a poke round and try and document things much better later on.
Then no idea, I still do not know how your router is configured, I tried very quickly different station modes ... with me definitely no ipv6 is loaded unless I enable it in the GUI...
Now you just have to find out why your ipv6 module is loaded...
Code:
ip6tables -S
ip6tables v1.8.5 (legacy): can't initialize ip6tables table `filter': Address family not supported by protocol
Perhaps ip6tables or your kernel needs to be upgraded.
With the bridge removed and vlan2 left unbridged (even though the bridge only contained VLAN2), and then turning off IPv6 on vlan2 using
Code:
sysctl -w net.ipv6.conf.vlan2.disable_ipv6=1
It appears all the packets have gone.
It occurs to me that DHCPd is running on the 2 interfaces that looked like they were causing the issue. One of those (vlan2) I have turned IPv6 off on, and the other seemed to get isolated by removing the bridge (which was connected to vlan2 and DHCP).
I will keep a close eye, but it looks like this may be enough for testing now.
Why this is, I am unsure as I have read up and see exactly what you mean, that the type 133 packet I am having trouble with must come from a device using the router. I just can't work out what unless by chance something has gone faulty on my laptop that I was using to set the tcpdump off with.
