If you can keep an eye on it through ssh cli logread -f, it should provide some telltale
I am sure if I reboot the TO than it works.
Just right now it dosen’ t work
Shith happened.
with logread -f you would be reading actual log events in real time pertinent to
One more thing - is the instability of IPv6 connectivity observed on the router itself or happen on a client connected to the router? If latter it would be not uncommon since clients often retain public IPv6 lease and would only refresh the lease when either the lease time is expired or being disconnected for say 30 seconds from the router.
Wow. Why don’t you delete the other one? Why you are removing it in the first place? There is button disable and/or edit, right? I am sure that then you will help users who follow your advice with WAN tab in Foris/ReForis that it crashes. But you are using two interfaces to configure it and it might leads to some conflicts or issues.
How did you come to this conclusion? This depends on the workflow and configuration of the device. If you want router mode, then you expect that there is a WAN6 interface as well, right?
https://openwrt.org/docs/guide-quick-start/starterfaq
Note that there is a “WAN” and “WAN6” interface. Each of the 2 WAN interfaces holds config data related to the upstream interface (WAN is for IPv4 and has “DHCP client”, while WAN6 is for IPv6 has “DHCPv6 client”). On the other hand “LAN” has both the config data for the downstream side for both IPv4 and IPv6 associated, so there is no need to have an extra LAN6 interface. Also note that both an interface and a zone called “LAN” exist. Also “WAN” is used both as a name for a zone and as a name for the IPv4 WAN interface. Both the “WAN” and “WAN6” interface belong to the “WAN” zone (so furthermore there is no “WAN6” zone)
If set to automatic (as per OpenWrt default), which re/Foris implies
it should be coherent with netifd’s automatic mode that spawns then WAN_6 programmatically.
WAN6 in /etc/config/config is on the other hand a manual setting instead.
What crashes? If re/Foris crashes because of a setting in /etc/config/config pertinent to netifd then it should probably be looked into by development.
Well, you got two UI present on the system. Are you implying that the users should refrain from using LuCI because re/Foris might not be fully aligned and changes undertaken in LuCI could jeopardise re/Foris?
and there is with WAN_6 being spawned automatically by netifd, which is default OpenWrt setting [OpenWrt Wiki] IPv6
- auto: (default) enable IPv6 on the interface. Spawn a virtual interface wan_6 (note the underscore) and start DHCPv6 client odhcp6c to manage prefix assignment.
Why re/Foris diverts from that default and instead implements a manual setup is not for me to know.
If I understand correctly wan6 is OpenWrt’s preferred interface for IPv6, wan_6, is more of a backstop.
The likely problem is that nobody in their right mind had to expect an ISP offering both ds-lite and DualStack over the same link at the same time, with the end user having to actively choose. OpenWrt’s choosing ds-lite over DualStack by default unfortunately is not the right choice for the OP.
Good morning again 
Today I will run logread -f in the SSH cli and see what`s happened over the day.
Even I refresh the WAN interface than the IPv6 is available.
Than halt an hour or maybe one hour later it doesn`t work and no IPv6 is available.
Than I must refresh the WAN interface.
This seems to reproducible.
Today the Foris Updater offer me the package ds-lite
Uhm…i have a IPV6 & 4 provider, and this is my current working and stable MOX HBT setup with [active link on]
This is setup in Luci, in Foris or Reforis this does not work, since i also have a VLAN eth0.6 in the WAN config. Foris does not compute that, so stay in Luci.
1 Like
Mmmh, to get there, did you need to actively delete the default wan6 interface?
I have a similar situation with PPPoE for IPv4 and IPv6 via DHCPv6, but in my case traffic flows over wan6. I just looked, and I now see a spurious wan_6 interface as well, even though this does not show any traffic, while wan6’s traffic counters follow when I do ping -6 -c 10 gstatic.com… I wonder what is up with the wan_6, I had not noticed in the past (at one point I had deleted wan6 and used wan_6 exclusively, but I undid that months ago, and I am confident, that wan_6 did not show up back then, but have no proof, so I might just not have noticed).
I guess it is time to put the omnia into duty as main router and see what it will default to for IPv6 (but since it is a DualStack/PPPoE link without ds-lite being offered by the ISP my experience will have zero relevance for the ds-lite case)…
So, what I have write before.
I refresh the WAN interface for the connection to my ISP.
Than more or less 1/2 hour later I lost the IPv6 connection.
Right now I have refresh the WAN interface again and it works. IPv6 is available.
You can see this on the output from logread -f in the end.
root@turris:~# logread -f
Jun 3 06:19:20 turris odhcpd[2889]: DHCPV6 SOLICIT IA_NA from 0004c5932e8cb608acee96e95992f3a1d497 on br-lan: ok 2a02:2028:620:9a00::bdf/128 fdf3:1bd9:8262::bdf/128
Jun 3 06:19:21 turris odhcpd[2889]: DHCPV6 REQUEST IA_NA from 0004c5932e8cb608acee96e95992f3a1d497 on br-lan: ok 2a02:2028:620:9a00::bdf/128 fdf3:1bd9:8262::bdf/128
Jun 3 06:20:01 turris /usr/sbin/cron[28090]: (root) CMD (/usr/bin/notifier)
Jun 3 06:20:01 turris /usr/sbin/cron[28091]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:21:01 turris /usr/sbin/cron[28180]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 08:21:30 turris dnsmasq-dhcp[24512]: DHCPREQUEST(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c
Jun 3 08:21:30 turris dnsmasq-dhcp[24512]: Ignoring domain eu.auxxxx.int for DHCP host name ANG-OF-WL1xxx
Jun 3 08:21:30 turris dnsmasq-dhcp[24512]: DHCPACK(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c ANG-OF-WL1xxx
Jun 3 06:22:01 turris /usr/sbin/cron[28249]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:22:03 turris sshd[28244]: Accepted password for root from 192.168.1.3 port 50572 ssh2
Jun 3 06:23:01 turris /usr/sbin/cron[28323]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:24:01 turris /usr/sbin/cron[28387]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:25:01 turris /usr/sbin/cron[28452]: (root) CMD (/usr/bin/notifier)
Jun 3 06:25:01 turris /usr/sbin/cron[28453]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:26:01 turris /usr/sbin/cron[28758]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 08:26:03 turris dnsmasq-dhcp[24512]: DHCPREQUEST(br-lan) 192.168.1.228 58:9e:c6:20:47:cf
Jun 3 08:26:03 turris dnsmasq-dhcp[24512]: DHCPACK(br-lan) 192.168.1.228 58:9e:c6:20:47:cf N510-IP-PRO
Jun 3 06:27:01 turris /usr/sbin/cron[28824]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:28:01 turris /usr/sbin/cron[28887]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:29:01 turris /usr/sbin/cron[28959]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:30:01 turris /usr/sbin/cron[29025]: (root) CMD (/usr/bin/notifier)
Jun 3 06:30:01 turris /usr/sbin/cron[29028]: (root) CMD (/usr/bin/get-api-crl)
Jun 3 06:30:01 turris /usr/sbin/cron[29026]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:31:01 turris /usr/sbin/cron[29118]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:32:01 turris /usr/sbin/cron[29183]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:33:01 turris /usr/sbin/cron[29247]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:34:01 turris /usr/sbin/cron[29311]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:35:01 turris /usr/sbin/cron[29376]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:35:01 turris /usr/sbin/cron[29377]: (root) CMD (/usr/bin/notifier)
Jun 3 06:36:01 turris /usr/sbin/cron[29468]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:37:01 turris /usr/sbin/cron[29533]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:38:01 turris /usr/sbin/cron[29596]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:39:01 turris /usr/sbin/cron[29660]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:40:01 turris /usr/sbin/cron[29732]: (root) CMD (/usr/bin/notifier)
Jun 3 06:40:01 turris /usr/sbin/cron[29733]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:41:01 turris /usr/sbin/cron[29824]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:42:01 turris /usr/sbin/cron[29889]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:42:24 turris updater-supervisor: Running pkgupdate
Jun 3 06:42:25 turris updater[29916]: repository.lua.lua:43 (Globals): Target Turris OS: 4.0.5
Jun 3 06:42:31 turris updater[29916]: planner.lua:379 (pkg_plan): Package wpad is in cyclic dependency. It might fail its post-install script.
Jun 3 06:42:31 turris updater[29916]: planner.lua:379 (pkg_plan): Package hostapd is in cyclic dependency. It might fail its post-install script.
Jun 3 06:42:31 turris updater[29916]: planner.lua:358 (pkg_plan): Requested package pkglists-l10n-cs that is missing, ignoring as requested.
Jun 3 06:42:31 turris updater[29916]: planner.lua:358 (pkg_plan): Requested package pkglists-l10n-de that is missing, ignoring as requested.
Jun 3 06:42:31 turris updater[29916]: planner.lua:358 (pkg_plan): Requested package foris-storage-plugin-l10n-de that is missing, ignoring as requested.
Jun 3 06:42:31 turris updater[29916]: updater.lua:85 (Globals): Queue install of ds-lite/base/7-4.0
Jun 3 06:42:31 turris updater[29916]: src/pkgupdate/main.c:83 (approved): Approval request generated
Jun 3 06:42:31 turris updater-supervisor: pkgupdate reported no errors
Jun 3 06:43:01 turris /usr/sbin/cron[30036]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:44:01 turris /usr/sbin/cron[30100]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:45:01 turris /usr/sbin/cron[30167]: (root) CMD (/usr/bin/notifier)
Jun 3 06:45:01 turris /usr/sbin/cron[30166]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:46:01 turris /usr/sbin/cron[30256]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:47:01 turris /usr/sbin/cron[30321]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:48:01 turris /usr/sbin/cron[30384]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:49:01 turris /usr/sbin/cron[30447]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 08:49:29 turris dnsmasq-dhcp[24512]: DHCPREQUEST(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c
Jun 3 08:49:29 turris dnsmasq-dhcp[24512]: Ignoring domain eu.auxxxx.int for DHCP host name ANG-OF-WL1xxx
Jun 3 08:49:29 turris dnsmasq-dhcp[24512]: DHCPACK(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c ANG-OF-WL1xxx
Jun 3 06:50:01 turris /usr/sbin/cron[30514]: (root) CMD (/usr/bin/notifier)
Jun 3 06:50:01 turris /usr/sbin/cron[30513]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:51:01 turris /usr/sbin/cron[30612]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:52:01 turris /usr/sbin/cron[30676]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:53:01 turris /usr/sbin/cron[30740]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:54:01 turris /usr/sbin/cron[30803]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:55:01 turris /usr/sbin/cron[30869]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:55:01 turris /usr/sbin/cron[30868]: (root) CMD (/usr/bin/notifier)
Jun 3 06:56:01 turris /usr/sbin/cron[30959]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:57:01 turris /usr/sbin/cron[31022]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:58:01 turris /usr/sbin/cron[31086]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 06:59:01 turris /usr/sbin/cron[31152]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:00:01 turris /usr/sbin/cron[31218]: (root) CMD (/usr/bin/notifier)
Jun 3 07:00:01 turris /usr/sbin/cron[31221]: (root) CMD (/usr/bin/get-api-crl)
Jun 3 07:00:01 turris /usr/sbin/cron[31219]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:01:01 turris /usr/sbin/cron[31311]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:02:01 turris /usr/sbin/cron[31382]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:03:01 turris /usr/sbin/cron[31445]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:04:01 turris /usr/sbin/cron[31510]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:05:01 turris /usr/sbin/cron[32000]: (root) CMD (/usr/bin/notifier)
Jun 3 07:05:01 turris /usr/sbin/cron[32001]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:06:01 turris /usr/sbin/cron[32096]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:07:01 turris /usr/sbin/cron[32164]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:08:01 turris /usr/sbin/cron[32228]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:09:01 turris /usr/sbin/cron[32293]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:10:01 turris /usr/sbin/cron[32358]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:10:01 turris /usr/sbin/cron[32359]: (root) CMD (/usr/bin/notifier)
Jun 3 07:11:01 turris /usr/sbin/cron[32448]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:12:01 turris /usr/sbin/cron[32513]: (root) CMD (/usr/sbin/logrotate -s /tmp/logrotate.state /etc/logrotate.conf)
Jun 3 07:12:01 turris /usr/sbin/cron[32514]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:13:01 turris /usr/sbin/cron[32586]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:14:01 turris /usr/sbin/cron[32651]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:15:01 turris /usr/sbin/cron[32716]: (root) CMD (/usr/bin/notifier)
Jun 3 07:15:01 turris /usr/sbin/cron[32717]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:16:01 turris /usr/sbin/cron[339]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 09:16:48 turris dnsmasq-dhcp[24512]: DHCPREQUEST(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c
Jun 3 09:16:48 turris dnsmasq-dhcp[24512]: Ignoring domain eu.auxxxx.int for DHCP host name ANG-OF-WL1xxx
Jun 3 09:16:48 turris dnsmasq-dhcp[24512]: DHCPACK(br-guest_turris) 10.111.222.180 c8:d3:ff:6e:5e:7c ANG-OF-WL1xxx
Jun 3 07:17:01 turris /usr/sbin/cron[407]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:18:01 turris /usr/sbin/cron[470]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:19:01 turris /usr/sbin/cron[539]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:20:01 turris /usr/sbin/cron[608]: (root) CMD (/usr/bin/notifier)
Jun 3 07:20:01 turris /usr/sbin/cron[609]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:21:01 turris /usr/sbin/cron[700]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:22:01 turris /usr/sbin/cron[763]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:23:01 turris /usr/sbin/cron[829]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:24:01 turris /usr/sbin/cron[905]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:25:01 turris /usr/sbin/cron[983]: (root) CMD (/usr/bin/notifier)
Jun 3 07:25:01 turris /usr/sbin/cron[984]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:26:01 turris /usr/sbin/cron[1098]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:27:01 turris /usr/sbin/cron[1161]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:28:01 turris /usr/sbin/cron[1676]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:28:09 turris netifd: Interface 'wan_6' is now down
Jun 3 07:28:09 turris netifd: Network alias '' link is down
Jun 3 07:28:09 turris netifd: Interface 'wan_6' has link connectivity loss
Jun 3 07:28:09 turris netifd: Interface 'wan_6' is disabled
Jun 3 07:28:09 turris pppd[26396]: Terminating on signal 15
Jun 3 07:28:09 turris pppd[26396]: Connect time 76.6 minutes.
Jun 3 07:28:09 turris pppd[26396]: Sent 30619216 bytes, received 199639720 bytes.
Jun 3 07:28:09 turris netifd: Network device 'pppoe-wan' link is down
Jun 3 07:28:09 turris pppd[26396]: Connection terminated.
Jun 3 07:28:09 turris pppd[26396]: Connect time 76.6 minutes.
Jun 3 07:28:09 turris pppd[26396]: Sent 30619216 bytes, received 199639720 bytes.
Jun 3 07:28:09 turris pppd[26396]: Sent PADT
Jun 3 07:28:09 turris pppd[26396]: Exit.
Jun 3 07:28:09 turris netifd: Interface 'wan' is now down
Jun 3 09:28:09 turris kernel: [46550.347541] mvneta f1034000.ethernet eth2: Link is Down
Jun 3 07:28:09 turris netifd: Interface 'wan' is disabled
Jun 3 09:28:09 turris kernel: [46550.462085] mvneta f1034000.ethernet eth2: PHY [f1072004.mdio-mii:01] driver [Marvell 88E1510]
Jun 3 09:28:09 turris kernel: [46550.480426] mvneta f1034000.ethernet eth2: configuring for phy/sgmii link mode
Jun 3 09:28:09 turris kernel: [46550.487779] IPv6: ADDRCONF(NETDEV_UP): eth2: link is not ready
Jun 3 09:28:09 turris kernel: [46550.493696] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jun 3 07:28:09 turris netifd: Interface 'wan' is enabled
Jun 3 07:28:09 turris netifd: Interface 'wan' is setting up now
Jun 3 09:28:09 turris kernel: [46550.493822] IPv6: ADDRCONF(NETDEV_CHANGE): eth2: link becomes ready
Jun 3 07:28:09 turris insmod: module is already loaded - slhc
Jun 3 07:28:09 turris insmod: module is already loaded - ppp_generic
Jun 3 07:28:09 turris insmod: module is already loaded - pppox
Jun 3 07:28:09 turris insmod: module is already loaded - pppoe
Jun 3 07:28:09 turris pppd[1855]: Plugin rp-pppoe.so loaded.
Jun 3 07:28:09 turris pppd[1855]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
Jun 3 07:28:09 turris pppd[1855]: pppd 2.4.7 started by root, uid 0
Jun 3 07:28:10 turris netifd: Network device 'eth2' link is down
Jun 3 07:28:10 turris netifd: Interface 'wan' has link connectivity loss
Jun 3 09:28:10 turris kernel: [46551.634835] mvneta f1034000.ethernet eth2: Link is Down
Jun 3 07:28:12 turris netifd: Network device 'eth2' link is up
Jun 3 07:28:12 turris netifd: Interface 'wan' has link connectivity
Jun 3 09:28:12 turris kernel: [46553.711534] mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
Jun 3 07:28:15 turris pppd[1855]: PPP session is 8822
Jun 3 07:28:15 turris pppd[1855]: Connected to d4:6d:50:4e:81:d3 via interface eth2
Jun 3 09:28:15 turris kernel: [46556.007479] pppoe-wan: renamed from ppp0
Jun 3 07:28:15 turris pppd[1855]: Using interface pppoe-wan
Jun 3 07:28:15 turris pppd[1855]: Connect: pppoe-wan <--> eth2
Jun 3 07:28:18 turris pppd[1855]: Remote message: Welcome to wilhelm.tel BRAS-Service
Jun 3 07:28:18 turris pppd[1855]: PAP authentication succeeded
Jun 3 07:28:18 turris pppd[1855]: peer from calling number D4:6D:50:4E:81:D3 authorized
Jun 3 07:28:18 turris pppd[1855]: local LL address fe80::d9b6:18ae:9139:9951
Jun 3 07:28:18 turris pppd[1855]: remote LL address fe80::aa9d:21ff:fea5:7b00
Jun 3 07:28:18 turris pppd[1855]: local IP address 134.101.221.184
Jun 3 07:28:18 turris pppd[1855]: remote IP address 84.46.104.216
Jun 3 07:28:18 turris pppd[1855]: primary DNS address 213.209.104.220
Jun 3 07:28:18 turris pppd[1855]: secondary DNS address 213.209.104.250
Jun 3 07:28:18 turris netifd: Network device 'pppoe-wan' link is up
Jun 3 07:28:18 turris netifd: Interface 'wan' is now up
Jun 3 07:28:18 turris netifd: Network alias 'pppoe-wan' link is up
Jun 3 07:28:18 turris netifd: Interface 'wan_6' is enabled
Jun 3 07:28:18 turris netifd: Interface 'wan_6' has link connectivity
Jun 3 07:28:18 turris netifd: Interface 'wan_6' is setting up now
Jun 3 07:28:18 turris firewall: Reloading firewall due to ifup of wan (pppoe-wan)
Jun 3 07:28:21 turris firewall: Reloading firewall due to ifupdate of wan (pppoe-wan)
Jun 3 07:28:22 turris netifd: Interface 'wan_6' is now up
Jun 3 07:28:23 turris firewall: Reloading firewall due to ifup of wan_6 (pppoe-wan)
Jun 3 07:28:33 turris kresd[2558]: [ ta ] key: 20326 state: Valid
Jun 3 07:28:33 turris kresd[2558]: [ ta ] next refresh for . in 2.1251388888889 hours
Jun 3 07:29:01 turris /usr/sbin/cron[2934]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:30:01 turris /usr/sbin/cron[3073]: (root) CMD (/usr/bin/notifier)
Jun 3 07:30:01 turris /usr/sbin/cron[3076]: (root) CMD (/usr/bin/get-api-crl)
Jun 3 07:30:01 turris /usr/sbin/cron[3074]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
Jun 3 07:31:01 turris /usr/sbin/cron[3238]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
What I have observe is the internal time from TO and on the UI is different (2 hours) but I think this has no influence.
I`m sure it will works for 1/2 - 1 hour and than I lost again the IPv6.
If you look at pppoe portion in [OpenWrt Wiki] WAN interface protocols it states there too as default:
ipv6 [0,1,auto] no auto Enable IPv6 on the PPP link. See Protocol “ppp” above
and which setting spawns wan_6 programmatically, not as backstop of sorts.
It is however a real world scenario and commonly with ISP’s sponsored CPE, that often comes with a managerial backchannel, the subscriber would not have to be bothered since the ISP could manage settings remotely.
1 Like
Well, in my case traffic is routed vie wan6 as it should be, but I just looked and I also now have a wan_6. I am relatively sure I did not have that initially, when I switched back from wan_6 (to which I got by deleting wan6 on the broken theory that this would be the right thing; that did work, but as it turned out was/is not how OpenWrt IPv6 is supposed to work for PPPoE/DHCPv6 according to forum and mailing list posts, not sure about the ds-lite situation).
Is it? I really doubt that simultaneous ds-lite & dualstack is common at all. IMHO a competent ISP would configure end users to either dualstack or ds-lite, but not really both (with the OP didn’t the problem start with ds-lite not working properly in the first place).
Well, the ISP can already manage remotely what is offered to each enduser already by just configuring his servers correctly, no TR-069 or similar needed.
But all my annoyance aside, as the OP shows, ISPs can not be relied upon to always offer sane configurations, so OpenWrt/TOS needs to pick up the slack and allow user control what to use (if only be a specific override option, OpenWrt’s goal to do the right thing out of the box for most users does not need to be compromised)
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 [OpenWrt Wiki] 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 [OpenWrt Wiki] IPv4/IPv6 transition technologies
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 
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.