late pppoe address

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

late pppoe address

Jan Stary
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 0xffffffff
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

Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Jason McIntyre-2
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 0xffffffff
> 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

Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Jan Stary
Hi,

On Jun 06 17:46:35, [hidden email] 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 0xffffffff
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Todd C. Miller-3
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

Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Stuart Henderson
On 2020-06-06, Todd C  Miller <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Mihai Popescu-3
In reply to this post by Jan Stary
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.
Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Kenneth Gober
In reply to this post by Jan Stary
On Sat, Jun 6, 2020 at 11:57 AM Jan Stary <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Stuart Henderson
In reply to this post by Mihai Popescu-3
On 2020-06-07, Mihai Popescu <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: late pppoe address

Jan Stary
In reply to this post by Todd C. Miller-3
On Jun 06 11:30:46, [hidden email] 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