Pppd killed on signal 15 after reconnect, repeatedly

Without looking at the details, that smell a bit like issues with DHCP timeouts, I would just expect to see DHCP failure messages in the log, when the old IPv6 “grants” expire and new one’s can not be acquired. Again, this is not a real diagnosis, but rather a gut-feeling.

Afaik there was no default WAN6 interface. What i did was make a custom eth0.6 WAN in Luci. Then ''use builtin IPv_6 management “” in the advanced section, [force link on] , Obtain IPv-6-Adress on Automatic, and then it makes WAN_6 by itself. Zero configuration on my part on the ipv6 side.

1 Like

Is a known issue and indeed not relevant, it just makes log reading a bit more fun.

In the WAN settings try with LCP Echo Intervall = 10 or auto , it may stabilise the line and cause less interrupts.


That is then contrary to the documentation, those two links above, plus here is another one https://openwrt.org/docs/guide-user/network/wan/isp-configurations that stipulates the same setting for most of the cited ISP specific configurations.


That is not what is said or implied but is nonetheless real, even if a marginal use case.


An ISP may suffer scarcity of IPv4 address blocks/space and during such time choose ds-lite for some subscribers but not for all. Then the ISP might be able to procure additional IPv4 space and switch users to ds-full via CPE settings.

Whether to tag the ISP as incompetent is not my call to make.


They could, but for reasons of their own they may not and prefer their sponsored CPE to be configured via TR-069 instead.


ds-lite appears to be probing certain criteria, including detection of an AFTR device on the ISP end and if successful deploys the

1 Like

Thanks, I will try to test this this weekend, if the rest of the family is in the mood to accept me playing with the router and the internet disappearing, that is.

IIRC the goal is to do the right thing out of the box for ds-lite, as otherwise users stuck with ds-lite will have no meaningful internet access at all, but that comes at a cost… Some years ago, by default OpenWrt doid not do the right thing for PPPoE/DHCPv6 out of the box (no IPv6 connectivity) but that was accepted back then, do to no IPv6 by default was considered less problematic than no effective internet at all. But the defaults from back then got canged along the way, IIRC. So they might differ quite a lot between the different TOS versions.

IPv4 still works, if that is meaningful. But there is another (sideline) issue with ds-lite which users are mostly unaware of and require manual intervention https://openwrt.org/docs/guide-user/network/ipv6_ipv4_transitioning

ds-lite operation requires that IPv4 NAT is disabled. You should adjust your settings in /etc/config/firewall accordingly.


is probably too much of corner case for the developers to be bothered. It was mentioned on the OpenWrt forum and someone suggested a toggle.


Just in case the node is still on TOS3.x mind that netifd is hopelessly outdated (and can be wonky at times) compared to current stable OpenWrt. And TOS4.x (based on EoL OpenWrt 18.06.x) is not up to speed either.

That was not the case back then, the decision IIRC was between borking ds-lite completely or forcing PPPoE/DHCPv6 users to having to manually configure IPv6. But things have changed, I gave this as history perspective to understand waht motivated the OpenWrt defaults.

I am not sure that that is actually correct, one can stack as many NAT layers as one is wil;ing to navigate though…

In the case of concurrent ds-lite and dualstack, I agree, but ds-lite better just works out of the box, otherwise most DOCSIS users will have an unhappy first experience with OpenWrt.

Thanks! I switched to TOS5 when it was in HBK (IIRC) and before that had used TOS4, so I should be reasonably up to date, or rather test the soon to be current default configuration :wink:

It is correct in light of the design of ds-lite but exploring the reasoning in this thread would be digressing from the issue at hand.

Mmmh, RFC6333 phrases this as “A DS-Lite CPE SHOULD NOT operate a NAT function between an internal interface and a B4 interface, as the NAT function will be performed by the AFTR in the service provider’s network. This will avoid accidentally operating in a double-NAT environment.”
So you are right that the ds-lite design does not want NAT there, but I maintain that this is not the same as a hard requirement (which in IETF lingo would be either a MUST or MUST NOT), I also agree that this is getting off-topic fast, so I concede your point.

Sorry for my delay.
Even after half an hour I am loosing IPv6.
Refresh the WAN interface than it is back.
I have try to play with the LCP Echo parameters but the Effect is the same.

From mybpointbif you nothing will fix the issue and I can’ t spend so many time to fix the issue and I don’ t want to stress your support here.
Maybe the failure is in another area …
I have used a FritzBox before and there was a setting from the ISP the IPv6 is Unique by the FB (I don’t know exactly der wording). Maybe the ISP has the problem but I am sure they provides IPv6.
What is the affect when IPv6 is not working?
In the moment I don’t use VPN connection and IPv4 is still activ.
Is there any risk?
Sure, later must be work. Maybe with the next update.
Otherwise I must go back to the FritzBox or another router. Nothing what I want to do :slight_smile:

These come only into play for the ppp-tunnel, unless the ppp link comes and goes changing these parameters should not effect the IPv6 side of things, but you should get nice and normal PPPoE reconnects.

