cancel
Showing results for 
Search instead for 
Did you mean: 
1

Ask

2

Reply

3

Solution

Terminating on signal 15

Scope
2: Seeker
2: Seeker

As of yesterday afternoon I have started getting disconnection on my 3rd Party Route (RPI5 running OpenWrt).. Its been running fine for week, but despite nothing changing on my side connection started dropping yesterday..

It will attempt to connect, with a number of these in the log:

Sat Aug 3 11:22:08 2024 daemon.info pppd[19804]: Plugin pppoe.so loaded.
Sat Aug 3 11:22:08 2024 daemon.info pppd[19804]: PPPoE plugin from pppd 2.4.9
Sat Aug 3 11:22:08 2024 daemon.notice pppd[19804]: pppd 2.4.9 started by root, uid 0
Sat Aug 3 11:22:08 2024 daemon.debug pppd[19804]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Aug 3 11:22:08 2024 daemon.debug pppd[19804]: dst ff:ff:ff:ff:ff:ff src 00:e0:xx:xx:38:a0
Sat Aug 3 11:22:08 2024 daemon.debug pppd[19804]: [service-name] [host-uniq 5c xx00 00]
Sat Aug 3 11:22:13 2024 daemon.debug pppd[19804]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
Sat Aug 3 11:22:13 2024 daemon.debug pppd[19804]: dst ff:ff:ff:ff:ff:ff src 00:e0:xx:xx:38:a0
Sat Aug 3 11:22:13 2024 daemon.debug pppd[19804]: [service-name] [host-uniq 5c xx00 00]
Sat Aug 3 11:22:14 2024 daemon.err pppd[19804]: select (waitForPADO): Interrupted system call
Sat Aug 3 11:22:14 2024 daemon.warn pppd[19804]: Timeout waiting for PADO packets
Sat Aug 3 11:22:14 2024 daemon.err pppd[19804]: Unable to complete PPPoE Discovery
Sat Aug 3 11:22:14 2024 daemon.info pppd[19804]: Exit.

And when it finally connects (usually every 5min or so) I get this in the log:

Fri Aug 2 23:31:26 2024 daemon.info pppd[4721]: Terminating on signal 15
Fri Aug 2 23:31:26 2024 daemon.info pppd[4721]: Connect time 2.0 minutes.

If I connect the router to another 3rd party router (R7800 running DD-WRT) it works fine.

Anybody else seeing this behaviour?

This is through Cityfibre.

6 REPLIES 6

Ripshod
16: Advanced member
16: Advanced member

About 4 years ago this was quite common with both OPENWRT and DD-WRT, and was initially triggered by an IPv4 and/or IPv6 update. IIRC the routers were trying to reconnect too quickly for the gateway.

Maybe add  "sleep 10" (without the quotes) to the config? How old is the version you're running? Why use a Pi? 

Im running the latest SNAPSHOT version, so bang up to date - I have also tried a version that is a few weeks old, which have been running since I initially installed it.

I chose the RPI because I wanted to try something different - its powerful enough to do a few things, support 1gig no problems (quite a few of the 3rd party routers struggle unless you turn on QSM and other offloading magic.. My R7800 required SFE enable in order for me to get full gig speed, and it recent times it has been unreliable.. Hence I wanted a fast enough CPU to cope with gig (+).. I've also had just about every RPI since its launch, so it was a good reason to get the latest. 😉

So this "sleep 10" you talk about, where do you suggest I add this?

Also, I wish I knew if Vodefone made any changes to things yesterday afternoon, so I can explain why it stopped working, rather than just trying all sort of workaround on a system that has been running fine for weeks.

Cynric
16: Advanced member
16: Advanced member

@Scope Snapshot could be too up-to-date. Did you try the most recent stable?

I see that there isn't an openwrt specifically for the Pi 5 listed.

It's a fair point, but it's been running fine for weeks, why the sudden change? 

The RPi5 is only supported by the Snapshot build so far, no stable release for it yet. 

Ripshod
16: Advanced member
16: Advanced member

Okay. Is it the same with the older final build? What happens when you put the vodafone router back? 

It was - same behaviour. 

Since then, with the above comment in mind, as well as other forums I frequent I have made the following change:

Scope_0-1722701538389.png

I have been testing slightly lower numbers aswell, but with keepalive set to "10 10" I have now been up and running for 1h 30m (and counting, so lets hope I dont jinx it now), by far longer than any time since yesterday afternoon.. Before this change the longest it stayed connected was 4 minutes.