Why am I seeing IPv6 packets?

hAX3 v.14beta6

/ipv6 settings
set disable-ipv6=yes

And yet I see the following while sniffing packets:

37  13.64   2point4     fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
38  13.64   Guest-2ghz  fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
39  13.64   ether2      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
40  13.64   ether4      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
41  13.64   ether5      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
42  13.64   ether3      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
43  13.64   bridge      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
51  16.67   2point4     fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
52  16.67   Guest-2ghz  fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
53  16.67   ether2      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
54  16.67   ether4      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
55  16.67   ether5      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
56  16.67   ether3      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
57  16.67   bridge      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
77  25.688  2point4     fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
78  25.688  Guest-2ghz  fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
79  25.688  ether2      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
80  25.688  ether4      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
81  25.688  ether5      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
82  25.688  ether3      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1
83  25.688  bridge      fe80::4661:32ff:fe2b:9fd4:5353  ff02::fb:5353        udp           116    1

Is it as simple as the sniffer is just reporting what it hears?

It seems to me that the router is processing these packets. That is, the packets are originating with a device connected to the SSID “2point4” and then broadcast/repeated/sent-out on interfaces Guest-2ghz, ether2, ether3, ether4, ether5, and bridge."

I come to this point because of my struggles with a single device (Ecobee thermostat) frequently (but at random intervals) disconnecting and then reconnecting from 2point4. I see these packets, as well as lots of ARP and ICMP packets from and to this device.

Thanks!

Using words already written by others on the forum:
You can prevent the router from generating or interpreting IPv6 packets,
but you cannot prevent devices connected to the router from exchanging any Internet protocol packets, even IPv6, with each other.

At most with rules on the router, completely disabling hardware acceleration, you block IPv6, but only what passes through the router.

With IPv6 disabled, I even added 2 drop firewalls (input and forwarding). But, as expected, that made no difference.

I don’t know anything about disabling hardware acceleration, but acceleration sounds like a good thing.

Is hardware acceleration the same as hardware offloading? Enabled with “fast forwarding” checked in /bridge? Basically making all ports/interfaces in the bridge behave as if it was on a switch?

I assume it’s a feature that takes packets and makes them available elsewhere (like on the same bridge?) without processing them – and thereby doesn’t care if they are v4 or 6 (or anything)?

But what do you care about IPv6 packets if they can’t go out on the Internet anyway?

The link local fe80:… addresses can’t be routed on Internet also if you have IPv6 enabled on router.

I tend to care about things I don’t understand – I’m working on fixing that :slight_smile:

I was trying to figure out the regular wifi disconnecting and saw these packets, so I got distracted – I’m working on that also :slight_smile:

So much to work on…

I don’t speak English, I mean, get over it, they don’t go out,
but investigate what traffic they’re doing, maybe some peripheral is compromised… :wink:

Google is your friend (sometime)…
https://en.wikipedia.org/wiki/Multicast_DNS

Now that I know (thanks to you) that the packets don’t go out, I can indeed get over it. Honestly, I could get over it even if they were going out, running up my credit card, coming back and leaving the place a mess, but that’s another story.

Thank you (as always)!

Following up on my wifi disconnect/disassociate problem, I am happy to report the problem was all because of my fingers:

Simultaneously with troubleshooting this wifi problem, I have been troubleshooting why my furnace is short cycling (runs for 10 minutes, stops for 2 minutes, starts again).

Luckily, I am data-addicted, so I collect the data showing the times of each of these, and of course the MT device knows when the ecobee disconnects/reconnects.

I overlayed the two and sure enough they correspond.

Seems the transformer that powers the ecobee was wired into the burner power, and, for reasons I do not understand, every 10 minutes there was an interruption in the power, causing the ecobee to reboot.

I just rewired it (you can see it on the graph from 8-9am) and it’s been running for an hour without interruptions – as has the Ecobee tstat.

.
Screenshot 2024-01-15 100239.png