Solved: Loosing IPv6 default route after 30 minutes

Hi!

I have a Turris Omnia v3.6.1 as Internet Router for my Wilhelm.Tel FTTH access. The IPv4 Uplink is working fine with PPPoE but the IPv6 Uplink ceases working after 30 minutes.

What I have found so far is that the default route is deleted from the kernel 30 Minutes after the setting of the route:

# ip -ts -6 monitor label 1>>/var/log/ip-monitor.log &
# grep default.*via /var/log/ip-monitor.log 
[2017-04-02T12:57:35.639232] [ROUTE]Deleted default from 2a02:2028:51b:2b00::/56 via fe80::aa9d:21ff:fee1:7f00 dev pppoe-wan  proto static  metric 512 
[2017-04-02T13:14:13.247896] [ROUTE]default via 84.46.104.215 dev ppp0  proto static 
[2017-04-02T13:14:17.395220] [ROUTE]default from 2a02:2028:548:e100::/56 via fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 512 
[2017-04-02T13:44:18.388291] [ROUTE]Deleted default from 2a02:2028:548:e100::/56 via fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 512 
[2017-04-02T14:13:03.349801] [ROUTE]default via 84.46.104.215 dev ppp0  proto static 
[2017-04-02T14:13:06.761349] [ROUTE]default from 2a02:2028:548:e100::/56 via fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 4096 
[2017-04-02T14:13:07.394041] [ROUTE]default from 2a02:2028:548:e100::/56 via fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 512 
[2017-04-02T14:13:07.394210] [ROUTE]Deleted default from 2a02:2028:548:e100::/56 via fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 4096 
[2017-04-02T14:43:08.895168] [ROUTE]Deleted default from 2a02:2028:548:e100::/56 via  fe80::aa9d:21ff:fee1:7f00 dev ppp0  proto static  metric 512 

In the system logs is nothing relevant to find

2017-04-02T12:42:23+02:00 warning odhcpd[2155]: DHCPV6 RELEASE IA_NA from 000100011d9062ad0862664ce61d on br-lan: ok 2a02:2028:548:e100::22a/128 fd9c:9819:4c58::22a/128 
2017-04-02T12:42:55+02:00 warning odhcpd[2155]: DHCPV6 CONFIRM IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: not on-link 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T12:42:55+02:00 warning odhcpd[2155]: DHCPV6 SOLICIT IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: ok 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T12:42:56+02:00 warning odhcpd[2155]: DHCPV6 REQUEST IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: ok 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T12:43:01+02:00 info /usr/sbin/cron[31546]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
2017-04-02T12:43:02+02:00 warning odhcpd[2155]: DHCPV6 CONFIRM IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: not on-link 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T14:43:09+02:00 warning odhcpd[]: Last message 'DHCPV6 CONFIRM IA_NA' repeated 1 times, supressed by syslog-ng on turris
2017-04-02T12:43:09+02:00 warning odhcpd[2155]: DHCPV6 SOLICIT IA_NA from 000100011f5b4bd92c56dcd48687 on br-lan: ok 2a02:2028:548:e100::1c0/128 fd9c:9819:4c58::1c0/128 
2017-04-02T12:43:09+02:00 warning odhcpd[2155]: DHCPV6 SOLICIT IA_NA from 000100011d9062ad0862664ce61d on br-lan: ok 2a02:2028:548:e100::22a/128 fd9c:9819:4c58::22a/128 
2017-04-02T12:43:10+02:00 warning odhcpd[2155]: DHCPV6 CONFIRM IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: not on-link 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T12:43:10+02:00 warning odhcpd[2155]: DHCPV6 SOLICIT IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: ok 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T14:43:10+02:00 debug kernel[]: [1003207.672984] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=178.17.20.123 DST=84.46.35.158 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=382 DF PROTO=TCP SPT=28126 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 
2017-04-02T12:43:10+02:00 warning odhcpd[2155]: DHCPV6 REQUEST IA_NA from 000100011f5b4bd92c56dcd48687 on br-lan: ok 2a02:2028:548:e100::1c0/128 fd9c:9819:4c58::1c0/128 
2017-04-02T12:43:10+02:00 warning odhcpd[2155]: DHCPV6 REQUEST IA_NA from 000100011d9062ad0862664ce61d on br-lan: ok 2a02:2028:548:e100::22a/128 fd9c:9819:4c58::22a/128 
2017-04-02T12:43:11+02:00 warning odhcpd[2155]: DHCPV6 REQUEST IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: ok 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T14:43:13+02:00 debug kernel[]: [1003210.647454] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=178.17.20.123 DST=84.46.35.158 LEN=52 TOS=0x00 PREC=0x00 TTL=117 ID=401 DF PROTO=TCP SPT=28126 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 
2017-04-02T12:43:13+02:00 warning odhcpd[2155]: DHCPV6 RELEASE IA_NA from 000100011f5b4bd92c56dcd48687 on br-lan: ok 2a02:2028:548:e100::1c0/128 fd9c:9819:4c58::1c0/128 
2017-04-02T12:43:13+02:00 warning odhcpd[2155]: DHCPV6 RELEASE IA_NA from 000100011d9062ad0862664ce61d on br-lan: ok 2a02:2028:548:e100::22a/128 fd9c:9819:4c58::22a/128 
2017-04-02T14:43:19+02:00 debug kernel[]: [1003216.640397] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=178.17.20.123 DST=84.46.35.158 LEN=48 TOS=0x00 PREC=0x00 TTL=117 ID=422 DF PROTO=TCP SPT=28126 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 
2017-04-02T12:43:21+02:00 warning odhcpd[2155]: DHCPV6 CONFIRM IA_NA from 0004adfc3d22ee1f41b9403852c12de6e668 on br-lan: not on-link 2a02:2028:548:e100::960/128 fd9c:9819:4c58::960/128 
2017-04-02T14:43:30+02:00 debug kernel[]: [1003227.966379] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=185.98.90.221 DST=84.46.35.158 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=8078 DF PROTO=TCP SPT=53550 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 
2017-04-02T14:43:33+02:00 debug kernel[]: [1003230.505889] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=185.98.90.221 DST=84.46.35.158 LEN=52 TOS=0x00 PREC=0x00 TTL=114 ID=8103 DF PROTO=TCP SPT=53550 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 
2017-04-02T14:43:39+02:00 debug kernel[]: [1003236.500594] ucollect-fake-open-inet: IN=pppoe-wan OUT= MAC= SRC=185.98.90.221 DST=84.46.35.158 LEN=48 TOS=0x00 PREC=0x00 TTL=114 ID=8108 DF PROTO=TCP SPT=53550 DPT=80 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x80000 

