here). BT & manufacturer fixed that modem, but sadly the same bug seems to exist in other modems.
We're seeing this in some Zyxel modems now. I am pretty sure I have had reports of other modes as well. The problem is that it is not always obvious what the issue is, people turn things off and back on again, and that fixes it, so we do not always get clear reports of issues.
The issue is that the modem seems to have some sort of packet acceleration in the chipset - for what reason we cannot image - it seems that it caches around 254 different IP/port/protocol sets. This is a bit like header compression by the sound of it.
This means these cached headers are reconstructed, which is fine, if not for a bug. It seems that when passing PPPoE the IP/port/protocols are matched but the PPPoE ID field is not, yet this is part of what is reconstructed.
This means that on any fixed IP line (IP being an one of the things that needs not to have changed to hit the cache), a PPP restart leaves any packets matching the cache from the previous PPPoE session not working (they send down the line with the PPPoE ID of the previous session, and so are dropped).
For a lot of people this does not matter - dynamic IP has no issue, and even a lot of Internet traffic has different IP/ports, e.g. accessing web pages, so just work.
Sadly there are a number of protocols that easily break, including VPNs like IPsec, and VoIP. So a simple PPP restart on a line causes things not to work. The other issue is these protocols tend to keep trying. so the cache never clears or times out. It just stays not working.
Resetting the modem is one (slow) way to fix, but all it actually needs is the Ethernet port to be reset - just un-plug the cable and re-plug. This causes the modem to clear the cache (why do this on a port reset and not on seeing a PADI, I have no idea, but bugs are funny like that).
When this was one modem and the issue was fixed, that was fine. Now it seems to be more modems, and not fixed, it needs some work arounds. So today I have added an Ethernet port reset feature to our FireBricks so that the port connected to the modem is reset for a second when PPPoE shuts down.
It is a bodge to work around someone else's bug, but it is a pragmatic step. It is in the latest FireBrick alpha release for testing.
P.S. Until now people have used the profile feature of the FireBrick to reset the port when needed because a VPN would not come up due to this modem bug. This is just how flexible the FireBrick is, but it was not easy to do for VoIP related issues, and so I felt it was time for some special code for this.
So it seems, from what I can tell, under UK GDPR... ✓ Banning someone from your service called "Dave" Yep, it seems GDPR does not ...
The ASR33, like most teletypes of the era, works at a fixed rate. It does 10 characters per second. It is 110 Baud, using 1 start, 8 data (i...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
I am using KiCad for PCB design, and it is pretty impressive, but KiCad version 6 has just been released. There are lots of small changes, b...