Loosing IPv6 upstream after 30 minutes

Its a multicast problem.

Try adding one of these two lines to your /etc/rc.local (before the exit 0):

/sbin/ifconfig eth0 allmulti

Or

/sbin/ifconfig eth0 promisc

Replace eth0 if necessary with your WAN6 interface.

3 Likes

OMG @lbdroid you saved my life. I have the same problem as the original poster, and whenever I've used tcpdump on the OpenWRT box to check if the upstream router (Unitymedia Connectbox) was sending RA's I got replies and IPV6 was working for hours on end. Then, after I shut down tcpdump, I would lose connectivity after 30 minutes.

I thought that it must be the promiscuous mode tcpdump activates on the interface, but I had ruled it out since I couldn't imagine it really being something stupid as this.

I fiddled with the VLAN, Firewall and everything else that could potentially swallow the RA's, to no avail. I had also already checked that the upstream router sends the RA's to the IPV6 multicast MAC 33:....

@lbdroid Can you explain why the interface does not activate allmulti by itself, or who deactivates it if it should be on? Or is the upstream router actually sending the multicast message to the wrong MAC address(es)? Sorry if these questions seem stupid, I'm not really familiar with IPV6.
Also I would obviously like a different solution than setting a mode on the interface that's not really required, especially promiscuous, for fear of creating security vulnerabilities.

Thanks in advance

Line40

Sorry for digging up an ancient topic. Actual problem though.
Apparently OpenWRT's IPv6 client odhcp6c expects regular RA sollicitations from upstream router. Without RA messages the default route times out after a certain time (probably 30min). After that OpenWRT apparently deletes the default route and connection is lost.

Two workarounds exist:
a) get your ISP sending RA's. See Dutch fix (in Dutch)
b) apply Steffen_Weinreich's workaround and copy odhcp6c.user in /etc/ in your router. See Steffen_Weinreich's fix

After a long conversation with my ISP this behavior seems specific to IPv6 and specific to OpenWRT. I would like to let the communtity decide whether this is a bug or not. And hey, this might be a good contribution for the IPv6 configuration page.
Credits go to the original posters :wink:

# /etc/odhcp6c.user
# https://forum.turris.cz/t/solved-loosing-ipv6-default-route-after-30-minutes/3883
# by Steffen_Weinreich
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

(Older versions of) OpenWrt is the basis for many commercial router SDKs, all OEM firmwares for QCA and Mediatek chipsets are using it for their devices, so blaming 'just' OpenWrt isn't quite an option for an ISP.

@slh thanks for the clarification. To be clear I love OpenWrt and am using this excellent piece of software for many years already and in multiple CPE's. Per the RFC my ISP offers a kind of broken native IPv6 service, let's tell them that, "you are the only customer with such a router" hehe ;). For fixing this inconvenience Steven Barth's workaround consists of the 'fakeroutes' default option, which unfortunately did not work for me.

Some ISP seem to only do stateful DHCPv6 and not sending RAs.
This is technically broken because plain DHCPv6 doesn't carry routes.

We work around here by faking a default route to the DHCPv6 server
if we do not receive a useful RA from the ISP.

This workaround can be turned off with: option fakeroutes 0
Signed-off-by: default avatarSteven Barth <steven@midlink.org>

git-svn-id: svn://svn.openwrt.org/openwrt/branches/barrier_breaker@42842 3c298f89-4303-0410-b956-a3cf2f4a3e73