On 05/02/2026 14:04, Lars Poulsen wrote:
On 2026-02-04, The Natural Philosopher <tnp@invalid.invalid> wrote:
If you remember I had constricted a bridge from wifi to ethernet to act
as a bridged access point. On a PI 4B as a test platform
The problem was that whilst the bridge was reasonably OK accessing my
LAN, up to 90% packet loss was experienced when accessing the internet
via my edge router.
Two further points have been established but the exact reason for the
behaviour still remains a mystery
1/. A friend with a Pi 5 attempted to duplicate the setup, could not get >>> it to work and instead used the Network Manager˙ GUI to set up˙ a
(routed?) access point which worked ok. It turns out that you cannot use >>> the GUI tool to set up a bridge at all. Only nmcli.
2/. After a long time with traceroutes and pings I realised that this
particular machine was the *only one wired directly to the router via a
single gigabit Ethernet cable*. Everything else went via an ancient
100Mbps switch that I inherited from an office clearout. In a rash of
'well I tried everything else' I unplugged the Pi from the Gigabit
router socket˙ and put it into the 100Mbps switch and bingo!... Pretty
decent internet performance. Yes extremely long transfers sometimes
fail, but its very useable
What I cannot for the life of me understand is *why*˙ this worked. The
same [Gigabit] link was involved in both local and Internet access.˙ The >>> only difference being that local access ALSO went through a 100Mbps
switch.
If anyone can shed light on this I would appreciate it.
If it matters, the router is a Draytek Vigor2762Vac running PPPoE via an >>> Openrach ONT to an optical fibre for Internet and thence to the ISP.
The link-level connection involves a negotiation handshake to find
compatible parameters. You may read up on MII (Media Independent
Interface). When the state machines in the MII part of the MAC block in
the Ethernet part of your SoC chip encounters an MII state machine it
has not seen before, there may be timing dependent glitches.
One of our customers has an installation on a remote island where
the link between a microprocessor in his seismic gear connected via an
ethernet switch to our radio locks up every 6 to 12 months and needs a
remote-triggered power cycle to reset. We suggested he try another
switch next time he can get a service tech to the island.
It is also possible that a port data rate of a Gigabit may occasionally
cause bus contention on some internal data bus in the PI triggering
a bus error, while 100Mbps avoids that contention. I have seen such
bus contention cause glitches in memory controllers in a few systems
over my career.
Thank you for that.
Since the pi was always connected via the gigabit and the router
hardware, and performed well when then routed by an external switch,˙ it seems unlikely that it was the PI<=>router link that was at fault.
I am leaning more towards the router buffering Internet data into large Gigabit Ethernet bursts that overwhelmed the Pi when it was forwarding
to wifi. Limiting the data rate to 100Mbps allowed the Pis Ethernet to function well enough not to overload the wifi.
It was only the Internet<=>Router<=gigabit=>Pi4<=wifi=>client that broke
Without the wifi the ethernet was OK., Without the gigabit the wifi was OK.
Anyway I think we both agree that it is not something that can be
programmed around . I will test again when I get a Pi 5 and if it still sucks, a wifi access point is not that expensive. The Pi is also pretty crippled in wifi speed.
I suspect the˙ PI wifi hardware was never really designed for AP usage:
More for client access to a Wifi station.
I may try adding a wifi dongle at some point
If you remember I had constricted a bridge from wifi to ethernet to act
as a bridged access point. On a PI 4B as a test platform
The problem was that whilst the bridge was reasonably OK accessing my
LAN, up to 90% packet loss was experienced when accessing the internet
via my edge router.
Two further points have been established but the exact reason for the behaviour still remains a mystery
1/. A friend with a Pi 5 attempted to duplicate the setup, could not get
it to work and instead used the Network Manager GUI to set up a
(routed?) access point which worked ok. It turns out that you cannot use
the GUI tool to set up a bridge at all. Only nmcli.
2/. After a long time with traceroutes and pings I realised that this particular machine was the *only one wired directly to the router via a single gigabit Ethernet cable*. Everything else went via an ancient
100Mbps switch that I inherited from an office clearout. In a rash of
'well I tried everything else' I unplugged the Pi from the Gigabit
router socket and put it into the 100Mbps switch and bingo!... Pretty decent internet performance. Yes extremely long transfers sometimes
fail, but its very useable
What I cannot for the life of me understand is *why* this worked. The
same [Gigabit] link was involved in both local and Internet access. The only difference being that local access ALSO went through a 100Mbps switch.
If anyone can shed light on this I would appreciate it.
If it matters, the router is a Draytek Vigor2762Vac running PPPoE via an Openrach ONT to an optical fibre for Internet and thence to the ISP.
On 2026-02-04, The Natural Philosopher <tnp@invalid.invalid> wrote:
If you remember I had constricted a bridge from wifi to ethernet to act
as a bridged access point. On a PI 4B as a test platform
The problem was that whilst the bridge was reasonably OK accessing my
LAN, up to 90% packet loss was experienced when accessing the internet
via my edge router.
Two further points have been established but the exact reason for the
behaviour still remains a mystery
1/. A friend with a Pi 5 attempted to duplicate the setup, could not get
it to work and instead used the Network Manager GUI to set up a
(routed?) access point which worked ok. It turns out that you cannot use
the GUI tool to set up a bridge at all. Only nmcli.
2/. After a long time with traceroutes and pings I realised that this
particular machine was the *only one wired directly to the router via a
single gigabit Ethernet cable*. Everything else went via an ancient
100Mbps switch that I inherited from an office clearout. In a rash of
'well I tried everything else' I unplugged the Pi from the Gigabit
router socket and put it into the 100Mbps switch and bingo!... Pretty
decent internet performance. Yes extremely long transfers sometimes
fail, but its very useable
What I cannot for the life of me understand is *why* this worked. The
same [Gigabit] link was involved in both local and Internet access. The
only difference being that local access ALSO went through a 100Mbps switch. >>
If anyone can shed light on this I would appreciate it.
If it matters, the router is a Draytek Vigor2762Vac running PPPoE via an
Openrach ONT to an optical fibre for Internet and thence to the ISP.
The link-level connection involves a negotiation handshake to find
compatible parameters. You may read up on MII (Media Independent
Interface). When the state machines in the MII part of the MAC block in
the Ethernet part of your SoC chip encounters an MII state machine it
has not seen before, there may be timing dependent glitches.
One of our customers has an installation on a remote island where
the link between a microprocessor in his seismic gear connected via an ethernet switch to our radio locks up every 6 to 12 months and needs a remote-triggered power cycle to reset. We suggested he try another
switch next time he can get a service tech to the island.
It is also possible that a port data rate of a Gigabit may occasionally
cause bus contention on some internal data bus in the PI triggering
a bus error, while 100Mbps avoids that contention. I have seen such
bus contention cause glitches in memory controllers in a few systems
over my career.
On 5.2.2026 16.27, The Natural Philosopher wrote:
On 05/02/2026 14:04, Lars Poulsen wrote:
On 2026-02-04, The Natural Philosopher <tnp@invalid.invalid> wrote:
If you remember I had constricted a bridge from wifi to ethernet to act >>>> as a bridged access point. On a PI 4B as a test platform
The problem was that whilst the bridge was reasonably OK accessing my
LAN, up to 90% packet loss was experienced when accessing the internet >>>> via my edge router.
Two further points have been established but the exact reason for the
behaviour still remains a mystery
1/. A friend with a Pi 5 attempted to duplicate the setup, could not
get
it to work and instead used the Network Manager˙ GUI to set up˙ a
(routed?) access point which worked ok. It turns out that you cannot
use
the GUI tool to set up a bridge at all. Only nmcli.
2/. After a long time with traceroutes and pings I realised that this
particular machine was the *only one wired directly to the router via a >>>> single gigabit Ethernet cable*. Everything else went via an ancient
100Mbps switch that I inherited from an office clearout. In a rash of
'well I tried everything else' I unplugged the Pi from the Gigabit
router socket˙ and put it into the 100Mbps switch and bingo!... Pretty >>>> decent internet performance. Yes extremely long transfers sometimes
fail, but its very useable
What I cannot for the life of me understand is *why*˙ this worked. The >>>> same [Gigabit] link was involved in both local and Internet access.
The
only difference being that local access ALSO went through a 100Mbps
switch.
If anyone can shed light on this I would appreciate it.
If it matters, the router is a Draytek Vigor2762Vac running PPPoE
via an
Openrach ONT to an optical fibre for Internet and thence to the ISP.
The link-level connection involves a negotiation handshake to find
compatible parameters. You may read up on MII (Media Independent
Interface). When the state machines in the MII part of the MAC block in
the Ethernet part of your SoC chip encounters an MII state machine it
has not seen before, there may be timing dependent glitches.
One of our customers has an installation on a remote island where
the link between a microprocessor in his seismic gear connected via an
ethernet switch to our radio locks up every 6 to 12 months and needs a
remote-triggered power cycle to reset. We suggested he try another
switch next time he can get a service tech to the island.
It is also possible that a port data rate of a Gigabit may occasionally
cause bus contention on some internal data bus in the PI triggering
a bus error, while 100Mbps avoids that contention. I have seen such
bus contention cause glitches in memory controllers in a few systems
over my career.
Thank you for that.
Since the pi was always connected via the gigabit and the router
hardware, and performed well when then routed by an external switch,
it seems unlikely that it was the PI<=>router link that was at fault.
I am leaning more towards the router buffering Internet data into
large Gigabit Ethernet bursts that overwhelmed the Pi when it was
forwarding to wifi. Limiting the data rate to 100Mbps allowed the Pis
Ethernet to function well enough not to overload the wifi.
It was only the Internet<=>Router<=gigabit=>Pi4<=wifi=>client that broke
Without the wifi the ethernet was OK., Without the gigabit the wifi
was OK.
Anyway I think we both agree that it is not something that can be
programmed around . I will test again when I get a Pi 5 and if it
still sucks, a wifi access point is not that expensive. The Pi is also
pretty crippled in wifi speed.
I suspect the˙ PI wifi hardware was never really designed for AP
usage: More for client access to a Wifi station.
I may try adding a wifi dongle at some point
It may be as simple as the cable from your router to the Pi, if it
is a different one than with the switch. Verify that you're using
a CAT6 patch cable.
I'm running a Zyxel GS-1200 switch with gigabit ports to a Pi3B+
and WLAN bridging without extra problems. The WLAN in Pi is not
completely as good a radio than a dedicated WLAN base station,
due to different antenna systems.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 56 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 14:06:34 |
| Calls: | 771 |
| Calls today: | 1 |
| Files: | 1,226 |
| D/L today: |
3 files (2,998K bytes) |
| Messages: | 219,953 |