This is a bit curious since the ISP provides the IPv6 via DHCPv6 and it is unclear from the logs why netifd sees it fit to disconnect the wan_6 interface. Debugging would require an investment in time/effort.

Unless mistaken your node is on TOS4.x, which is stale in regards to code development for some time. TOS5.x may not exhibit the issue.


  • IPv6 upstream (WAN) connectivity not working, instead traffic will be IPv4 only.
  • slight delay in WAN connectivity caused by inital IPv6 connectivity attempts then falling back to IPv4
  • but real problem that the pppoe session gets restarted and that will cause intermittent interruptions in WAN connectivity (also IPv4)

There might be however still a misconfiguration on the ISP back-end such as been observed here https://forum.openwrt.org/t/pppoe-disconnects-every-few-hours/61239

Unfortunately however

and therefore not due to arrive in TOS for another couple of months.

Makes sense to flash the TO with the latest OS 5.xx?
It is stable enough for the daily work?

Here the config from the FB before:

Allocate Unique local adress if no IPv6 internet connection existing (Translation).

Maybe here is also a fault?
With the FB IPv6 was working!

If the IPv6 function not working than I have a problem what I have understood.
Than I need an alternative solution.

What is strange and I don`t understand these: In the LuCi UI I see for WAN an IPv6 address.
When IPv6 is not working why I have this address?

No need to flash the router, with TOS4.x = HBS branch (as of today) just switch the branch to HBT. To move back and forth between the branches schnapps rollback can be used.


Is unrelated - ULA IPv6 address space is sort of the equivalent to the IPv4 private address space.

You can check the router’s own ULAs assigned with ip a - look for the inet6 fd30:... entries.


On the WAN side or the LAN side? For LAN IPv6 connectivity the ULA address space works independently from the WAN’s GUA address space and any intermittent interruption on the WAN does (should) not cause any issue on LAN traffic.


The the interruption period in WAN connectivity (from your last log) lasts from 07:28:09 to 07:28:22 and LuCI does not refresh its UI every second, you just may not catch the interruption on LuCI (assuming the auto refresh in LuCI is enabled in the first place, if not then there would no status change of the interfaces at all).

I have now switch to the HBT brunch.
I will see what is the influence.

For the moment looks OK:

root@turris:~# check_connection Pinging 84.46.104.215 ... OK IPv4 Gateway: OK Pinging 217.31.205.50 ... OK Pinging 198.41.0.4 ... OK Pinging 199.7.83.42 ... OK Pinging 8.8.8.8 ... OK IPv4: OK Pinging fe80::aa9d:21ff:fee1:7f00%pppoe-wan ... OK IPv6 Gateway: OK Pinging 2001:1488:0:3::2 ... OK Pinging 2001:500:3::42 ... OK Pinging 2001:500:2d::d ... OK Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... OK IPv6: OK Resolving api.turris.cz ... OK Resolving www.nic.cz ... OK Resolving c.root-servers.net ... OK DNS: OK Resolving www.rhybar.cz ... OK DNSSEC: OK

What is interessting: The Check in Foris is also OK but if I check in an internet side like the following than is IPv6 NOK.
How can be this?

This is different to the HBS brunch.
When the TO test was NOK than was the internet test also NOK and was die internal test OK than was the internet test also OK.

disconnect the client from the router for say 30 sec and then reconnect, should clear the GUA IPv6 lease on the client. Clear the browser cache, run test again.


:crossed_fingers:

Ok, back to the root.
I am loosing again IPv6.

:frowning:

I am desperate!

Too bad and unfortunate.

If it is the ISP’s fault similar to this one

you would have jump through the same debugging hoops.

Alternatively you could stick with WAN IPv4 connectivity only until someone would bother to backport the kernel patch for that issue or wait for kernel 5.4 to arrive in TOS and see then whether it gets sorted.

Else you could,

  • see if changing the cable between the router and the FTTH unit helps, if the current cable is an unshielded Cat5 | 5e try with a shielded CAT6 | 6a or Cat 7 | 7a | 8.1 cable instead
  • follow the support procedure https://docs.turris.cz/basics/support/ and take it up with support, or
  • invest time/effort to provide more verbose debugging logs and hope to get it resolved through this community forum.

Next step: I have order new Cat7 cable.

…but I think the issue is on the ISP side.
I have found a thread with the same ISP and the same issue.

https://board.wtnet.de/viewtopic.php?t=9193

Sorry for the German language.

Hi,
Yesterday I had for the whole day IPv6 connectivity.
I don’t know why.
I’ve wrote to my ISP. No answer for the moment.
Today, latest tomorrow I will replace the cable with an Cat 7 double shielded. Temporary I’ve place Cat 6 and I think it’s also protected.
Today the same story like beginning of this thread.
I get the connection and after an half hour I lost IPv6.
It’s not stable.
I think the reason is not the TO router I think it’s depend to the ISP and maybe the the configuration.