XFCE for Raspi 3 - ICMPv6 chatter on bridge interface

Hi everybody!

General setup: 1x Raspberry Pi 3 wtih two additional USB-RJ45 adaptors, latest Tumbleweed XFCE with updates from yesterday, bridge-utils and Wireshark installed.

I bridge the two USB-RJ45 devices with the following:

ifconfig eth1 -arp promisc 0.0.0.0 up 
ifconfig eth2 -arp promisc 0.0.0.0 up 
brctl addbr br0 
brctl addif br0 eth1 
brctl addif br0 eth2 
ifconfig br0 -arp promisc 0.0.0.0 up

…and start Wireshark on the bridge interface. Normally there should be silence on the bridge, as long as no traffic is coming from the clients (on one USB-RJ45 interface: router interface, other USB-RJ45: Win10 PC without any power, i.e. power plug pulled).

However, on the USB-RJ45 connected to the totally dead I get:

1    0.000000000    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97

again, and again and again.

I tried Wicked (IPv6 disabled) -> same result

I tried NetworkManager (IPv6 “Ignored” on all three interfaces) -> same result

I disabled anything related to Avahi in Yast -> ServiceManager

Interestingly, when I use Tumbleweed JeOS with Enlightenment desktop on the same Raspi with the same USB-RJ45 interfaces, it’s totally silent.

Where to look next? What is sending out IPv6 ICMP?

What could I disable/uninstall to make the bridge silent?

Many thanks in advance.

Hi
The USB interface, I’m guessing the asix driver…


00:0E:C6 ASIX ELECTRONICS CORP.

The windows box has W.o.L active perhaps (check BIOS)?

How long did you observe/monitor on each of the two different desktops?

Hy!

