Bonded interface cannot ping printer

Hi, this thing is driving me crazy. I created a bonded interface with network manager, so that the ethernet card and the wireless card are linked together in an interface that we will call bond0. bond0 is in active backup mode, with the ethernet card as the primary interface. This way if I disconnect the cable it falls back on the wireless without dropping connections.

if I print the active connections with network manager I get:

NAME UUID TYPE DEVICE
bond-all a-long-number bond bond0
bond-eth another-long-number ethernet enp5s0
bond-wifi another-long-number wifi wlp6s0

and everything was working until I tried to print.

I can’t ping the printer when both slave connections are up. If I disconnect the cable or turn off the wireless card I can. I can ping other machines in the network when both are up.

Can anyone explain to me why?

Thanks!

Please always try to prove what you are saying by showing. Copy/paste from your terminal between CODE tags (that is the # button above the post edit field). Only so can we see what you sawand come to out own conclusions. It is e.g. unclear if you ping that printer by hostname or IP address, etc.

fair enough, here we go:

all interfaces are up:

nmcli connection show --active 
NAME           UUID                                  TYPE      DEVICE  
bond-casa-all  a28d1bef-196b-4f1d-a8d1-fd4049c6b3f9  bond       bond0
bond-eth       5f3aa436-2e57-461a-90ae-502f54b5c5f1  ethernet   enp5s0
bond-wifi      177ff41b-ae34-4855-9485-ab8ea1208678  wifi       wlp6s0

Pinging the printer:


**#**ping 192.168.1.18 
PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 
^C 
--- 192.168.1.18 ping statistics --- 
5 packets transmitted, 0 received, 100% packet loss, time 4097ms

I pull the cable off the ethernet card, connections don’t change:

** #**nmcli con show --active 
NAME           UUID                                  TYPE      DEVICE  
bond-casa-all  a28d1bef-196b-4f1d-a8d1-fd4049c6b3f9  bond       bond0
bond-eth       5f3aa436-2e57-461a-90ae-502f54b5c5f1  ethernet   enp5s0
bond-wifi      177ff41b-ae34-4855-9485-ab8ea1208678  wifi       wlp6s0

bringing down bond-eth doesn’t seem to make a difference, the cable is not there, and pinging now works:

 ping 192.168.1.18              
PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 
64 bytes from 192.168.1.18: icmp_seq=1 ttl=255 time=76.0 ms 
64 bytes from 192.168.1.18: icmp_seq=2 ttl=255 time=3.95 ms 
64 bytes from 192.168.1.18: icmp_seq=3 ttl=255 time=6.40 ms 
64 bytes from 192.168.1.18: icmp_seq=4 ttl=255 time=4.12 ms 
^C 
--- 192.168.1.18 ping statistics --- 
4 packets transmitted, 4 received, 0% packet loss, time 3005ms 
rtt min/avg/max/mdev = 3.949/22.626/76.045/30.856 ms

I reconnect the cable and turn off the wifi, this results in bond-wifi going down:

nmcli con show --active 
NAME           UUID                                  TYPE      DEVICE  
bond-casa-all  a28d1bef-196b-4f1d-a8d1-fd4049c6b3f9  bond      bond0
bond-eth       5f3aa436-2e57-461a-90ae-502f54b5c5f1  ethernet  enp5s0

I ping the printer now:

**#** ping 192.168.1.18       
PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 
64 bytes from 192.168.1.18: icmp_seq=10 ttl=255 time=43.5 ms 
64 bytes from 192.168.1.18: icmp_seq=11 ttl=255 time=27.5 ms 
64 bytes from 192.168.1.18: icmp_seq=12 ttl=255 time=3.58 ms 
64 bytes from 192.168.1.18: icmp_seq=13 ttl=255 time=9.95 ms 
64 bytes from 192.168.1.18: icmp_seq=14 ttl=255 time=7.04 ms 
64 bytes from 192.168.1.18: icmp_seq=15 ttl=255 time=5.50 ms 
64 bytes from 192.168.1.18: icmp_seq=16 ttl=255 time=18.1 ms 
^C 
--- 192.168.1.18 ping statistics --- 
16 packets transmitted, 7 received, 56.25% packet loss, time 15204ms 
rtt min/avg/max/mdev = 3.579/16.452/43.480/13.482 ms

and it works. Turn on wifi again, all interfaces are now up, cable is connected:

**#** nmcli con show --active 
NAME           UUID                                  TYPE      DEVICE  
bond-casa-all  a28d1bef-196b-4f1d-a8d1-fd4049c6b3f9  bond      bond0
bond-eth       5f3aa436-2e57-461a-90ae-502f54b5c5f1  ethernet  enp5s0
bond-wifi      177ff41b-ae34-4855-9485-ab8ea1208678  wifi      wlp6s0

ping once more:

**#** ping 192.168.1.18       
PING 192.168.1.18 (192.168.1.18) 56(84) bytes of data. 
^C 
--- 192.168.1.18 ping statistics --- 
10 packets transmitted, 0 received, 100% packet loss, time 9224ms

and all packets are lost once again. How is it that when either one of the bonded interfaces is connected ping works, but not when both are?

In case you were wondering, the routing looks like this the whole time:

ip r 
default via 192.168.1.254 dev bond0 proto dhcp metric 300  
192.168.1.0/24 dev bond0 proto kernel scope link src 192.168.1.2 metric 300 

Thanks!

This does not really provide any new or useful information. We see three lines; we do not know how these lines are related to each other; we do not know bond configuration, we do not know where ethernet and wireless interfaces are connected, we do not know what interface printer has and where it is connected … so nothing actually to make any guess.

all right! If you could tell me what kind of information you need I’ll provide it, I can’t dump here every single configuration file, can I?

Let’s see… this is /etc/NetworkManager/system-connections/bond-ethernet.nmconnection

[connection]
id=bond-eth
uuid=5f3aa436-2e57-461a-90ae-502f54b5c5f1
type=ethernet
interface-name=enp5s0
master=bond0
permissions=
slave-type=bond
timestamp=1612660236

[ethernet]
duplex=full
mac-address-blacklist=
speed=1000

This is bond-wifi.nmconnection:


[connection]
id=bond-wifi
uuid=177ff41b-ae34-4855-9485-ab8ea1208678
type=wifi
interface-name=wlp6s0
master=bond0
permissions=
slave-type=bond
timestamp=1610981051

[wifi]
mac-address-blacklist=
mode=infrastructure
seen-bssids=A0:BD:CD:A1:83:5A;
ssid=MYNETWORKNAME

[wifi-security]
key-mgmt=wpa-psk
psk=MYPASSWORD

And this is the configuration file of the bond:


[connection]
id=bond-casa-all
uuid=a28d1bef-196b-4f1d-a8d1-fd4049c6b3f9
type=bond
autoconnect-priority=1
autoconnect-slaves=1
interface-name=bond0
permissions=
timestamp=1612660592

[ethernet]
cloned-mac-address=10:7B:44:18:D8:47
mac-address-blacklist=

[bond]
downdelay=0
miimon=1
mode=active-backup
primary=enp5s0
updelay=0

[ipv4]
dns-search=
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=auto
[proxy]

Let’s see the network interfaces now:


ip a 
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: **enp5s0: **<BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state **UP **group default qlen 1000 
    link/ether **10:7b:44:18:d8:47** brd **ff:ff:ff:ff:ff:ff** 
3: **wlp6s0: **<BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state **UP **group default qlen 1000 
    link/ether **10:7b:44:18:d8:47** brd **ff:ff:ff:ff:ff:ff** permaddr **88:d7:f6:02:94:43** 
7: **bond0: **<BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state **UP **group default qlen 1000 
    link/ether **10:7b:44:18:d8:47** brd **ff:ff:ff:ff:ff:ff** 
    inet **192.168.1.2**/24 brd **192.168.1.255 **scope global dynamic noprefixroute bond0 
       valid_lft 77464sec preferred_lft 77464sec 
    inet6 **2a02:c7f:daef:eb00:b7b7:647d:dd67:9a5e**/64 scope global dynamic noprefixroute  
       valid_lft 2078sec preferred_lft 2078sec 
    inet6 **fd35:2c43:1ff:0:b00:f7db:487:3055**/64 scope global noprefixroute  
       valid_lft forever preferred_lft forever 
    inet6 **fe80::6357:db6b:47f1:605b**/64 scope link noprefixroute  
       valid_lft forever preferred_lft forever

The bond clones the mac address of enp5s0, so that the DHCP server that was configured for the wired interface gives the bond the same static IP that I had set for it. The wired interface is connected to a router. The same router is the access point of the wifi network that bond-wifi connects to. So both interfaces are connected to the same router, each in their own way. The printer (192.168.1.18) is connected to the same wifi.

If there’s anything you’d need to know to figure out what’s happening just let me know :).

