I'm a little surprised that two interfaces are worse than one.
On Sun, 24 Nov 2024 18:50:55 -0000 (UTC), bp wrote:
I've now got two wifi connections on my Pi5 running Bookworm. Following
the latest update a day or two ago both come up automatically on reboot
connecting to the same access point with the same frequency and channel.
Using both interfaces together seems to result in much worse performance
than either one alone, which I didn't expect at all.
If they are on the same frequency/channel, it’s no surprise they’re interfering with each other. Can you set them on different, non-
overlapping frequencies/channels?
I've now got two wifi connections on my Pi5 running Bookworm. Following
the latest update a day or two ago both come up automatically on reboot connecting to the same access point with the same frequency and channel.
Using both interfaces together seems to result in much worse performance
than either one alone, which I didn't expect at all.
On 2024-11-24, <bp@www.zefox.net> <bp@www.zefox.net> wrote:
I'm a little surprised that two interfaces are worse than one.
Do you have separate IP addresses for the two interfaces?
cu
Michael
I'm curious, what is the point? Do you want it to go faster, use a
wire. Are you going to connect them to different access points? Do you
have two different networks? You can plug in multiple USB NICs as well.
I've now got two wifi connections on my Pi5 running Bookworm.
Following the latest update a day or two ago both come up
automatically on reboot connecting to the same access point
with the same frequency and channel. Using ifconfig it's
possible to turn them on or off individually.
The internal wifi shows a ping time of 5-10 ms, the USB
external Archer T3U is generally under 2 ms, perhaps because
it reports a stronger (~95% vs 75%) signal strength.
Using both interfaces together seems to result in much worse
performance than either one alone, which I didn't expect at all.
Ping times reach tens of seconds under load, for example. The
effect relliably appears a few seconds after applying the load
using the chromium browser.
I'm a little surprised that two interfaces are worse than one.
Has anybody else seen this behavior?
Thanks for reading,
bob prohaska
Knute Johnson <knute2024@585ranch.com> wrote:
I'm curious, what is the point? Do you want it to go faster, use a
wire. Are you going to connect them to different access points? Do you
have two different networks? You can plug in multiple USB NICs as well.
The point is to first understand why wifi connectivity went from usable
to unusable. Then, if possible, to fix it.
The first thought was interference from other access points nearby.
No consistent evidence has been found, but I'm still looking.
The second thought was a faulty upgrade to Bookworm (this is on a Pi5) There's a sliver of support for that idea, since performance changed following some upgrades.
Third, a problem with the access point. That seems unlikely since other
hosts connect successfully and reliably.
Right now using a usb-wifi adapter seems to fix the problem. To me that suggests a problem with the internal WiFi hardware or the software that drives it. The Raspberry Pi forums have some accounts of poor wifi behavior on Pi5s, but not many and no unifying features are obvious.
What case do you use - is it metal?
If so, I would suggest disabling the internal WiFi, and using the
stronger signal you get from the USB adapter
There's still something funny about the two channels when used
separately. The internal wifi shows ~5 ms pings to the access point
with no other traffic but seconds of delay when watching Youtube
videos. The external wifi alone shows ~2 ms delays when idle and
only about 4 ms when watching YouTube.
On Sun, 24 Nov 2024 20:58:42 -0000 (UTC), bp wrote:
There's still something funny about the two channels when used
separately. The internal wifi shows ~5 ms pings to the access point
with no other traffic but seconds of delay when watching Youtube
videos. The external wifi alone shows ~2 ms delays when idle and
only about 4 ms when watching YouTube.
Are you sure the unused interface is turned completely off -- no radio transmissions at all?
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
bp@www.zefox.net wrote:
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
Something else is going on. Placed in scan mode, the external usb-wifi adapter is reporting
non-existent access points:
ATTKXEBVbA DC:8D:8A:5A:D6:D4 54%, -72 dBm, ch 1, 2412 MHz 43% chan, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS millerhome2 F0:72:EA:49:C6:4A 54%, -72 dBm, ch 6, 2437 MHz ESS, Radio Measure
<hidden ESSID> 7C:9A:54:FC:7E:7F 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7E 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7C 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7A 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:79 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
ATTKXEBVbA DC:8D:8A:5A:D6:D4 56%, -71 dBm, ch 36, 5180 MHz 20% chan, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:87 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:84 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:81 61%, -67 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:86 63%, -66 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 108, 5540 MHz ESS d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS
The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.
Anybody got an idea what's going on?
Thanks for reading!
bob prohaska
On 25/11/2024 16:30, bp@www.zefox.net wrote:
bp@www.zefox.net wrote:7C:9A:54:FC:7E:7F is a Tecnicolor CH USA device. Do you have any such devices?
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
Something else is going on. Placed in scan mode, the external usb-wifi adapter is reporting
non-existent access points:
ATTKXEBVbA DC:8D:8A:5A:D6:D4 54%, -72 dBm, ch 1, 2412 MHz 43% chan, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS
millerhome2 F0:72:EA:49:C6:4A 54%, -72 dBm, ch 6, 2437 MHz ESS, Radio Measure
<hidden ESSID> 7C:9A:54:FC:7E:7F 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7E 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7C 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7A 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:79 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
ATTKXEBVbA DC:8D:8A:5A:D6:D4 56%, -71 dBm, ch 36, 5180 MHz 20% chan, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:87 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:84 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:81 61%, -67 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:86 63%, -66 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 108, 5540 MHz ESS
d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS
The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.
Anybody got an idea what's going on?
Thanks for reading!
bob prohaska
mm0fmf <none@invalid.com> wrote:
On 25/11/2024 16:30, bp@www.zefox.net wrote:
bp@www.zefox.net wrote:7C:9A:54:FC:7E:7F is a Tecnicolor CH USA device. Do you have any such
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
Something else is going on. Placed in scan mode, the external usb-wifi adapter is reporting
non-existent access points:
ATTKXEBVbA DC:8D:8A:5A:D6:D4 54%, -72 dBm, ch 1, 2412 MHz 43% chan, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS
millerhome2 F0:72:EA:49:C6:4A 54%, -72 dBm, ch 6, 2437 MHz ESS, Radio Measure
<hidden ESSID> 7C:9A:54:FC:7E:7F 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7E 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7C 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7A 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:79 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
ATTKXEBVbA DC:8D:8A:5A:D6:D4 56%, -71 dBm, ch 36, 5180 MHz 20% chan, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:87 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:84 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:81 61%, -67 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:86 63%, -66 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 108, 5540 MHz ESS
d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS
The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.
Anybody got an idea what's going on?
Thanks for reading!
bob prohaska
devices?
It must belong to a neighbor. My AP is d-link.zefox.net, a DI-524.
What motivates the question?
Thanks for writing,
bob prohaska
bp@www.zefox.net wrote:That's a Nokia device. Possibly a smart phone being used as an access point
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
Something else is going on. Placed in scan mode, the external usb-wifi adapter is reporting
non-existent access points:
ATTKXEBVbA DC:8D:8A:5A:D6:D4 54%, -72 dBm, ch 1, 2412 MHz 43% chan, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS
millerhome2 F0:72:EA:49:C6:4A 54%, -72 dBm, ch 6, 2437 MHz ESS, Radio MeasureThose are all MAC addtreses from Vantiva, which sells broadband .
<hidden ESSID> 7C:9A:54:FC:7E:7F 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7E 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7C 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7A 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:79 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
ATTKXEBVbA DC:8D:8A:5A:D6:D4 56%, -71 dBm, ch 36, 5180 MHz 20% chan, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:87 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:84 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:81 61%, -67 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:86 63%, -66 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 108, 5540 MHz ESS d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS
The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.
Anybody got an idea what's going on?
Thanks for reading!
bob prohaska
On 25/11/2024 16:30, bp@www.zefox.net wrote:
bp@www.zefox.net wrote:That's a Nokia device. Possibly a smart phone being used as an access point
Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.
Something else is going on. Placed in scan mode, the external usb-wifi adapter is reporting
non-existent access points:
ATTKXEBVbA DC:8D:8A:5A:D6:D4 54%, -72 dBm, ch 1, 2412 MHz 43% chan, Radio Measure, Spectrum Mgmt
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS
Thats a Pi set up badly
millerhome2 F0:72:EA:49:C6:4A 54%, -72 dBm, ch 6, 2437 MHz ESS, Radio MeasureThose are all MAC addtreses from Vantiva, which sells broadband .
<hidden ESSID> 7C:9A:54:FC:7E:7F 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7E 70%, -61 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7C 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:7A 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:79 71%, -60 dBm, ch 11, 2462 MHz ESS, Radio Measure, Spectrum Mgmt
Presumably they have some routers nearby
ATTKXEBVbA DC:8D:8A:5A:D6:D4 56%, -71 dBm, ch 36, 5180 MHz 20% chan, Radio Measure, Spectrum Mgmt
That's a Nokia device. Possibly a smart phone being used as an access point
<hidden ESSID> 7C:9A:54:FC:7E:87 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:84 60%, -68 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
cross 7C:9A:54:FC:7E:81 61%, -67 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
<hidden ESSID> 7C:9A:54:FC:7E:86 63%, -66 dBm, ch 44, 5220 MHz ESS, Radio Measure, Spectrum Mgmt
More Manitiva shit
d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 108, 5540 MHz ESSThat's a pi set up badly I think
d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS
The last two entries appear to be duplicates of the second, with a wrong frequency attribution: myI didn't see your access point in there at all.
AP can't use 5 GHz.
What is its SSID?
On 25/11/2024 18:57, bp@www.zefox.net wrote:
What motivates the question?
7C:9A:54 is a Technicolor MAC address
What motivates the question?
Sorry, but I still don't understand the significance of that fact....
I'm a little surprised that two interfaces are worse than one.
Has anybody else seen this behavior?
I didn't think you could put full stops in an SSID
If both interfaces are talking to the same Access point on the same frequency, it's going to be worse as WiFi can only talk to one thing at
a time, and the two interfaces will compete for bandwidth.
If they are on the same frequency/channel, it’s no surprise they’re interfering with each other. Can you set them on different, non-
overlapping frequencies/channels?
On 2024-11-25, druck <news@druck.org.uk> wrote:
If both interfaces are talking to the same Access point on the same
frequency, it's going to be worse as WiFi can only talk to one thing at
a time, and the two interfaces will compete for bandwidth.
It's not different from having two completely separate clients connected to the same AP. Unless the channel is fully saturated, the available bandwith will be shared between the clients.
cu
Michael
However the ability under windows to make BOTH of them the default
route, led to the TCP/IP stack using them in round robin to send TCP/IP packets.
On 27/11/2024 10:50, Michael Schwingen wrote:
On 2024-11-25, druck <news@druck.org.uk> wrote:
If both interfaces are talking to the same Access point on the same
frequency, it's going to be worse as WiFi can only talk to one thing at
a time, and the two interfaces will compete for bandwidth.
It's not different from having two completely separate clients connected to >> the same AP. Unless the channel is fully saturated, the available bandwith >> will be shared between the clients.
cu
Michael
It reminds me of a really strange situation we encountered in the early
days of NT and TCP/IP
The customer complained of 50% packet loss.
EXACTLY 50% packet loss.
It turned out their NT server was bridging tow networks and had two
Ethernet cards. And two different IP addresses.
Nothing wrong with that.
On 2024-11-27, The Natural Philosopher <tnp@invalid.invalid> wrote:
However the ability under windows to make BOTH of them the default
route, led to the TCP/IP stack using them in round robin to send TCP/IP
packets.
I just checked on my laptop, which has (sometimes) ethernet and wireless connections to the same network, with separate IP addresses. This works just fine without any packet losses.
This is while running Debian, not raspbian, but at least it shows that this scenario can work on Linux - I am at a loss what happens on the problem machine. Probably some tcpdump/wireshark tracing, maybe even on both sides of the access point, is required to get at the cause of the problem.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 27/11/2024 10:50, Michael Schwingen wrote:
On 2024-11-25, druck <news@druck.org.uk> wrote:
If both interfaces are talking to the same Access point on the same
frequency, it's going to be worse as WiFi can only talk to one thing at >>>> a time, and the two interfaces will compete for bandwidth.
It's not different from having two completely separate clients connected to >>> the same AP. Unless the channel is fully saturated, the available bandwith >>> will be shared between the clients.
cu
Michael
It reminds me of a really strange situation we encountered in the early
days of NT and TCP/IP
The customer complained of 50% packet loss.
EXACTLY 50% packet loss.
It turned out their NT server was bridging tow networks and had two
Ethernet cards. And two different IP addresses.
Nothing wrong with that.
Hmm, that's a close parallel to my situation. Each wifi interface
has its own IP address. However, I'm losing much more than half
my traffic, and not repeatably. Sometimes almost none is lost,
other times everything, seemingly but not predictably depending
on load.
Thanks for writing,
bob prohaska
Bob.. I dont *know* how linux routing copes with two interfaces to the
same network.
Ideally it should open either at random, and since they have unique
source addresses pings should always get back. Nothing outside the
machine itself knows whether it has two interfaces or is in fact two
separate machines.
I just know that my gut feeling is not to do that, at all.
When you have all these interfaces up, what does ifconfig show? and route?
Michael Schwingen wrote:... per route table.
The Natural Philosopher wrote:
route, led to the TCP/IP stack using them in round robin to send TCP/IPthe ability under windows to make BOTH of them the default
packets.
I just checked on my laptop, which has (sometimes) ethernet and
wireless connections to the same network, with separate IP
addresses. This works just fine without any packet losses.
Linux doesn't allow of more than one default route.
The Natural Philosopher <tnp@invalid.invalid> wrote:
Bob.. I dont *know* how linux routing copes with two interfaces to the
same network.
Ideally it should open either at random, and since they have unique
source addresses pings should always get back. Nothing outside the
machine itself knows whether it has two interfaces or is in fact two
separate machines.
I just know that my gut feeling is not to do that, at all.
When you have all these interfaces up, what does ifconfig show? and route?
To start with, ifconfig reports
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.18 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::26ee:3368:6e6c:aa6e prefixlen 64 scopeid 0x20<link>
ether 24:2f:d0:b9:54:f7 txqueuelen 1000 (Ethernet)
RX packets 6896208 bytes 8657581257 (8.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1647035 bytes 215681086 (205.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and route reports
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 601 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 601 0 0 wlan1
If I bring up wlan0 (the internal wifi interface then ifconfig reports
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::98a0:b51e:4f4:236a prefixlen 64 scopeid 0x20<link>
ether 2c:cf:67:0f:10:64 txqueuelen 1000 (Ethernet)
RX packets 108 bytes 15818 (15.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1120 bytes 200215 (195.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.18 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::26ee:3368:6e6c:aa6e prefixlen 64 scopeid 0x20<link>
ether 24:2f:d0:b9:54:f7 txqueuelen 1000 (Ethernet)
RX packets 6897155 bytes 8657817041 (8.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1648196 bytes 215824139 (205.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and route reports
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 601 0 0 wlan1 default 192.168.1.254 0.0.0.0 UG 602 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 601 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 602 0 0 wlan0
At the moment, there's a ping session running to the gateway continuously. Times are sub-2ms unloaded, until I start loading a big page under chromium, whereupon ping times go.....dammit, everthing works just fine 8-(
At the moment I'm baffled.
On 2024-11-24, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
If they are on the same frequency/channel, it’s no surprise they’re
interfering with each other. Can you set them on different, non-
overlapping frequencies/channels?
Not really. Multiple WLAN clients work fine on the same channel due to
the use of CSMA/CA ...
The Natural Philosopher wrote:
Linux doesn't allow of more than one default route.
... per route table.
It turns out that letting the system stand for ~4 hrs reproduced some
of the problems. Ping times with both interfaces up eventually rose to
7-10 ms but didn't fail completely. Several of the ssh connections
open from the Pi5 to other hosts either froze or disconnected.
The Natural Philosopher <tnp@invalid.invalid> wrote:
Bob.. I dont *know* how linux routing copes with two interfaces to the
same network.
Ideally it should open either at random, and since they have unique
source addresses pings should always get back. Nothing outside the
machine itself knows whether it has two interfaces or is in fact two
separate machines.
I just know that my gut feeling is not to do that, at all.
When you have all these interfaces up, what does ifconfig show? and route?
To start with, ifconfig reports
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.18 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::26ee:3368:6e6c:aa6e prefixlen 64 scopeid 0x20<link>
ether 24:2f:d0:b9:54:f7 txqueuelen 1000 (Ethernet)
RX packets 6896208 bytes 8657581257 (8.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1647035 bytes 215681086 (205.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and route reports
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 601 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 601 0 0 wlan1
If I bring up wlan0 (the internal wifi interface then ifconfig reports
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.11 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::98a0:b51e:4f4:236a prefixlen 64 scopeid 0x20<link>
ether 2c:cf:67:0f:10:64 txqueuelen 1000 (Ethernet)
RX packets 108 bytes 15818 (15.4 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1120 bytes 200215 (195.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.18 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::26ee:3368:6e6c:aa6e prefixlen 64 scopeid 0x20<link>
ether 24:2f:d0:b9:54:f7 txqueuelen 1000 (Ethernet)
RX packets 6897155 bytes 8657817041 (8.0 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1648196 bytes 215824139 (205.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
and route reports
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.254 0.0.0.0 UG 601 0 0 wlan1 default 192.168.1.254 0.0.0.0 UG 602 0 0 wlan0 192.168.1.0 0.0.0.0 255.255.255.0 U 601 0 0 wlan1 192.168.1.0 0.0.0.0 255.255.255.0 U 602 0 0 wlan0
At the moment, there's a ping session running to the gateway continuously. Times are sub-2ms unloaded, until I start loading a big page under chromium, whereupon ping times go.....dammit, everthing works just fine 8-(
At the moment I'm baffled.
Thanks for writing, apologies for the goose chase.
bob prohaska
Not really. Multiple WLAN clients work fine on the same channel due to
the use of CSMA/CA ...
But this isn’t multiple clients, it’s multiple interfaces on the same client. Pointless to have them on the same channel, really.
On 2024-11-25, druck <news@druck.org.uk> wrote:
If both interfaces are talking to the same Access point on the same
frequency, it's going to be worse as WiFi can only talk to one thing at
a time, and the two interfaces will compete for bandwidth.
It's not different from having two completely separate clients connected to the same AP. Unless the channel is fully saturated, the available bandwith will be shared between the clients.
On 2024-11-27, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
Not really. Multiple WLAN clients work fine on the same channel due
to the use of CSMA/CA ...
But this isn’t multiple clients, it’s multiple interfaces on the same
client. Pointless to have them on the same channel, really.
No, as far as the wireless channel and the access point are concerned,
these are two separate clients. That they are attached to the same host
does not matter, they will cooperate / share airtime.
No, as far as the wireless channel and the access point are concerned,
these are two separate clients. That they are attached to the same host
does not matter, they will cooperate / share airtime.
Regardless of how you look at it, they are colliding with each other.
Having two interfaces on the same channel cannot magically double its bandwidth.
And because both transmitters are so close to each other, that
aggravates the losses from frame collisions.
On 2024-11-28, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
No, as far as the wireless channel and the access point are concerned,
these are two separate clients. That they are attached to the same host >>> does not matter, they will cooperate / share airtime.
Regardless of how you look at it, they are colliding with each other.
Yes, but CSMA/CA reduces that to a point where it works fine unless the channel is heavily loaded.
Having two interfaces on the same channel cannot magically double its
bandwidth.
I never said that - of course they share the bandwidth, just like two separate clients do. Noone installs one separate access point for every device they use (not only because you would run out of free channels quite quick, even with 5/6GHz) - multiple devices connected to a single AP is a standard, supported scenario. Even when one client does heavy up/downloads, the others will notice a slowdown, but not the packet loss problems that
were the start of this thread.
And because both transmitters are so close to each other, that
aggravates the losses from frame collisions.
How? Being close to each other, they can easily "see" when the channel is busy and will not step over each other's foot. Contrary, widely spaced clients
lead to the "hidden station" problem where two stations each "see" the
access point, but not each other, and start to transmit at the same time.
cu
Michael
It's not different from having two completely separate clients connected to >> the same AP. Unless the channel is fully saturated, the available bandwith >> will be shared between the clients.
Well if you are testing the speed you are saturating, and there will
always be more overhead with two competing clients, than one.
The point being wifi is as shit as coaxial ethernet was, and should be avoided if at all possible
On 2024-11-28, druck <news@druck.org.uk> wrote:
It's not different from having two completely separate clients connected to >>> the same AP. Unless the channel is fully saturated, the available bandwith >>> will be shared between the clients.
Well if you are testing the speed you are saturating, and there will
always be more overhead with two competing clients, than one.
Usually, you can't *completely* saturate a WLAN channel with one client and one TCP stream. I just did a test with two laptops on my WLAN, running iperf3 against a server on my LAN (so I am not limited by my internet connection).
When I run iperf on both clients, the aggregated bandwith is actually a wee bit HIGHER than what a single client can achieve - regardless of direction. And with one client running iperf traffic as fast as it can, the other one can use the net just fine, without perceivable delays or losses. ping latency on the unloaded client rises from 2-4ms to 20-40ms - this is not really noticeable when browsing the web.
With both clients transferring data, they share roughly 50/50.
This is on an old 802.11ac (Wifi5) access point, with Intel AX200/AX210 modules in the clients, so modern features like OFDMA that might help in
this scenario are not available. And this is on a 2.4GHz channel in a residential area where I am not alone on that channel.
On 2024-11-29, The Natural Philosopher <tnp@invalid.invalid> wrote:
The point being wifi is as shit as coaxial ethernet was, and should be
avoided if at all possible
Agreed - if I can get a wired connection, that is preferrable (if throughput matters - I won't bother plugging in an ethernet cable to transfer some
small amount of data to my laptop).
However, there is nothing inherent in wifi that explains the observed problems with the two adapters on one machine.
TCP/IP / 802 is well enough designed to make this sort of stuff work as
well as it can...
Smart chaps with beards and tweed jackets have spent their whole summers trying to make it work like that, and it dies.
Shame they never get enough time to get laid and pass their genes on...
Shame they never get enough time to get laid and pass their genes on...
On 2024-11-29, The Natural Philosopher <tnp@invalid.invalid> wrote:
Shame they never get enough time to get laid and pass their genes on...
Time to re-watch
https://www.imdb.com/title/tt0387808/
;-)
On 27/11/2024 20:22, bp@www.zefox.net wrote:
It turns out that letting the system stand for ~4 hrs reproduced some
of the problems. Ping times with both interfaces up eventually rose to
7-10 ms but didn't fail completely. Several of the ssh connections
open from the Pi5 to other hosts either froze or disconnected.
That's exactly what I got with an inadequate PSU.
The Natural Philosopher <tnp@invalid.invalid> wrote:
On 27/11/2024 20:22, bp@www.zefox.net wrote:
It turns out that letting the system stand for ~4 hrs reproduced some
of the problems. Ping times with both interfaces up eventually rose to
7-10 ms but didn't fail completely. Several of the ssh connections
open from the Pi5 to other hosts either froze or disconnected.
That's exactly what I got with an inadequate PSU.
Since a software update this morning it appears that both interfaces
are co-existing without problems. Re-checking the supply voltage
reveals 5.05 volts, 10 mV below the value seen earlier, measured on
the GPIO header.
That's not to claim the problem is resolved: It took about four hours
to misbehave in the previous instance, now it might merely take longer.
uname -a now reports
Linux raspberrypi 6.6.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux
Thanks for writing,
bob prohaska
On 29/11/2024 23:13, bp@www.zefox.net wrote:
The Natural Philosopher <tnp@invalid.invalid> wrote:I got sag when USB was drawing current I think.
On 27/11/2024 20:22, bp@www.zefox.net wrote:
It turns out that letting the system stand for ~4 hrs reproduced some
of the problems. Ping times with both interfaces up eventually rose to >>>> 7-10 ms but didn't fail completely. Several of the ssh connections
open from the Pi5 to other hosts either froze or disconnected.
That's exactly what I got with an inadequate PSU.
Since a software update this morning it appears that both interfaces
are co-existing without problems. Re-checking the supply voltage
reveals 5.05 volts, 10 mV below the value seen earlier, measured on
the GPIO header.
That's not to claim the problem is resolved: It took about four hoursFingers crossed.
to misbehave in the previous instance, now it might merely take longer.
uname -a now reports
Linux raspberrypi 6.6.62+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux
The point being wifi is as shit as coaxial ethernet was, and should be avoided if at all possible
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 4 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 59:03:24 |
| Calls: | 65 |
| Files: | 21,500 |
| Messages: | 73,556 |