| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 28 |
| Nodes: | 6 (1 / 5) |
| Uptime: | 45:08:19 |
| Calls: | 422 |
| Calls today: | 1 |
| Files: | 1,024 |
| Messages: | 90,304 |
I didn't think you could put full stops in an SSID
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?
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.
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.
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.
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
The point being wifi is as shit as coaxial ethernet was, and should be avoided if at all possible
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.
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.
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