On 2026-06-15, Stuart Henderson <[email protected]> wrote: > On 2026-06-15, Jurjen Oskam <[email protected]> wrote: >> Hi, >> >> I recently switched to another ISP, and it uses PPPoE so I set things >> up using pppoe(4). This works fine about 50% of the time: after a >> reboot of the OpenBSD box there's a ~50% chance that the link comes up >> correctly. The strange thing is that IPv4 connectivity does *not* work >> in that case, while IPv6 connectivity (via dhcp6leased) *does* work. A >> tcpdump of IPv4 traffic on pppoe0 shows only outbound packets (TCP >> SYNs, UDP, etc), nothing coming back in. >> >> The PPPoE connection is from an Ethernet interface on my machine >> (igc1) directly to the ONT of the ISP. The ONT expects the PPPoE >> session on VLAN 6. The ISP has assigned a static IPv4 address. >> >> I suspect some sort of race condition occurring somewhere, but I >> wouldn't know where to start digging. What would be the best way of >> debugging this? > > pppoe starts trying to negotiate when the interface comes up > with whatever address families it knows about. IIRC changing the > available address families mid negotation can sometimes have issues. > > there's no proper way round it becausing with most interface types > (including pppoe), configuring an address or setting 'autoconf' (for > either v4 or v6) automatically brings the interface up at that point, > rather than when you explicitly use "up". > > some years ago dlg had some work to fix this in general (with the > compatibility case handled by netstart running "ifconfig up" in the > same situations that it would have been brought up anyway, but at > the end of configuring an interface rather than partway through) > but IIRC there were objections. > >> The hostname.if files: >> >> calvin# cat /etc/hostname.igc1 >> media 2500baseT mtu 1508 up > > unrelated but I don't recommend forcing media (which is also liable to > disable auto duplex, which could result in one side using half-duplex > and the other full-duplex, which is a pig to debug). autodetect is > generally the sane way. > >> calvin# cat /etc/hostname.vlan6 >> vnetid 6 parent igc1 mtu 1508 up >> calvin# cat /etc/hostname.pppoe0 >> inet 45.142.146.140 255.255.255.255 NONE \ >> pppoedev vlan6 authproto pap \ >> authname '[email protected]' authkey '1234' \ >> mtu 1500 up >> dest 0.0.0.1 >> inet6 autoconf eui64 >> !/sbin/route add default -ifp pppoe0 0.0.0.1 >> !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 > > try to do as little as possible in hostname.if between configuring the > v4 and v6 addresses. this does _not_ avoid the race but might mean that > you win it more often (maybe even consistently). this should be > equivalent to the file you have above: > > pppoedev vlan6 authproto pap authname '[email protected]' authkey '1234' mtu > 1500 > inet 45.142.146.140 255.255.255.255 0.0.0.1 > inet6 autoconf > !/sbin/route add default -ifp pppoe0 0.0.0.1 > !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0
p.s. there is also a race here where the route is added; the route with the 0.0.0.1 placeholder must be added _before_ the connection comes up, otherwise the remote side ip as seen in ifconfig will change from 0.0.0.1 to the remote's real address, at which point you can no longer add the 0.0.0.1 route. -- Please keep replies on the mailing list.
