6relayd and tunnelbroker issue.

[xinglp <xinglp@…>]

My last working version is r35342.

I set it according the example configurations

uci set network.wan6=interface
uci set network.wan6.proto=6in4
uci set network.wan6.peeraddr=xxxxx
uci set network.wan6.ip6addr='2001:xxx:xx:xxxx::2/64'
uci set network.wan6.tunnelid=xxxx
uci set network.wan6.username=xxxxx
uci set network.wan6.password='YOUR_PASSWORD'
uci commit network

uci set firewall.@zone[1].network='wan wan6'
uci commit firewall

Then I can access ipv6 from this router.

But the default 6relayd config file (below) not set default ipv6 route for my PC(xp), it only assign ipv6 address.

config server default
       option master   wan6
       list network    lan
       option rd       server
       option dhcpv6   server
       option fallback_relay   'rd dhcpv6 ndp'

So I changed it to the below config, and it works well.

config server exampleserver
        option network  'lan'
        option rd       'server'
        option dhcpv6   'server'

After update to r35362, my PC can only get ipv6 address, but can not access anythings with ipv6,(ping -6 google.com show timeout). And there is a wget process keeping in the router, like "wget ​http://tunnelbroker.net/xxxxx"

[hnyman <hannu.nyman@…>]

You are missing the routed ipv6 prefix addresses. As far as I know, the tunnel address is just for the tunnel endpoint. Then you have to give ipv6 addresses from the "routed prefix".

Read wiki: ​http://wiki.openwrt.org/doc/uci/network6#henet.6in4.tunnel

It might be easier to forget about wan6 and leave wan6 for possible later ipv6 autoconfig for ISP. Just create a new interface (e.g. henet) and set configuration for that. No need to edit the 6relayd config at all. Just leave the defaults there.

config 'interface' 'henet'
        option 'proto' '6in4'
        option 'mtu' '1424'
        option 'ttl' '64'
        option 'peeraddr' '62.12.34.56'
        option 'ip6addr' '2001:DB8:2222:EFGH::2/64'
        option 'ip6prefix' '2001:DB8:1234:ABCD::/64' # Your routed prefix
        option tunnelid '123456'
        option username 'tb1234567890.12345678'
        option password 'password'

[anonymous]

I'm seeing a similar behaviour as the OP. Machines on the network served by the router can no longer get any traffic through to the wider ipv6 internet. Reverting r35344 (or manually running "sysctl -w net.ipv6.conf.all.forwarding=1" on the router) restores the ipv6 connectivity for machines on the internal network.

[cyrus]

@OP: Please follow hnymans advice and add an
option ip6prefix ...
to the 6in4 configuration where ... is the value given as "Routed /64" or "Routed /48" and commit and apply your network configuration.

@anonymous: fix is on the way

[xinglp <xinglp@…>]

After update the confg file(as the wiki, set the henet interface, add "option ip6assign 64" to lan interface) and reboot. My PC still can not reach ipv6 outside.
Only "sysctl -w net.ipv6.conf.all.forwarding=1" make it work.

And a process hanging there.
"wget-qO/dev/null ​http://ipv4.tunnelbroker.net/ipv4_end.php?ip=AUTO&apikey=xxx&pass=xxx&tid=xxx"
netstat -anp show it's state is ESTABLISHED.

[anonymous]

Replying to xinglp <xinglp@…>:

After update the confg file(as the wiki, set the henet interface, add "option ip6assign 64" to lan interface) and reboot. My PC still can not reach ipv6 outside.

Have you recompiled the firmware after the recent fixes by r35368, r35369, r35370, r35371 and r35372 ?

[cyrus]

This is fixed in latest trunk. Retry with r35371 or later, please.

[xinglp <xinglp@…>]

OK, confirm fixed, Thanks

[xinglp <xinglp@…>]

But a wget process still keeping running here.

