From: "Brian J. Murrell" <brian@interlinx.bc.ca>
To: netdev@vger.kernel.org
Subject: Re: bonded active-backup ethernet-wifi drops packets
Date: Fri, 21 Jun 2019 08:30:28 -0400 [thread overview]
Message-ID: <30bdcc940d2bdafb7b8f5609207a4bf642fcf9a5.camel@interlinx.bc.ca> (raw)
In-Reply-To: <0292e9eefb12f1b1e493f5af8ab78fa00744ed20.camel@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]
On Tue, 2019-06-18 at 14:57 -0400, Brian J. Murrell wrote:
> Hi.
An update...
I have another machine with the same ethernet-wifi bonded connection
and it behaves perfectly but only when disconnected from the wired-
ethernet and therefore on the bonded-wifi. The ping -f occasionally
bursts out a few '.'s but it quickly catches up and removes them (i.e.
very momentary delay -- to be expected for wifi I suppose).
But when I do plug it into wired, it drops packets like the other
machine. Which is really odd. I'd think wired should be much more
reliable than wifi.
So why does this machine behave (but only on wifi) and the other one
doesn't. To compare them...
> I have an active-backup bonded connection on a 5.1.6 kernel
Working machine has a 5.0.16 kernel.
> My bonding config:
>
> $ cat /proc/net/bonding/bond0
> Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
>
> Bonding Mode: fault-tolerance (active-backup)
> Primary Slave: enp0s31f6 (primary_reselect always)
> Currently Active Slave: enp0s31f6
> MII Status: up
> MII Polling Interval (ms): 100
> Up Delay (ms): 0
> Down Delay (ms): 0
>
> Slave Interface: enp0s31f6
> MII Status: up
> Speed: 1000 Mbps
> Duplex: full
> Link Failure Count: 0
> Permanent HW addr: 0c:54:15:4a:b2:0d
> Slave queue ID: 0
>
> Slave Interface: wlp2s0
> MII Status: up
> Speed: Unknown
> Duplex: Unknown
> Link Failure Count: 1
> Permanent HW addr: 0c:54:15:4a:b2:0d
> Slave queue ID: 0
Working machine:
$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: fault-tolerance (active-backup)
Primary Slave: enp0s25 (primary_reselect always)
Currently Active Slave: enp0s25
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: wlp3s0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 1
Permanent HW addr: 00:24:d7:7b:1f:24
Slave queue ID: 0
Slave Interface: enp0s25
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:24:d7:7b:1f:24
Slave queue ID: 0
> Current interface config/stats:
>
> $ ifconfig bond0
> bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
> inet 10.75.22.245 netmask 255.255.255.0 broadcast
> 10.75.22.255
> inet6 fe80::ee66:b8c9:d55:a28f prefixlen 64 scopeid
> 0x20<link>
> inet6 2001:123:ab:123:d36d:5e5d:acc8:e9bc prefixlen
> 64 scopeid 0x0<global>
> ether 0c:54:15:4a:b2:0d txqueuelen 1000 (Ethernet)
> RX packets 1596206 bytes 165221404 (157.5 MiB)
> RX errors 0 dropped 0 overruns 0 frame 0
> TX packets 1590552 bytes 162689350 (155.1 MiB)
> TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Working machine:
$ ifconfig bond0
bond0: flags=5187<UP,BROADCAST,RUNNING,MASTER,MULTICAST> mtu 1500
inet 10.75.22.130 netmask 255.255.255.0 broadcast 10.75.22.255
inet6 2001:470:1d:6f8:b12f:e840:c6a9:8480 prefixlen 64 scopeid 0x0<global>
inet6 fd31:aeb1:48df:0:2374:a2d1:e1b7:89a3 prefixlen 64 scopeid 0x0<global>
inet6 fe80::3dac:5dd4:3c21:421b prefixlen 64 scopeid 0x20<link>
ether 00:24:d7:7b:1f:24 txqueuelen 1000 (Ethernet)
RX packets 40416877 bytes 10615841459 (9.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9040319 bytes 1493391347 (1.3 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
> Devices:
> 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection
> (2) I219-LM (rev 31)
> 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275
> (rev 78)
Working machine:
00:19.0 Ethernet controller: Intel Corporation 82577LM Gigabit Network Connection (rev 06)
03:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)
The only real difference I can see is hardware and kernel version. Or
was there something I missed?
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-06-21 12:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 18:57 bonded active-backup ethernet-wifi drops packets Brian J. Murrell
2019-06-21 12:30 ` Brian J. Murrell [this message]
2019-07-04 15:12 ` Brian J. Murrell
2019-07-06 0:46 ` Jay Vosburgh
2019-07-12 12:51 ` Brian J. Murrell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=30bdcc940d2bdafb7b8f5609207a4bf642fcf9a5.camel@interlinx.bc.ca \
--to=brian@interlinx.bc.ca \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).