2

I followed the steps to create a dynamic network failover from @Ingo (Dynamic failover setup on my Raspberry Pi 3 running on Debian Buster. I can see that under the bonding status, the currently active slave is my eth0 interface, but unless I down the wlan0 interface, the Pi still connect over wifi.

The bonding seems to work since when I down the eth0 instead, the currently active slave switch to wlan0, the issue being when both interfaces are up, it connects over wifi even if the bonding says that it is on eth0.

So far, I tried with either DHCP and Static IP with no luck in changing that behavior. Did I miss something to force the Pi to use the wired connection first?

Here is the output I have from cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: eth0 (primary_reselect always)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 500
Up Delay (ms): 1000
Down Delay (ms): 1000

Slave Interface: eth0
MII Status: up
Speed: 100 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: b8:27:eb:fa:af:1e
Slave queue ID: 0

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: b8:27:eb:af:fa:4b
Slave queue ID: 0

But even if it says that the Currently Active Slave is eth0, my router says that it is currently connected on WiFi. I have to down the wlan0 in order for it to connect to the eth0.

This is what I have running ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether ae:96:51:5a:10:17 brd ff:ff:ff:ff:ff:ff
3: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ae:96:51:5a:10:17 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.105/24 brd 192.168.0.255 scope global dynamic bond0
       valid_lft 6817sec preferred_lft 6817sec
    inet6 fe80::ac96:51ff:fe5a:1017/64 scope link
       valid_lft forever preferred_lft forever
4: wlan0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
    link/ether ae:96:51:5a:10:17 brd ff:ff:ff:ff:ff:ff

Thanks for your help!

  • 1
    Please edit your question and add the output of these commands to it: cat /proc/net/bonding/bond0 and ip addr. – Ingo Jan 15 at 9:20
  • 1
    I added the outputs requested in my question, let me know if anything else could help solving this! – Olivier Jan 17 at 19:08
2

According to the analyze output everything is working as expected. If possible both lines are always UP so they can be fast switched without interruption of the data stream if one fails. This is also shown by /proc/net/bonding/bond0: both Slave Interfaces eth0 and wlan0 have MII Status: up. Also ip addr shows that all interfaces have state UP. Of course this is also shown by your router: the WiFi interface is connected but it doesn't mean that it is used for data transfer. The primary slave is eth0 and is used for data as soon as it is available and it is primary reselected (Primary Slave: eth0 (primary_reselect always)).

You can verify it with tcpdump. If not available install it with sudo apt install tcpdump. Then in a console start a ping to whatever, e.g.

rpi ~$ /bin/ping 192.168.0.1   # if this ip address exists, mostly the router

Now in a second console check:

rp ~$ sudo tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
22:46:07.313065 IP 192.168.0.105 > 192.168.0.1: ICMP echo request, id 2236, seq 81, length 64
22:46:07.315362 IP 192.168.0.1 > 192.168.0.105: ICMP echo reply, id 2236, seq 81, length 64
22:46:08.314602 IP 192.168.0.105 > 192.168.0.1: ICMP echo request, id 2236, seq 82, length 64
22:46:08.317295 IP 192.168.0.1 > 192.168.0.105: ICMP echo reply, id 2236, seq 82, length 64
--- snip ---

rp ~$ sudo tcpdump -ni wlan0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

There is nothing. If you pull the ethernet cable then you will see the pings on wlan0 but not on eth0 of course. On interface bond0 you will always see them.

| improve this answer | |
  • Thanks a lot for your explanation, I guess the confusion came from the fact the router only saw that connection over wlan even when it was actually using lan. Testing it that way proved otherwise. – Olivier Jan 29 at 0:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.