# pstree
init-+-6relayd
     |-crond
     |-dnsmasq
     |-hostapd
     |-hotplug2
     |-init
     |-klogd
     |-miniupnpd
     |-netifd-+-6in4.sh---wget
     |        `-pppd
     |-ntpd
     |-procd-+-dropbear---dropbear---ash---pstree
     |       `-ubusd
     `-syslogd

[anonymous]

The wget process should be there to dynamically update your he-net tunnel so that he.net knows your endpoints IP address, it should not be harmful.

Does it behave unexpectedly in any way?

[xinglp <xinglp@…>]

Replying to anonymous:

The wget process should be there to dynamically update your he-net tunnel so that he.net knows your endpoints IP address, it should not be harmful.

Does it behave unexpectedly in any way?

It keeping be there forever.
Normally, it should run and quit very soon.

[cyrus]

I cannot see anything wrong with the code.
I'm not sure why this is happening or what could possibily fix it. I'd guess a connection problem or something related.

Maybe it would help to add a timeout there for the individual update requests but busybox wget doesn't seem to support that.

However it seems more like a cosemtical problem to me.

[hnyman <hannu.nyman@…>]

It might actually be more than cosmetics:
I tested my he.net tunnel and the wget behaviour. It seemed to go this way:

• If he.net tunnel interface is down and is activated with "connect" button in Luci, the wget process goes ok and dies normally.
• If the tunnel interface is already up and the "connect" button is pressed, the wget process stays alive under the netifd / 6in4.sh

'- /sbin/netifd

'- /bin/sh ./6in4.sh 6in4 setup henet { "proto": "6in4", "auto": false, "mtu": 1424, "ttl": 64, "peer...

'- wget -qO/dev/null ...

If the tunnel interface is then closed with "Stop", the wget process dies.

The behaviour seemed rather repeatable.

[xinglp <xinglp@…>]

I fingure out it's a firewall problem.

I try to block /etc/hotplug.d/iface/20-firewall (add "exit 0" to it just after sha-bang), the "keeping running wget" not appeared any more.

But since my endpoint ip for het-net was update by wget, the "wget staying alive" behavior maybe caused by dropping FIN when firewall is in setting up.

After set "START=99" in /etc/init.d/firewall, it seems normal.

[xinglp <xinglp@…>]

Replying to xinglp <xinglp@…>:

I fingure out it's a firewall problem.

I try to block /etc/hotplug.d/iface/20-firewall (add "exit 0" to it just after sha-bang), the "keeping running wget" not appeared any more.

But since my endpoint ip for het-net was update by wget, the "wget staying alive" behavior maybe caused by dropping FIN when firewall is in setting up.

After set "START=99" in /etc/init.d/firewall, it seems normal.

This only fix first startup problem.

If I run "ifup henet" when it already up, it will happen somethings.

Also while a wget is running, "ifdown henet" will make wget below to init like this:

init-+-6relayd
     |-crond
     |-dnsmasq
     |-hostapd
     |-hotplug2---hotplug2
     |-init
     |-klogd
     |-miniupnpd
     |-netifd---pppd
     |-ntpd
     |-procd-+-dropbear---dropbear---ash---pstree
     |       `-ubusd
     |-syslogd
     `-wget #<<<<<

[xinglp <xinglp@…>]

Finally, I use this patch

[hnyman]

Replying to cyrus:

Maybe it would help to add a timeout there for the individual update requests but busybox wget doesn't seem to support that.

Actually, busybox seems to already have the timeout feature, but it is turned off by default:
# CONFIG_BUSYBOX_CONFIG_FEATURE_WGET_TIMEOUT is not set

Maybe it should be turned on by default, and 6in4 script changed to use the timeout feature. (and do that also for other similar places with wget, maybe ddns-scripts)

[xinglp <xinglp@…>]

Replying to hnyman:

Replying to cyrus:

Maybe it would help to add a timeout there for the individual update requests but busybox wget doesn't seem to support that.

Actually, busybox seems to already have the timeout feature, but it is turned off by default:
# CONFIG_BUSYBOX_CONFIG_FEATURE_WGET_TIMEOUT is not set

Maybe it should be turned on by default, and 6in4 script changed to use the timeout feature. (and do that also for other similar places with wget, maybe ddns-scripts)

The default busybox wget's timeout behavior won't fix this problem ( at least current busybox-1.19.4 ).
Some of it's socket opteration not use timeout. (not in a poll/select loop).
My patch just add a setsockopt(..., SOL_SOCKET, SO_RCVTIMEO,...)

[cyrus]

I just commited a workaround in r35408 and r35409.
It is not very elegant but should do the trick.

If the problem still persists for you, please reopen the ticket.

[jow]

Milestone Attitude Adjustment 12.09 deleted