Re: late pppoe address
On Jun 06 11:30:46, mill...@openbsd.org wrote: > On Sat, 06 Jun 2020 19:14:28 +0200, Jan Stary wrote: > > > Is the aim to let the ISP know that the iface is down, > > so that it gets set up afresh on boot, as opposed to > > waiting for some PPP keep-alive timeout? > > Basically. It is to work around an issue where the pppoe ethernet > interface goes down during reboot before the pppoe disconnect message > can be sent to the ISP. > > I'm not sure it is needed anymore, though I still have it in my own > rc.shutdown file. After a few reboots with and without that, I can confirm that having 'ifconfig pppoe0 down' in rc.shutdown noticeably speeds up getting an address assigned on the next boot. With my ISP, it's seconds as opposed to a minute or two. Thank you. Jan
Re: late pppoe address
On 2020-06-07, Mihai Popescu wrote: > Start address this problem to your ISP and ask it to remedy this stupid > implementation of pppoe on server side. Otherwise, you have to wait for it > and avoid spamming the list with your "i need to get this done quickly" > messages, please. Maybe it is time to employ a real expert on OpenBSD. Have you considered that it might not be the ISP's problem? OpenBSD's pppoe(4) is not perfect.
Re: late pppoe address
On Sat, Jun 6, 2020 at 11:57 AM Jan Stary wrote: > This is current/amd64 on an APU2. > The egress is XDSL pppoe(4) over vlan(4) over em(4), > > ... > > Are people having the same problem? > Are you doing something about the late ifconfig? > I have some routers that connect to DSL using pppoe(4) and yes, I have the same problem with delayed startup. For me the impact is to isc_named and openvpn, but the result is similar -- a lot of logged errors, mostly due to inability to resolve names until the pppoe link comes up. A somewhat more difficult problem is that ospfd fails to start at all under these conditions (I have it listening for routes over the vpn links, and ospfd won't start if those links are down). I don't do anything at startup to address this, because the DSL is also prone to dropping at other times for other reasons. I considered using ifstated to fix it, but found it more expedient to simply use a cron job to "rcctl start ospfd" periodically, and to ignore everything else. Ignoring everything else works because most things resolve themselves when pppoe negotiation finally completes. I am very happy that things just start working once the link comes up, and that manual intervention isn't needed. A few logged errors from software that is able to resume normal function on its own is very little burden compared to some alternatives. -ken
Re: late pppoe address
Start address this problem to your ISP and ask it to remedy this stupid implementation of pppoe on server side. Otherwise, you have to wait for it and avoid spamming the list with your "i need to get this done quickly" messages, please. Maybe it is time to employ a real expert on OpenBSD. Thank you.
Re: late pppoe address
On 2020-06-06, Todd C Miller wrote: > On Sat, 06 Jun 2020 19:14:28 +0200, Jan Stary wrote: > >> Is the aim to let the ISP know that the iface is down, >> so that it gets set up afresh on boot, as opposed to >> waiting for some PPP keep-alive timeout? > > Basically. It is to work around an issue where the pppoe ethernet > interface goes down during reboot before the pppoe disconnect message > can be sent to the ISP. > > I'm not sure it is needed anymore, though I still have it in my own > rc.shutdown file. I still have it in mine, not sure if it's needed or not either. I definitely needed it with a previous ISP who didn't seem to do LCP keepalives and hanged onto the session for ages (the alternative for that one was PPPOE_TERM_UNKNOWN_SESSIONS but the kernel-wrangling became annoying). Whether it will help or not depends on the reason for the delay. If it's just poor/slow ISP infrastructure there might be nothing much you can do other than wait for the interface to come up.
Re: late pppoe address
On Sat, 06 Jun 2020 19:14:28 +0200, Jan Stary wrote: > Is the aim to let the ISP know that the iface is down, > so that it gets set up afresh on boot, as opposed to > waiting for some PPP keep-alive timeout? Basically. It is to work around an issue where the pppoe ethernet interface goes down during reboot before the pppoe disconnect message can be sent to the ISP. I'm not sure it is needed anymore, though I still have it in my own rc.shutdown file. - todd
Re: late pppoe address
Hi, On Jun 06 17:46:35, j...@kerhand.co.uk wrote: > On Sat, Jun 06, 2020 at 05:56:56PM +0200, Jan Stary wrote: > > This is current/amd64 on an APU2. > > The egress is XDSL pppoe(4) over vlan(4) over em(4), > > as is the case with many European dialup telecoms. > > > > The connection itself works just fine (after some mss woes), > > but it takes some time to get assigned and IP address at startup. > > > > $ cat /etc/hostname.pppoe0 > > inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \ > > authproto 'pap' authname 'X' authkey 'PASS' up > > dest 0.0.0.1 > > inet6 eui64 > > !/sbin/route add default 0.0.0.1 > > !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 > > > > As per pppoe(4), the 0.0.0.0 and 0.0.0.1 get changed > > to my actual address (fixed) and the other end, respectively; > > routes get established, etc. > > > > My problem is that the delay is long enough > > to make some of the the early daemons choke: > > > > starting network > > add net default: gateway 0.0.0.1 > > add net default: gateway fe80::%pppoe0 > > starting early daemons: syslogd pflogd nsd(failed) unbound ntpd. > > > > nsd seems to get fixed using "ip-transparent: yes"; > > ntpd eventualy synchronizes after some "DNS lookup tempfail"s; > > but unbound spams /var/log/daemon with thousands of lines of > > > > unbound: [2895:0] notice: sendto failed: Permission denied > > unbound: [2895:0] notice: remote address is 178.17.0.12 port 53 > > > > as it tries in vain to contact its forwarders > > (or the root servers, if I don't specify forwarders). > > > > Eventually, it all falls into place, but is there a way > > to make the boot sequence wait for the pppoe IP address > > get assigned before moving on? I appended a lame > > > > !while ! ifconfig pppoe0 | grep -F 185.63.96.79; do date ; sleep 1; done > > > > to /etc/hostname.pppoe0, resulting in > > > > starting network > > add net default: gateway 0.0.0.1 > > add net default: gateway fe80::%pppoe0 > > Sat Jun 6 17:41:19 CEST 2020 > > Sat Jun 6 17:41:21 CEST 2020 > > [...] > > Sat Jun 6 17:42:53 CEST 2020 > > Sat Jun 6 17:42:54 CEST 2020 > > inet 185.63.96.79 --> 10.11.5.146 netmask 0x > > starting early daemons: syslogd pflogd nsd unbound ntpd. > > > > (The date is there purely for debug of course; > > it shows it took about a minute and a half this time.) > > > > Are people having the same problem? > > Are you doing something about the late ifconfig? > > > > Jan > > > > hi. > > although i haven't used pppoe for a little while, i definitely had the > same issue when i did (uk provider). i think i bugged another developer > to look at it (mpi?) but we never got far in working out a solution. > > sthen provided a workaround though: sth like "ifconfig pppoe0 down" in > /etc/rc.shutdown. i guess it's worth a shot... thank you for the tip. I just tried that, but it didn't make a difference. Is the aim to let the ISP know that the iface is down, so that it gets set up afresh on boot, as opposed to waiting for some PPP keep-alive timeout? Jan
Re: late pppoe address
On Sat, Jun 06, 2020 at 05:56:56PM +0200, Jan Stary wrote: > This is current/amd64 on an APU2. > The egress is XDSL pppoe(4) over vlan(4) over em(4), > as is the case with many European dialup telecoms. > > The connection itself works just fine (after some mss woes), > but it takes some time to get assigned and IP address at startup. > > $ cat /etc/hostname.pppoe0 > inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \ > authproto 'pap' authname 'X' authkey 'PASS' up > dest 0.0.0.1 > inet6 eui64 > !/sbin/route add default 0.0.0.1 > !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 > > As per pppoe(4), the 0.0.0.0 and 0.0.0.1 get changed > to my actual address (fixed) and the other end, respectively; > routes get established, etc. > > My problem is that the delay is long enough > to make some of the the early daemons choke: > > starting network > add net default: gateway 0.0.0.1 > add net default: gateway fe80::%pppoe0 > starting early daemons: syslogd pflogd nsd(failed) unbound ntpd. > > nsd seems to get fixed using "ip-transparent: yes"; > ntpd eventualy synchronizes after some "DNS lookup tempfail"s; > but unbound spams /var/log/daemon with thousands of lines of > > unbound: [2895:0] notice: sendto failed: Permission denied > unbound: [2895:0] notice: remote address is 178.17.0.12 port 53 > > as it tries in vain to contact its forwarders > (or the root servers, if I don't specify forwarders). > > Eventually, it all falls into place, but is there a way > to make the boot sequence wait for the pppoe IP address > get assigned before moving on? I appended a lame > > !while ! ifconfig pppoe0 | grep -F 185.63.96.79; do date ; sleep 1; done > > to /etc/hostname.pppoe0, resulting in > > starting network > add net default: gateway 0.0.0.1 > add net default: gateway fe80::%pppoe0 > Sat Jun 6 17:41:19 CEST 2020 > Sat Jun 6 17:41:21 CEST 2020 > [...] > Sat Jun 6 17:42:53 CEST 2020 > Sat Jun 6 17:42:54 CEST 2020 > inet 185.63.96.79 --> 10.11.5.146 netmask 0x > starting early daemons: syslogd pflogd nsd unbound ntpd. > > (The date is there purely for debug of course; > it shows it took about a minute and a half this time.) > > Are people having the same problem? > Are you doing something about the late ifconfig? > > Jan > hi. although i haven't used pppoe for a little while, i definitely had the same issue when i did (uk provider). i think i bugged another developer to look at it (mpi?) but we never got far in working out a solution. sthen provided a workaround though: sth like "ifconfig pppoe0 down" in /etc/rc.shutdown. i guess it's worth a shot... jmc
late pppoe address
This is current/amd64 on an APU2. The egress is XDSL pppoe(4) over vlan(4) over em(4), as is the case with many European dialup telecoms. The connection itself works just fine (after some mss woes), but it takes some time to get assigned and IP address at startup. $ cat /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE pppoedev vlan0 \ authproto 'pap' authname 'X' authkey 'PASS' up dest 0.0.0.1 inet6 eui64 !/sbin/route add default 0.0.0.1 !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 As per pppoe(4), the 0.0.0.0 and 0.0.0.1 get changed to my actual address (fixed) and the other end, respectively; routes get established, etc. My problem is that the delay is long enough to make some of the the early daemons choke: starting network add net default: gateway 0.0.0.1 add net default: gateway fe80::%pppoe0 starting early daemons: syslogd pflogd nsd(failed) unbound ntpd. nsd seems to get fixed using "ip-transparent: yes"; ntpd eventualy synchronizes after some "DNS lookup tempfail"s; but unbound spams /var/log/daemon with thousands of lines of unbound: [2895:0] notice: sendto failed: Permission denied unbound: [2895:0] notice: remote address is 178.17.0.12 port 53 as it tries in vain to contact its forwarders (or the root servers, if I don't specify forwarders). Eventually, it all falls into place, but is there a way to make the boot sequence wait for the pppoe IP address get assigned before moving on? I appended a lame !while ! ifconfig pppoe0 | grep -F 185.63.96.79; do date ; sleep 1; done to /etc/hostname.pppoe0, resulting in starting network add net default: gateway 0.0.0.1 add net default: gateway fe80::%pppoe0 Sat Jun 6 17:41:19 CEST 2020 Sat Jun 6 17:41:21 CEST 2020 [...] Sat Jun 6 17:42:53 CEST 2020 Sat Jun 6 17:42:54 CEST 2020 inet 185.63.96.79 --> 10.11.5.146 netmask 0x starting early daemons: syslogd pflogd nsd unbound ntpd. (The date is there purely for debug of course; it shows it took about a minute and a half this time.) Are people having the same problem? Are you doing something about the late ifconfig? Jan