Will this cause problems connecting to the Internet?
Ordinarily,
When I’ve set up bonded network interfaces, they’re connected to the same network so that if one fails, the network connections still connect to remote networks the same way
If you bond a wireless and wired interface, they’re connecting to different networks.
I’d have to think about whether that would cause problems connecting to other devices in your LAN, but it seems to be that would be a big problem connecting to remote networks like the Internet.

TSU

OK, so printer has wireless interface, correct? Do you have other home devices? If yes, are they wired or wireless? Can you access these other devices?

no problem with the Internet. I used this setup for weeks without realizing, until I had to print :).

Interesting question. I pinged some stuff, and I can reach wired devices, but not wireless. Note that if I turn off the wireless card then I can ping wireless devices when only the wired interface is up… :\

Stale ARP in the router perhaps? Restart the router and check device (wired and wireless) access again.

Recommend try:
Power down your PC.
Disconnect one of the network connections.
Boot up and try to connect to your printer.

Power down your PC.
Disconnect your network connection and connect using the other network device.
Boot up and try to connect to your printer.

TSU

Run packet capture on both wired and wireless interfaces while you perform do ping. Something like

sudo dumpcap -i eth0 -i wlan0 -w /tmp/trace.pcapng

and make resulting file available. Do not forget to tell which IP you pinged.

