1

I am using Raspbian Buster on a raspberry pi 3b v2 and I followed the @Ingo answer in this post. The failover works correctly, as far as the gateway is concerned. In normal conditions, i.e. when both ethernet and WLAN0 interfaces are up, the raspberry can reach the the gateway (i.e receives response to ping). When the ethernet link is down, the raspberry can still reach the gateway through WLAN0.

The raspberry cannot reach other hosts, if they are connected through WiFi to the same access point.

More precisely, in normal conditions, i.e. when both ethernet and WLAN interfaces are up, the raspberry cannot ping these hosts (and it cannot receive packets from these nodes). As soon as only one interface remains up (it can be either ethernet or WLAN0) the communication between the raspberry and the "problematic" hosts is re-established.

This behavior occurs with a fritzbox 7590 (fritzOS 7.13) but also with other acces points as well (technicolor tg789vac or Dlink DVA5992 or technicolor DGA4130).

I would say that this implies that dynamic failover is not completely working for the raspberry pi v3b (differently from the raspberry pi v4). Is anybody else experience the same problem? How is it possible to further debug this issue and eventually file a bug report somewhere?

PS---------------------------------------- Some details follow.

When both interfaces are up this is the status of bonding

openhabian@openhab:~$ 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: 2
Permanent HW addr: b8:27:eb:b3:1c:7d
Slave queue ID: 0

Slave Interface: wlan0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 2
Permanent HW addr: b8:27:eb:e6:49:28
Slave queue ID: 0

The ip address in this case is

 openhabian@openhab:~$ 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 7a:79:3c:31:5d:e3 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 7a:79:3c:31:5d:e3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.27.2/24 brd 192.168.27.255 scope global bond0
       valid_lft forever preferred_lft forever
    inet6 fd6f:17f9:753c:0:7879:3cff:fe31:5de3/64 scope global mngtmpaddr noprefixroute
       valid_lft forever preferred_lft forever
    inet6 fe80::7879:3cff:fe31:5de3/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 7a:79:3c:31:5d:e3 brd ff:ff:ff:ff:ff:ff

The ARP cache reflects the fact the the communication with the problematic host cannot be established. Even if I delete the host from the ARP cache in order to force an ARP search, the problem remains

openhabian@openhab:~$ ip neighbor
192.168.27.1 dev bond0 lladdr 08:60:6e:eb:58:f8 REACHABLE
192.168.27.54 dev bond0 lladdr 50:46:5d:b5:80:bf REACHABLE
192.168.27.30 dev bond0 lladdr 34:f3:9a:cd:e5:4c REACHABLE
*192.168.27.16 dev bond0  FAILED*

openhabian@openhab:~$ sudo ip neighbor delete 192.168.27.16 dev bond0

ip neighbor
192.168.27.1 dev bond0 lladdr 08:60:6e:eb:58:f8 REACHABLE
192.168.27.54 dev bond0 lladdr 50:46:5d:b5:80:bf REACHABLE
192.168.27.30 dev bond0 lladdr 34:f3:9a:cd:e5:4c REACHABLE
*192.168.27.16 dev bond0  FAILED*

As soon as one of the interfaces goes down communication with the node restarts without need to delete the ARP cache:

openhabian@openhab:~$ sudo ip link set wlan0 down
openhabian@openhab:~$ ip neighbor
192.168.27.1 dev bond0 lladdr 08:60:6e:eb:58:f8 REACHABLE
192.168.27.54 dev bond0 lladdr 50:46:5d:b5:80:bf REACHABLE
192.168.27.30 dev bond0 lladdr 34:f3:9a:cd:e5:4c REACHABLE
*192.168.27.16 dev bond0 lladdr 38:1a:52:47:32:35 REACHABLE*

As soon as two interfaces are up the communication fails again.


  • Configuration looks good so far. If you set eth0 down and wlan0 up, can you then ping 192.168.27.16? Do you can ping all other ip addresses no matter what interface is up or down? – Ingo Feb 9 at 16:06
  • Yes, If I set eth0 down and wlan0 up I can ping that problematic host and all others. – LionHe Feb 9 at 17:17
1

According to the commands output you have given about the configuration, bonding looks good so far. That all interfaces have the same mac address is due to bonding and will not confuse the fritz box router. Quite contrary it ensures that it does not sense the change of an interface on the fly because the mac address doesn't change. That's the trick of bonding.

You have one (or more?) devices that you only can ping if only the wlan0 interface is up as noted in a comment. If you have only the eth0 interface up you cannot reach the problematic device. This is also the case if both interfaces are up. Then eth0 is always used if available because of Primary Slave: eth0 (primary_reselect always). So we can say, if using the wired connection (eth0) then the problematic device cannot be connected. Because everything is working as expected with bonding I don't believe its a problem with it. You should look at your network configuration and/or at the fritz box router what could be the reason that only the WiFi connection works in this case.

|improve this answer|||||
  • @LionHe All the same, look at your network. I cannot saying much more about it with the (not) available information about your network. What have I to do to reproduce the error? Haven't seen it before. – Ingo Feb 9 at 20:19
  • I have a few devices that I cannot ping when eth0 and wlan0 are both up. If eth0 is down (unplugging the chord of with sudo ip link set eth0 down) then I can ping them again. If I plug the ethernet chord or give the sudo ip link set eth0 up then the devices are not reachable. If I switch off wlan0 with sudo ip link wlan0 down then the devices are reachable again. I can post the sequence of commands in the first post if it is useful to clarify this. In any case, thanks for your help, I'll try to reproduce the issue in more reproducible conditions (i.e. switching off all my network) – LionHe Feb 9 at 20:20
  • Yes, please edit your question and add it there. To summarize: if only one interface is up, no matter if eth0 or wlan0, then you can ping all devices on the network. If both interfaces are up, then there are some devices that you cannot ping but the other devices you can ping. Can you confirm this? Do you see any differences between these devices belonging to network connection? Are they always the same failing devices? – Ingo Feb 9 at 21:07
  • In the fritz-box do you have enabled "Wireless -> Security -> The active wireless devices displayed below may communicate with each other"? – Ingo Feb 9 at 21:07
  • I modified the question. Meanwhile I found that when both interfaces are up, the Raspberry can't connect to the hosts (not only smart devices, but also android phones or tablets) that are connected to the same access point to which wlan0 is associated. This occurs on the fritzbox but also on another access point (dga4132). As soon as eth0 or wlan0 go down every connection work. – LionHe Feb 10 at 20:26

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.