Hello,
I found a strange behavior of the PPP subsystem since I updated to
OpenBSD 7.8.
First to set the stage, I am in Japan and use PPPoE to connect to my ISP.
The PPPoE equipment are part of the infrastructure of NTT that then
connect to your ISP.
When connecting to you PPPoE session, if you break the link and try to
reconnect too fast the link does not come up, there is something like a
timeout delay and it is also not good to hammer too much the PPPd.
So it is usual to use something like:
# ifconfig pppoe0 destroy; sleep 300; sh /etc/netstart pppoe0
You could also let the netstart retry until the timeout on NTT side
allows to reconnect.
Updating to 7.8 I had to reboot to reboot my box, and I let netstart it
do its job.
Here was the ifconfig output:
pppoe0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1454
description: External PPPoE
index 14 priority 0 llprio 3
dev: igc2 state: session
sid: 0x916d PADI retries: 1 PADR retries: 0 time: 00:00:10
sppp: phase terminate authproto pap authname
"[email protected]"
groups: pppoe egress
status: no carrier
inet 0.0.0.0 --> 0.0.0.1 netmask 0xffffffff
However, after a while I could see that my PPPoE link did not come back,
and the ifconfig output show something strange:
pppoe0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1454
description: External PPPoE
index 14 priority 0 llprio 3
dev: igc2 state: PADI sent
sid: 0x0 PADI retries: 1 PADR retries: 0
groups: pppoe egress
status: no carrier
inet 0.0.0.0 --> 0.0.0.1 netmask 0xffffffff
Did the sppp subprocess gave up on its own?
Was there a timeout on this before?
I do not remember having such trouble until now and I use this setup
since around OpenBSD 5.4
I had to reboot once more to strait things up, manually do a destroy
then a netstart again did not solve the problem.
