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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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 wondered about that, but the initial settings were "automatic" and
the connection software didn't try to put them on different channels.
Presently the internal wifi remains "automatic" and the USB wifi is
set to channel 5. At this point I'll be interested mostly in whether
the setting is honored (tried it once before, still got channel 2).

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. The internal wifi bogs down
very badly under load, in a way that is new compared the initial
Bookworm installation.

On the plus side, at least the internal wifi can connect now. For
quite some time it didn't connect at all. I'm using the same hardware,
only software updates have been applied.

Thanks for writing,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael Schwingen <news-1513678000@discworld.dascon.de> wrote:

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?

Yes. From the GUI controls there doesn't appear to be any other choise.

cu
Michael

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

Thanks for writing,


bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 11/24/24 12:50, bp@www.zefox.net 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 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

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.

--

Knute Johnson

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/11/2024 23:01, bp@www.zefox.net wrote:

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

--
Chris

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Chris Townley <news@cct-net.co.uk> wrote:

What case do you use - is it metal?

Not metal. It's clear plastic. The internal wifi worked just fine,
displaying signal quality in the 75-80% range when first set up.

There's some chance I misunderstand the meaning of "signal quality".
It appears to be a simple log measure of received power. Maybe there's
more to it. The man pages for wavemon don't indicate.

If so, I would suggest disabling the internal WiFi, and using the
stronger signal you get from the USB adapter

In effect, that's what I've done. I'd still like to understand why
it was necessary.

Thanks for writing,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

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?

No, the only measure I have is wavemon running on the Pi5. It would
be nice to ask the access point what it can see, but that feature is
not offered, AFAIK.

When ifconfig takes the unused interface down wavemon stops reporting
for it. At the moment there's a mismatch between what wavemon reports
and what the GUI stataus indicator of the Pi5 reports. The latter states
that both internal and external wifi interfaces are present and active,
but ifconfig shows only the external wifi interface active with an IP
number. The GUI indicator is also greyed out, as if historical.

Between what ifconfig reports and wavemon displays I tend to think
the unused interface is inactive. However, I'm not certain.

Thanks for writing!

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 16:30, bp@www.zefox.net wrote:

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

7C:9A:54:FC:7E:7F is a Tecnicolor CH USA device. Do you have any such
devices?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mm0fmf <none@invalid.com> wrote:

On 25/11/2024 16:30, bp@www.zefox.net wrote:

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

7C:9A:54:FC:7E:7F is a Tecnicolor CH USA device. Do you have any such 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 18:57, bp@www.zefox.net wrote:

mm0fmf <none@invalid.com> wrote:

On 25/11/2024 16:30, bp@www.zefox.net wrote:

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

7C:9A:54:FC:7E:7F is a Tecnicolor CH USA device. Do you have any such
devices?

It must belong to a neighbor. My AP is d-link.zefox.net, a DI-524.

And that is its SSID?

I didn't think you could put full stops in an SSID

Oh. The spec says you can. Other people suggest that some clients cannot
deal with odd characters.

What motivates the question?

Thanks for writing,

bob prohaska

--
Microsoft : the best reason to go to Linux that ever existed.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 16:30, bp@www.zefox.net wrote:

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

That's a Nokia device. Possibly a smart phone being used as an access point

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

Those are all MAC addtreses from Vantiva, which sells broadband .
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 ESS d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS

That's a pi set up badly I think

The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.

I didn't see your access point in there at all.

What is its SSID?

Anybody got an idea what's going on?

Thanks for reading!

bob prohaska

--
“It is hard to imagine a more stupid decision or more dangerous way of
making decisions than by putting those decisions in the hands of people
who pay no price for being wrong.”

Thomas Sowell

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 25/11/2024 16:30, bp@www.zefox.net wrote:

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

That's a Nokia device. Possibly a smart phone being used as an access point

d-link.zefox.net 00:13:46:86:6D:0C 96%, -43 dBm, ch 2, 2417 MHz ESS

Thats a Pi set up badly

Please elaborate!

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

Those are all MAC addtreses from Vantiva, which sells broadband .
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 ESS
d-link.zefox.net 00:13:46:86:6D:0C 97%, -42 dBm, ch 157, 5785 MHz ESS

That's a pi set up badly I think

The MAC address is that of my access point, but that access point is limited to 2.4 GHz.
The router supports only one LAN IP range AFAIK.

The last two entries appear to be duplicates of the second, with a wrong frequency attribution: my
AP can't use 5 GHz.

I didn't see your access point in there at all.

What is its SSID?

d-link.zefox.net

I'm connected and typing via it now.

Thanks for writing,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

mm0fmf <none@invalid.com> wrote:

On 25/11/2024 18:57, bp@www.zefox.net wrote:

What motivates the question?

7C:9A:54 is a Technicolor MAC address

Sorry, but I still don't understand the significance of that fact.... Presumably a neighbor has the device, not me. Just to be clear, the
table of signals is what my Pi could potentially connect to nearby.

Thanks for writing,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 18:57, bp@www.zefox.net wrote:

What motivates the question?

7C:9A:54 is a Technicolor MAC address

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24/11/2024 18:50, bp@www.zefox.net wrote:

I'm a little surprised that two interfaces are worse than one.

Has anybody else seen this behavior?

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 you set up the access point with a different SSID for each frequency,
and connect an interface to each, you might get a small amount of
additional bandwidth, but not a much as if you had two 5GHz access
points on different frequencies and SSDs.

---druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25/11/2024 19:54, bp@www.zefox.net wrote:

Sorry, but I still don't understand the significance of that fact....

It's called logical deduction. You should try it sometime.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-25, The Natural Philosopher <tnp@invalid.invalid> wrote:

I didn't think you could put full stops in an SSID

You can even put UTF-8 characters (like emojis) in the SSID (it's an
extension, the AP must support that) - my guest network has those, and the clients I tested (Windows 10, Linux, Android) worked just fine.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 - there is some collision probability, but usually,
aggregated bandwith does not drop by a huge amount.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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.

--
The lifetime of any political organisation is about three years before
its been subverted by the people it tried to warn you about.

Anon.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/11/2024 14:54, Michael Schwingen wrote:

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.

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.

*However* routing with more than one interface active is complex,
especially if they connect to the *same* network.

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.

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.

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



--
“Some people like to travel by train because it combines the slowness of
a car with the cramped public exposure of 
an airplane.”

Dennis Miller

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/11/2024 16:28, bp@www.zefox.net wrote:

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.

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?

Thanks for writing,

bob prohaska

--
Climate is what you expect but weather is what you get.
Mark Twain

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher wrote:

Michael Schwingen wrote:

The Natural Philosopher wrote:

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.

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

... per route table.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

bp@www.zefox.net wrote:

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.

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.

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27 Nov 2024 10:45:57 GMT, Michael Schwingen wrote:

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

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 27 Nov 2024 19:27:35 +0000, Andy Burns wrote:

The Natural Philosopher wrote:

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

... per route table.

Multiple routing tables comes in with policy routing <https://manpages.debian.org/8/ip-rule.8.en.html>.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.


--
Climate Change: Socialism wearing a lab coat.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 27/11/2024 17:38, bp@www.zefox.net wrote:

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

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.

--
For in reason, all government without the consent of the governed is the
very definition of slavery.

Jonathan Swift

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

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

---druck

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 28 Nov 2024 19:50:40 GMT, Michael Schwingen wrote:

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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/11/2024 13:07, Michael Schwingen wrote:

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

--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/11/2024 16:44, Michael Schwingen wrote:

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.

There probably is, we just do not know what it is...

All I know is that my onboard Pi Wifi problems were resolved with a
better PSU.



--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/11/2024 13:45, Michael Schwingen wrote:

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

--
Truth welcomes investigation because truth knows investigation will lead
to converts. It is deception that uses all the other techniques.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-11-29, The Natural Philosopher <tnp@invalid.invalid> wrote:

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

"I'm a Linux geek. My machines crash about as often as I get laid."

--
/~\ Charlie Gibbs | Growth for the sake of
\ / <cgibbs@kltpzyxm.invalid> | growth is the ideology
X I'm really at ac.dekanfrus | of the cancer cell.
/ \ if you read it the right way. | -- Edward Abbey

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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/

;-)

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/11/2024 19:30, Michael Schwingen wrote:

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/

;-)

Love that movie.

--
Canada is all right really, though not for the whole weekend.

"Saki"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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




--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 29/11/2024 23:13, bp@www.zefox.net wrote:

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.

I got sag when USB was drawing current I think.

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.

Fingers crossed.

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

Reminds me of that old BT advert where an old lady discovers her phone
isn't working. Cut to engineers in vans climbing poles, remaking
connections and so on, cut to old lady lifting the handset 'Oh, its
fixed itself!'...



--
“It is dangerous to be right in matters on which the established
authorities are wrong.”

― Voltaire, The Age of Louis XIV

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The Natural Philosopher <tnp@invalid.invalid> wrote:

On 29/11/2024 23:13, bp@www.zefox.net wrote:

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.

I got sag when USB was drawing current I think.

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.

Fingers crossed.

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

Through this morning the networking functioned normally. Then I noticed a
batch of new system updates. After installing and rebooting the trouble returned, slightly worse. Now the internal wifi simply fails to connect.
The external usb-wifi adapter works as expected. I'm again seeing failures reported for networkmanager-wait-online, but don't understand what they mean.

Looking through journalctl output, filtered for wlan0, I see a torrent of output, some of which states:

Nov 30 09:19:00 raspberrypi NetworkManager[852]: <warn> [1732987140.7820] device (wlan0): Activation: (wifi) association took too long
Nov 30 09:19:00 raspberrypi NetworkManager[852]: <info> [1732987140.7821] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed')
Nov 30 09:19:00 raspberrypi NetworkManager[852]: <warn> [1732987140.7826] device (wlan0): Activation: failed for connection 'Wi-Fi connection 1'
Nov 30 09:19:00 raspberrypi NetworkManager[852]: <info> [1732987140.7828] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed')

The mismash of reasons looks inconsistent to me.

The only changes have been disconnecting and reconnecting the usb-wifi
dongle, right now it's connected and the gpio is showing 5.08 volts. I
suspect the small fluctuations seen reflect line voltage drift more
than load.

In any case, I've now navigated successfully from the frying pan back
to the fire 8-)

Thanks for reading,

bob prohaska

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 29 Nov 2024 13:27:40 +0000, The Natural Philosopher wrote:

The point being wifi is as shit as coaxial ethernet was, and should be avoided if at all possible

I find it hard to disagree. ;)

I have Ethernet connections running into both my bedroom and living room.
The wi-fi is fine for basic web browsing (not including watching videos),
but anything more traffic-intensive, and I plug the nearest handy cable
into my laptop.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)