Hello, On Wed, 27 Jul 2022, at 20:19, Stuart Henderson wrote: > On 2022-07-27, void <[email protected]> wrote:
>> Was just building and installing a new kernel incorrect, in this context? > > No, the kernel is all you need for that patch. > > If userland had been needed, the instructions for the patch would > have told you what else to build. thanks for clarifying. > Was pppoe working before applying the patch, or had you not configured > it at that point? It was "working" (in that pppoe0 got connected), once, and that was after applying the patch. I had not fully configured the network at that stage. I was accessing via console cable, and had configured cnmac1 as the pppoe-associated interface, and hostname.pppoe0. After *many* PAD retries, it connected and I was able to ping 1.1.1.1 dmesg : http://void.f-m.fm.user.fm/openbsd/2022-07-27.dmesg.txt The connection has a /29 ipv4 and a /40 ipv6 (which peers with a /64). I left ipv6 out of the configuration to simplify things in the first instance. The cnmac0 interface is accessible from the dmz. # cat /etc/hostname.cnmac0 inet router.ip.add.ress 255.255.255.248 NONE # cat /etc/hostname.cnmac1 up mtu 1508 (I have tried it without the mtu 1508 as well) # cat /etc/hostname.pppoe0 inet 0.0.0.0 255.255.255.255 NONE mtu 1500 \ pppoedev cnmac1 authproto pap \ authname 'username@myisp' authkey 'mYpAssWord' up dest 0.0.0.1 !/sbin/route add default -ifp pppoe0 0.0.0.1 when not using mtu 1508 in cnmac0 the mtu 1500 statement was also removed from hostname.pppoe0 as per the pppoe manpage. # cat /etc/hostname.cnmac2 cat: /etc/hostname.cnmac2: No such file or directory # sysctl -a | grep forwarding net.inet.ip.forwarding=1 net.inet.ip.mforwarding=0 net.inet6.ip6.forwarding=1 net.inet6.ip6.mforwarding=0 When it wasn't connecting after 5-10 mins and I saw the PAD counter had clocked up, I powercycled the termination point, waited 30s for it to come back (no LOS light so indicating there was signal) and then rebooted the edgerouter. Problem was still happening. Then I configured an asus RT68-U to use pppoe, plugged that into the termination point, gave it the credentials for the connection and it connected in under a minute. The pppoe authentication method here was set to "auto". I did not successfully connect when it was explicitly configured to use chap or pap authentication, but that may have been because I didn't wait long enough. So I removed the asus from the line, plugged the edgerouter back in and this time ran tcpdump over the pppoe connection - using chap auth and then, changing to pap, rebooting and running tcpdump again. The ISP states we can use chap or pap. The auth creds have been checked on the asus and on the edgerouter and they're correct. Here's the tcpdumps with auth creds redacted. chap auth: http://void.f-m.fm.user.fm/openbsd/2022-07-27.pppoe0-tcp-dump-chap-auth-standard-mtu.txt pap auth: http://void.f-m.fm.user.fm/openbsd/2022-07-27.pppoe.log.pap.1508mtu.txt How can I debug this further? why is it terminating the request. thank you for looking at my query.
