TomatoUSB

Hello TomatoUSB users, I've discovered that IPv6 6to4 in TomatoUSB is done completely off 6to4 standards and works only with native IPv6 hosts. If remote host is on 6to4, packets will be dropped, because of wrong routing and tunnel settings.

my hw: ASUS RT-N16
my sw: Tomato Firmware 1.28.0000 MIPSR2-088 K26 USB AIO

In details:
6to4 on TomatoUSB:

root@Citadel# ip tunnel
sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16
v6to4: ipv6/ip  remote 192.88.99.1  local 89.178.153.23  ttl 255  6rd-prefix 2002::/16
root@Citadel# ip -6 ro
2002:59b2:9917:1::/64 dev br0  proto kernel  metric 256  mtu 1480 advmss 1420 metric 10 4294967295
2002::/16 via :: dev v6to4  proto kernel  metric 256  mtu 1480 advmss 1420 metric 10 4294967295
...
default dev v6to4  metric 1024  mtu 1480 advmss 1420 metric 10 4294967295
unreachable default dev lo  proto kernel  metric -1  error -128 metric 10 255
...
unreachable default dev lo  proto kernel  metric -1  error -128 metric 10 255

Look at v6to4 remote point. By 6to4 standards it is not a 192.88.99.1, it must be any, and instead of hardlocking this value when creating tunnel, anycast relay must be set in routes like this: ip -6 ro add ::/0 via ::192.88.99.1

Example of misbehaivor.

root@Citadel# ping6 ipv6.yandex . r u
PING ipv6.yandex . r u (2a02:6b8:0:261::1): 56 data bytes
--- ipv6.yandex . r u ping statistics ---
100 packets transmitted, 0 packets received, 100% packet loss

listening on vlan901, link-type EN10MB (Ethernet), capture size 65535 bytes
03:22:12.637044 IP 87.250.234.10 > 95.24.55.205: IP6 2a02:6b8:0:261::1 > 2002:5f18:37cd::1: ICMP6, echo reply, seq 43, length 64
03:22:12.639731 IP 95.24.55.205 > 87.250.234.10: ICMP 95.24.55.205 protocol 41 port 0 unreachable, length 132
03:22:13.646255 IP 87.250.234.10 > 95.24.55.205: IP6 2a02:6b8:0:261::1 > 2002:5f18:37cd::1: ICMP6, echo reply, seq 44, length 64
03:22:13.648990 IP 95.24.55.205 > 87.250.234.10: ICMP 95.24.55.205 protocol 41 port 0 unreachable, length 132

Another example of misbehaivor.

my ip: 2002:59b2:9917:1
remote ip: 2002:b00e:08b6::1
6to4 <——> 6to4 connection
remote 6to4 done right (relay: any, routing ::192.88.99.1)

root@Citadel# ping6  2002:b00e:08b6::1
PING 2002:b00e:08b6::1 (2002:b00e:8b6::1): 56 data bytes
--- 2002:b00e:08b6::1 ping statistics ---
545 packets transmitted, 0 packets received, 100% packet loss

log from 2002:b00e:08b6::1

listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
00:29:38.042417 IP 192.88.99.1 > 176.14.8.182: IP6 2002:59b2:9917::1 > 2002:b00e:8b6::1: ICMP6, echo request, seq 296, length 64
00:29:38.042557 IP 176.14.8.182 > 89.178.153.23: IP6 2002:b00e:8b6::1 > 2002:59b2:9917::1: ICMP6, echo reply, seq 296, length 64
00:29:38.045051 IP 89.178.153.23 > 176.14.8.182: ICMP 89.178.153.23 protocol 41 port 0 unreachable, length 132
00:29:39.062157 IP 192.88.99.1 > 176.14.8.182: IP6 2002:59b2:9917::1 > 2002:b00e:8b6::1: ICMP6, echo request, seq 297, length 64
00:29:39.062388 IP 176.14.8.182 > 89.178.153.23: IP6 2002:b00e:8b6::1 > 2002:59b2:9917::1: ICMP6, echo reply, seq 297, length 64
00:29:39.064657 IP 89.178.153.23 > 176.14.8.182: ICMP 89.178.153.23 protocol 41 port 0 unreachable, length 132

this happens, because 6to4 host must use ipv4 to connect to other 6to4 host, by TomatoUSB routing and tunnel setup, everything will be routed to tunnel, and, ofcourse, dropped.

Thanks for reading and awesome firmware, hope this will be fixed in next release.

Best Regards, Dmitriy.

Here is workaround, how to get both misbehaivor situations fixed.

1) setup 6to4 in TomatoUSB
2) login from ssh or telnet and execute this script:

#!/bin/sh

# getting L2TP WAN ipv4
IPV4ADDR=`ifconfig ppp0 | grep inet | grep -v inet6 | cut -d ":" -f 2 | cut -d " " -f 1`
# making ipv6 from ipv4
IP6ADDR=`echo $IPV4ADDR | awk 'BEGIN{FS="\."}{printf"2002:%02x%02x:%02x%02x:1:0:0:0:1",$1,$2,$3,$4}'`
# deleting existing tunnel made by TomatoUSB front-end
ip t d v6to4
# adding new tunnel
ip t a v6to4 mode sit remote any local $IPV4ADDR
ip l s dev v6to4 up
# routing 6to4
ip -6 a a $IP6ADDR/16 dev v6to4
ip -6 route add 2000::/3 via ::192.88.99.1

now you have 6to4 done right.

Best Regards, Dmitriy.

please explain for the ones that aren't that good in networking

please generalize the script

If you "need" explanation or a "dummy script", then 6to4 isn't what you should be using.

perhaps you would be kind enough to modify the source code and post a diff ?

perhaps you would be kind enough to modify the source code and post a diff ?

sorry, but I dont know TomatoUSB guts well enough to provide reasonable fix and I hope that active developers of this project will notice this bug and workaround.

please explain for the ones that aren't that good in networking

if you dont use 6to4, you dont need this at all.

if you dont use 6to4, you dont need this at all.

i do use it, and it seems to work fine. computers get their ips, ipv6 pages get loaded fine, even opt-ware transmission connects to ipv6 pears.

if it ain't broke, don't fix it

been work fine for us for 7 months with no problem at all

i do use it, and it seems to work fine.
been work fine for us for 7 months with no problem at all

guys, read first post and try to connect to 6to4 peers. if you have relay set in interface settings and not in routing, 6to4 to 6to4 routing will fail. 6to4 with 6to4 connects on ipv4 because both hosts arent pure ipv6. its specification of protocol.

you might had 6to4 work that way before because many 6to4 relays were configured to route this type of packets by default (sortof fixing configuring and understanding of 6to4 because there was a big number of users with this same configuration mistake), but he. net and many others changed their 6to4 relay ipv6/4 transit settings and if you are behind this kind of relay - you will not be able to connect to 6to4 peers with default TomatoUSB 6to4 settings. relay will just drop wrong routed packets and you will see same thing as in first post.

if you still dont understand why and what I said - please just ignore this and dont post stuff like "works for me". If it works for you - provide logs and info.

Best regards.