Hello Michael,
> I'll be curious to know what product is at the other end.
After a few months we found the problem. The culprit for the wrong
session ID is not the Providers DSLAM or PPP, but the Zyxel ZyXEL
VMG1312-B30A or more specific:
> * https://support.aa.net.uk/VMG1312-B10A:_Bugs
>
Hello everyone,
* Thomas Glanzmann [2017-04-11 18:01]:
> another small follow-up in pppd 2.4.7 is [1]. When I manually hangup
> with this patch, all pending pppoe sessions are terminated as well.
> [1]
>
Hello Michael,
another small follow-up in pppd 2.4.7 is [1]. When I manually hangup
with this patch, all pending pppoe sessions are terminated as well.
[1]
https://github.com/paulusmack/ppp/commit/cd2c14f998c57bbe6a01dc5854f2763c0d7f31fb
Cheers,
Thomas
--
To unsubscribe from this list:
Hello Michael,
small follow up. Taking the link down on my site seems to reset the
pppoe session on the remote site. This symptom was probably triggered by
the reboot of the server.
--
(generate-03) [~] ping -c 5 172.17.0.254
PING 172.17.0.254 (172.17.0.254) 56(84) bytes of data.
---
Hello Michael,
> It sounds like they aren't part of the correct PPPoE session to me.
> As if the other end is not killing it's PPP session when the new one forms.
wow. You nailed it. Thank you for identifying the root cause. I'll open a call
with German Telekom to fix there ppp endpoint.
(x1)
Thomas Glanzmann wrote:
> The real interesting question is, why do perfectly healthy ip/udp
> packets from within the pppoe session drop before reaching ppp0? Why
> does it only happen after one hangup?
It sounds like they aren't part of the correct PPPoE session
Hello Michael,
* Michael Richardson [2017-04-10 22:02]:
> Are you using openvpn with a 0.0.0.0/0 route?
no, I don't.
> Can you post your routing table when it is working, and when it is
> not?
The routing table is the same:
(generate-03) [~] ip r s
default dev ppp0 scope