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.
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
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.
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
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
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)
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.
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
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.