The network config for wan6 looks like this:

network.wan6=interface
network.wan6.ifname='@wan'
network.wan6.proto='dhcpv6'
network.wan6.reqprefix='auto'
network.wan6.reqaddress='try'

EDIT: My provider send exactly one Router Advertisement with a validity time of 30 Min (1800 sec)

root@turris:/lib/netifd/proto# tcpdump -i pppoe-wan -n  -vvvv -ttt icmp6 and 'ip6[40] = 134'
tcpdump: listening on pppoe-wan, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
 00:00:00.000000 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::aa9d:21ff:fee1:7f00 > fe80::d:eaec:5225:3ca4: [icmp6 sum ok] ICMP6, router advertisement, length 24
	hop limit 64, Flags [managed, other stateful], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s
	  mtu option (5), length 8 (1):  1492
	    0x0000:  0000 0000 05d4

This will propagated with the /lib/netifd/dhcpv6.script to ubus which removes the route as soon as the validity time is up.

root@turris:~# ifstatus wan6
{
	"up": true,
[..]
	"route": [
		{
			"target": "::",
			"mask": 0,
			"nexthop": "fe80::aa9d:21ff:fee1:7f00",
			"metric": 512,
			"valid": 118,
			"source": "2a02:2028:541:3200::\/56"
		}
	],
[..]
}

Workaround: I have now added a /etc/odhcp6c.user which gets called after from /lib/netifd/dhcpv6.script on an update event. There I set the routes without any validity time checks…

# /etc/odhcp6c.user
logger -t odhcp6c.user INterface $1 State $2
# log env 
env | logger -t odhcp6c.user

routing () {

    if [ "$2" = "bound" ] ; then 
        for entry in $RA_ROUTES; do
                local duplicate=0
                local addr="${entry%%/*}"
                entry="${entry#*/}"
                local mask="${entry%%,*}"
                entry="${entry#*,}"
                local gw="${entry%%,*}"
                entry="${entry#*,}"
                local valid="${entry%%,*}"
                entry="${entry#*,}"
                local metric="${entry%%,*}"

                for xentry in $RA_ROUTES; do
                        local xprefix="${xentry%%,*}"
                        xentry="${xentry#*,}"
                        local xgw="${xentry%%,*}"

                        [ -n "$gw" -a -z "$xgw" -a "$addr/$mask" = "$xprefix" ] && duplicate=1
                done

                if [ -z "$gw" -o "$duplicate" = 1 ]; then
                        # proto_add_ipv6_route "$addr" "$mask" "$gw" "$metric" "$valid" "$paddr"

                        logger -t odhcp6c.user setting route 1: ip route add "$addr"/"$mask" via "$gw" dev $1 metric "1$metric"
                        ip route add "$addr"/"$mask" via "$gw" dev $1 metric "1$metric"
                else
                        for prefix in $PREFIXES $ADDRESSES; do
                                local paddr="${prefix%%,*}"
                                logger -t odhcp6c.user setting route 2: ip route add "$addr"/"$mask" via "$gw" dev $1 metric "2$metric" from "$paddr"
                                ip route add "$addr"/"$mask" via "$gw" dev $1 metric "2$metric" from "$paddr"
                        done
                fi
        done
    fi
}

routing $1 $2

I am not sure if my provider is wrong here of if the Turiss firmware has a bug here, but with the workaround I get IPv6 connectivity for more the 30 min :slight_smile:

cheerio
Steve

Hi Steffen,

thanks for sharing your experience with your provider and Turris Omnia!

I am facing the same problem with my ISP willy.tel (= Wilhelm.Tel), running Turris Omnia v3.6.2: My connection aslo refuses after 30min / 1800 sec…

Now since I just have started to experiment with OpenWrt and I am not very familar with any programming… Can we somehow verify that this is not a firmwarebug? Or other way arround - is this something that could be solved via some future firmware update? :slight_smile:

Thanks and greetings!,
Dave

My ISP is also Wilhelm.Tel (In fact Tel.Quick, but they have outsourced the technical stuff to Wilhelm.Tel), therefore it is quite possible that Wilhelm.Tel got that wrong :slight_smile: (Not the first time they fuck up their stuff…)