When we get a PPP connection (over L2TP) one of the first things we do is a RADIUS request to authenticate. That provides the IP routing which may be single PPP link IPv4, blocks of IPv4, and blocks of IPv6. We even allow IPv6 tunneled to IPv4.
What we used to do is add the routes at that point in time, then negotiate PPP IPCP, and IPV6CP. When the session closed we did RADIUS STOP and then removed routing.
The RFC prohibits sending packets until IPCP or IPV6CP is complete and we had a check for that which dropped the packets.
We have made some changes which should come in later this week which makes the routing much more closely tied to the IPCP and IPV6CP state.
The main impact is bonded and fallback lines. The few seconds that can happen on IPCP and IPV6CP negotiation at the start, and for RADIUS STOP at the end, can mean routing is up but the link drops the traffic.
So the new plan is that immediately on IPCP ACK received we announce the IPv4 routes, and immediately on IPV6CP ACK received we announce IPv6 routes. IPv6 tunneled over IPv4 are on IPCP ACK as the PPP level traffic is IPv4.
We also drop the routes immediately on LCP TERM or L2TP CDN, before waiting for RADIUS STOP confirmation.
This should avoid even milliseconds of routing where there is no link.
Subtle, I know, but am improvement.
As previously posted , I am quite impressed with Shelly stuff anyway, but the new "Plus" range has allowed some interesting develo...
Broadband services are a wonderful innovation of our time, using multiple frequency bands (hence the name) to carry signals over wires (us...
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...
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...