Dual wifi connections in Bookworm

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.

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.

Microsoft were complete assholes.

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.

cu Michael

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

Oh. I wasn't meaning that that was the *exact* issue in this case. It was merely a nice swipe at Micro$oft.

Linux doesn't allow of more than one default route.

If you have two interfaces active on the same network, which one is going to be used to access that network?

I am not claiming this is the answer, just that it may be due some consideration.

I think some careful thought and experimentation may get you there quicker.

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

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

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

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

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

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

... 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

bob prohaska

But this isn’t multiple clients, it’s multiple interfaces on the same client. Pointless to have them on the same channel, really.

Multiple routing tables comes in with policy routing

Well so you have two default routes and two LAN routes but they have the same target value.

That is interesting, but I cant say as to what the effect of that will be.

When Ive tried that here with ethernet and wifi, netmanager always shuts don the wifi.

That's exactly what I got with an inadequate PSU.

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.

It may be pointless, but there is no reason why it should cause problems.

cu Michael

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.

Well if you are testing the speed you are saturating, and there will always be more overhead with two competing clients, than one.

---druck

Yes, but CSMA/CA reduces that to a point where it works fine unless the channel is heavily loaded.

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.

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 s*it as coaxial ethernet was, and should be avoided if at all possible

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.

cu Michael