I found in the meantime:

ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::20e:c6ff:fec6:6697  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 15  bytes 1050 (1.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
....

So the BRIDGE actually has “inherited” the IPv6 address of one of the members. How to change this?

I can set in NetworkManager IPv6 to “Ignored” for the bridge, but it doesn’t change anything in the output of ifconfig.

WOL might be active, but as I said, the machine is not plugged in to any power.

Observation periods:

With JeOS+Enlightenment: For hours and hours. → Nothing like that

With TW XFCE: for some hours now → ICMPv6 comes back again and again:

1    0.000000000    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
2    3.866352499    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
3    11.626367496    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
4    27.626359469    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
5    58.986364509    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
6    124.906360786    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
7    1189581.814170311    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97
...
15    1208157.103065335    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97

Hi
If you down/up the bridge does it disappear? IPv6 is disabled in /etc/sysctl.conf?


net.ipv6.conf.all.disable_ipv6 = 1

I have in /etc/sysctl.conf

####
#
# /etc/sysctl.conf is meant for local sysctl settings
#
# sysctl reads settings from the following locations:
#   /boot/sysctl.conf-<kernelversion>
#   /lib/sysctl.d/*.conf
#   /usr/lib/sysctl.d/*.conf
#   /usr/local/lib/sysctl.d/*.conf
#   /etc/sysctl.d/*.conf
#   /run/sysctl.d/*.conf
#   /etc/sysctl.conf
#
# To disable or override a distribution provided file just place a
# file with the same name in /etc/sysctl.d/
#
# See sysctl.conf(5), sysctl.d(5) and sysctl(8) for more information
#
####

net.ipv6.conf.all.disable_ipv6 = 1

I tried several reboots, every time the same again.

I just found on the br0 “Bridge” tab in the NetworkManager app that

"Enable IGMP snooping"

is checked. Is that of any relevance? But I want to get rid of the IPv6 adress for the bridge COMPLETELY.

How to do that? IPv6 is turned of everywhere, but comes up like a pest again and again…

… I tried on the Raspi 3 with TW JeOS and Enlightenment, set up the bridge as described above and get:

ifconfig
br0: flags=4483<UP,BROADCAST,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:f9:bd  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


So no IPv6 on the bridge here…

Hi
Some info here;
https://routerguide.net/enable-igmp-snooping-on-or-off/

Delete the bridge, swap adapters across different USB ports and create the bridge again, does it follow the device.

No ipv6 in the output from the arp command?

I switched to Wicked, set all three interfaces to IPv4 DHCP and rebooted. After establishing the bridge, the IPv6 was gone for the bridge in ifconfig

ifconfig
br0: flags=4483<UP,BROADCAST,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

, but after adding the patch cables, the IPv6 on bridge was back.

ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::20e:c6ff:fec6:6697  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 4  bytes 1030 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3  bytes 210 (210.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Unbelievable.

Added the **same cables **to the two USB-RJ45 on the TW JeOS + Enlightenment: No IPv6 comming up in ifconfig:

 ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:f9:bd  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Nope, with arp I only get info on IPv4, on both raspis…

Now with Wicked I get an IPv4 IP-address offered from my router for the MAC of one of the USB-RJ45’s in the bridge:

1    0.000000000    IntelCor_xx:yy:zz    Broadcast    ARP    60    Who has 192.168.123.2? Tell 192.168.123.1

2    1.029762187    192.168.123.1    192.168.123.2    DHCP    342    DHCP Offer    - Transaction ID 0xf9e6e74f
3    3.849994998    192.168.123.1    192.168.123.2    DHCP    342    DHCP Offer    - Transaction ID 0xf9e6e74f
...

I have seen something like that in Raspbian (light with XFCE desktop), but never before with any TW (raspi 2 or 3) I used in the past.

I found a difference between the TW XFCE and the TW JeOS+Enlight.

In TW XFCE the FIRST (eth1) member of the bridge is running and provides the MAC fro the bridge:

ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::20e:c6ff:fec6:6697  prefixlen 64  scopeid 0x20<link>
        **ether 00:0e:c6:c6:66:97**  txqueuelen 1000  (Ethernet)
        RX packets 28  bytes 8620 (8.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5  bytes 350 (350.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet ...

eth1: flags=4547<UP,BROADCAST,**RUNNING**,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 21  bytes 6606 (6.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 6920 (6.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4483<UP,BROADCAST,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:c6:68:ab  txqueuelen 1000  (Ethernet)
        RX packets 7  bytes 2014 (1.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 2446 (2.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

While in TW JeOS+ Enlight the SECOND (eth2) is Running, but the first member (eth1) provides the MAC:

 ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        **ether 00:0e:c6:cc:f9:bd**  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet ...

eth1: flags=4483<UP,BROADCAST,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:f9:bd  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4547<UP,BROADCAST,**RUNNING**,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:fc:b3  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Why are you even installing a bridge interface on your RPi?
Personally, I can’t think of a reason to do so.

And,
If you’re connecting both/all physical network devices to the same network, then you really <are> trying to do something, and doing it wrong.
(Unless I’m overlooking some good reason you can provide)

TSU

No, not the same network. I know what a bridge is and how to use it. Something on topic, maybe?

I’m still not sure of the implications of binding your two network adapters to the same bridge device…

In any case,
Nowhere do I see that you’ve verified the br0 configuration on your two images (JeOS/Enlightment vs XFCE)
For each, you should verify the configuration with the following(are they identical, or slightly different?)

brctl show

You may need to look more deeply into what I posted in another thread about the difference between a JeOS and a normal base subsystem… For one thing I remember that a multitude of common network tools are normally stripped out, and any one of them could be essential to IPv6 network discovery. If you were to install those network tools, it’s possible that would restore what you see in your XFCE. Or, if you really desire the reverse then you should stick to the JeOS image.

Remember,
The whole reason for a JeOS image is the philosophy that it’s a lot more work to remove unwanted stuff than to start with bare bones and add only what you want. For that reason, you should <expect> that some things won’t work by default in a JeOS image.

TSU

I found that bridge-utils on the TW with XFCE is:

1.6-1.7-aarch64

while on the TW JeOS+Enlight it is:

1.6-1.5-aarch64

Change log in YaSt provides no info on differences. Is there any way to test the older bridge utils in the TW XFCE? “Copy over” the package?

TW XFCE

sudo brctl show
[sudo] password for root: 
bridge name    bridge id        STP enabled    interfaces
br0        8000.000ec6c66697    no        eth1
                            eth2

TW JeOS+Enlight

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.000ec6ccf9bd       no              eth1
                                                        eth2

…the ifconfig output I posted above gives you much more info, i.e. which interface is “RUNNING” and which provides the MAC for the bridge, see post above.

Hi
That’s just a rebuild of the package, 1.6 is the version, revision is 1, the .N indicates a rebuild…maybe a build requires changed.
if it was 1.6-2.N then something changed in the package.

OK, so no difference in bridge-utils. To bad!

Any other hypothesis what might be the difference, resulting in the “running”/MAC difference obvious from ifconfig given above? :\

Not talking about bridge-utils,
Am talking about network tools, so for instance one package might include common tools like ping, traceroute.

But, that’s just one package.
There are probably more… I haven’t had reason to investigate deeper than to notice what was patently obvious.

TSU

Hi again!

Did a fresh install of TW JeOS with Enlightenment desktop, but again there is this IPv6 noise on the bridges interfaces when listening with Wireshark:

...148    575731.581049742    fe80::20e:c6ff:fec6:6697    ff02::2    ICMPv6    70    Router Solicitation from 00:0e:c6:c6:66:97...

I think it’s related to the IPv6 assigned to the bridge (which shouldn’t be there):

 ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        **inet6 fe80::20e:c6ff:fec6:6697**  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 185  bytes 12950 (12.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: ...

eth1: flags=4547<UP,BROADCAST,**RUNNING**,NOARP,PROMISC,MULTICAST>  mtu 1500
        inet6 fe80::20e:c6ff:fec6:6697  prefixlen 64  scopeid 0x20<link>
        ether 00:0e:c6:c6:66:97  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 367  bytes 27158 (26.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4483<UP,BROADCAST,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:c6:68:ab  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 20  bytes 1000 (1000.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1000 (1000.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

…as can been seen on the Raspi 3 without the IPv6 problem:

ifconfig
br0: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:f9:bd  txqueuelen 1000  (Ethernet)
        RX packets 6950390  bytes 4770259087 (4.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: ....

eth1: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:f9:bd  txqueuelen 1000  (Ethernet)
        RX packets 3234897  bytes 1424986525 (1.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3715493  bytes 3412151580 (3.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth2: flags=4547<UP,BROADCAST,RUNNING,NOARP,PROMISC,MULTICAST>  mtu 1500
        ether 00:0e:c6:cc:fc:b3  txqueuelen 1000  (Ethernet)
        RX packets 3715493  bytes 3345272562 (3.1 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3234834  bytes 1483211067 (1.3 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5484217  bytes 74612565129 (69.4 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5484217  bytes 74612565129 (69.4 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Slightly painful that only the TW JeOS image/install from last year is without this IPv6 nonsense, but there is no easy way to duplicate the functional SD-card…