PPPoE disconnects every few hours

[xerces8]

@ergamus

I have the same ISP and the same type of home connection that you do. But a different modem device. I'm also getting regular PPPoE disconnects. Sometimes it's stable for days, weeks and sometimes it will reset every 20m-4h or so.

Do you use OpenWRT to establish the PPPoE connection?

Anyway, I wrote a patch (for the pppoe kernel module) to ignore PADT packets sent to others, fixing the issue.

See https://bugzilla.kernel.org/show_bug.cgi?id=207597

[pythonic]

@xerces8

So the problem was as already suspected, that pppoe does not properly check if the received PADT packet belongs to its ppp session.

Do you have any idea what sort of equipment your ISP is using as the access concentrator (i.e. PPPoE server)?

I may have seen something like this in the past, where I would lose the PPPoE session randomly from minutes up to days (very rarely got more than 10 days, usually less than 96 hours). I tried an OPNSense setup (FreeBSD based) to see whether a different PPP code heritage changed things but saw the same behaviour. I haven't seen the same behaviour for some months and my current PPPoE session has now been up for just over 35 days, so I suspect either a software update or hardware change to my ISP's AC... (and I know what AC setup they were using while I was experiencing the issue).

[xerces8]

@pythonic

Do you have any idea what sort of equipment your ISP is using as the access concentrator (i.e. PPPoE server)?

Sorry, I don't.
I can do some simple checks (if you suggest any), but I'm just a regular customer.

[ergamus]

Awesome, thank you. I'll try this patch out when I build a new image for my router.

[xerces8]

Do report about your experience...
What type of router do you use?

[pythonic]

@xerces8

Sorry, I don't.
I can do some simple checks (if you suggest any), but I'm just a regular customer.

You'd have to ask, and you'd probably not be told (because security through obscurity ).

Have you submitted a ticket to your ISP reporting that you're receiving PADTs for a device other than yours? and the link is being terminated because of this? [I wouldn't tell them you're patching around it!]

I understand that the ISP equipment in use when I had similar symptoms was by Microtik but I don't know model numbers.

[xerces8]

@pythonic

Have you submitted a ticket to your ISP reporting that you're receiving PADTs for a device other than yours? and the link is being terminated because of this?

@xerces8

the ISP stated that removing (and replacing with own) their router is not a supported configuration

EDIT: I'll take a look if other "more sensitive" packets arrive.

[pythonic]

@xerces8

the ISP stated that removing (and replacing with own) their router is not a supported configuration

Fairly typical reaction unfortunately .

@xerces8

EDIT: I'll take a look if other "more sensitive" packets arrive.

Yes, if you can find other packets that you shouldn't be getting you can call that a security issue. ISP will probably try and duck that too based on above .

At least you have a solution! BTW, in case the kernel-land patch goes nowhere you might try sending the patch to OpenWrt so it could be incorporated pending a kernel resolution.

[xerces8]

@xerces8

I'll take a look if other "more sensitive" packets arrive.

There is a bunch of DNS, NTP, XMPP and some HTTPS packets visible (packets sent to some other MAC addr, it is the same MAC for the day, then it changes and packets for a different MAC addr start arriving).

[pythonic]

So a couple of days short of 6 weeks the random PPPoE drops have reappeared - now had 2 in 48 hours. Will have to see whether I can apply your patch to my firmware build to see whether it helps...

[xerces8]

The patch just adds two lines to the pppoe kernel module, so you can just build the module and insert it into the running OpenWRT system:

• stop ppp (it uses the kernel module when connected): ifdown wan
• rmmod pppoe
• insmod /root/new_module/pppoe.ko
• ifup wan

Just to be sure, you can use the verbose patch (" patch with debug output "), it prints a message when it is loaded (or first used, not sure), just so you can see that the patched module is in use (sometimes insmod loads the original module, from the /lib/modules/ folder, not sure why...).

Also note that you must use the stripped module file, not the one in the build folder! That one might crash your router.
Just compare md5sum of unchanged modules with the installed ones, to find the folder with the "correct" version.
(sorry for this if you are an openwrt build expert, it confused me on my first tries)

PS: the debug version also writes a log when a PADT is recevied, noting the destination address, so you can see of "wrong" packets arrive on your connection. (if they don't then the reason for your problem might be something else)

[xerces8]

The fix is in the queue for the linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

See:
5.4-stable patches https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=8c2ea82ce4afa19c35557dcc1875663843c9a24d
5.6-stable patches https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=193c9be96f7a387420631158675bc557892cb4c3
4.19-stable patches https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=bdaf671f9a65fedbc724704f4a3083fa1169de64

[xerces8]

And it was released 3 days ago (on 2020-05-20) in linux kernel versions 5.6.14, 5.4.42 and 4.19.124

[pythonic]

So far the couple of lost PPPoE sessions I've had since installing the patch in my firmware don't appear to be this issue but just no response to the maximum number of configured pings (was set at 3 pings at 5s intervals; have changed this to 7 pings at 3s intervals to see what happens...).

But I'm glad to see your patch make it into the Linux kernel anyway! Thanks and well done!

[fantom-x]

Not for 4.14: is the issue not present in that kernel?

[pythonic]

As far as I can tell, the issue is present in every kernel since PPPoE support was added until @xerces8's patch was accepted. I would suggest whoever's maintaining the 4.14 LTS kernel has elected not to incorporate it at this time. @xerces8's patch can easily be applied to the 4.14 kernel code (which is what I did) if you need the fix.

[xerces8]

Someone opened a bug about this issue for OpenWRT: https://bugs.openwrt.org/index.php?do=details&task_id=3149

As 19.07.3 was released recently, I would need to repatch/rebuild if I update.

Is there anything to do to help this patch land sooner into openwrt?

[pythonic]

Attaching a backport of the accepted kernel patch to the bug report is probably the only thing you can do that might see action.

[xerces8]

I asked the kernel mainatiner about including the patch into the 4.14 kernel.

See this email thread: https://lkml.org/lkml/2020/6/4/860

Maybe someone from here can answer the question in that message and test the patch on 4.14 (I did, but didn't do a clean job).

[fantom-x]

I can confirm that it applies and builds cleanly in 4.14.