I liked the idea that rebooting would fix it, but it didn’t :slight_smile:

pinging succeeds in both cases.

So this was interesting. I never used wireshark before. I first brought down the wireless interface (let’s call this wifi), so the bond is connected only through the wired one (let’s call this eth). I pinged and recorded the file called trace. Then I brought up the wifi, so that now the bond has both, and recorded the second trace. Lastly, I pinged with both interfaces up but only recorded eth, the one that is used when both in the bond are up, this is the third trace. The files are here: https://www.dropbox.com/sh/3w8bft6k0l43113/AADBWjcAqW3mwv10LwM-7W5la?dl=0

This is what I notice:

  1. When only eth is up: ARP response is received by eth.
  2. When both eth and wifi are up: ARP request is received, I guess by wifi.
  3. Both are up, but I only record eth: ARP request is not received.

My guess is that the router sees the mac address of the bond in both the wired and wifi network. Because the ARP response is in the wifi network, it doesn’t switch it to the wired network, assuming that the bond has gotten the response over wifi. However, when both interfaces are up, the bond only listens to eth, and therefore never receives the ARP response. Does this make any sense?

That’s not what I asked you to do.

But it is. It’s case 2. Please look at file trace2 in the linked folder.

My computer is 192.168.1.2, the printer is 192.168.1.18. I can see ARP requests for 192.168.1.18 made on interface enp5s0, and the responses being received on wlp6s0. I think this has something to do with my problem.

Yes, sorry, did not pay attention.

My computer is 192.168.1.2, the printer is 192.168.1.18. I can see ARP requests for 192.168.1.18 made on interface enp5s0, and the responses being received on wlp6s0. I think this has something to do with my problem.

Yes. Educated guess is that wireless interface connects to AP using bond MAC so AP assumes this MAC is directly connected and does not attempt to forward it to Ethernet part of you router. Can you check connected devices in your AP when both interfaces are up in bond?

Look at fail_over_mac bond option. You probably want active or follow, whatever works best for you.

great! This sounds exactly like what I need. Thanks!

And? Did it help? It would be prudent to let us know so others could also benefit from it.

Imo since y9u succeeded with the test I recommended,
the problem isn’t likely a basic network connectivity problem.
The problem is something higher up on the network stack,

  • If you’re connecting to your printer by name, you’ll need to look at name resolution, whether it works at all and whether it maps using both network connections (ie try pinging your printer by name)
  • You may need to inspect the printer protocol you’re using.
  • You may need to inspect your printer configuration.

TSU