Comcast is going to give its subscribers a 64-bit prefix when IPv6 comes online late Tuesday, June 5. My question is this: Would I use Native IPv6 from ISP and tick "Accept RA from WAN" only? Or do both WAN and LAN boxes need to be ticked for Router Advertisements? If "Native IPv6 from ISP" is not the choice I would use, would I use "DHCPv6 Prefix Delegation" instead or another one of the options above? [www.comcast6.net says the launch of IPv6 for them is this coming Tuesday]
I've wondered the same thing, but haven't found a definitive answer. The Comcast forum members on DSLreports.com seem to feel that DHCPv6 with Prefix Delegation is the correct choice.
Most probably, you will use DHCPv6 With Prefix Delegation, inserting 64 in the first box (Prefix Length) and the static ipv6 dns of your provider , choosing also the router advertisements and Accept RA from WAN.
you wont be able to get DHCPv6 responses from a native v6 network. You will only get RA responses. To get it to work you must : Enable Native IPv6 on the ipv6 config page, disable/leave everything blank except check off accept RA from wan. do NOT tick enable RA and do NOT fill in any subnet info. then go to admin - scripts - wan up and do : ebtables -t broute -A BROUTING -i vlan2 -p ! ipv6 -j DROP brctl addif br0 vlan2 on your windows boxes you will need to do : netsh interface teredo set state disabled
Zurk, I could not get this to work. Maybe I am not entering the wan up scripts properly. Have you gotten this to work with Comcast? I haven't found anyone yet who has successfully made Tomato work with Comcast IPv6. Any guidance would be greatly appreciated.
I see that. Now we just need to get it baked into the firmware so that a reboot doesn't wipe the changes.
This issue affects more than Shibby. It affects Toastman builds as well. This whole ordeal has been getting a lot of attention recently on both the Comcast forums and the official TomatoUSB forums. I posted pretty verbose details trying to track this SOB down but another person found the root cause: http://tomatousb.org/forum/t-484538/comcast-ipv6-not-working-with-tomato I'm going to private message Toastman and inform him of this thread, since I imagine he might not be reading it since it's talking about Shibby and not his firmware. This issue needs to get fixed. Further public coverage is here: http://www.dslreports.com/forum/r27234575-TomatoUSB-and-Comcast-IPv6-bugs-found
I've written a WAN Up script as a workaround for this issue: http://www.dslreports.com/forum/r27235017- Hope this helps people.
I'm pretty sure I found the problem in Tomato's code that is causing the extra route to be added. I posted the details at: http://tomatousb.org/forum/t-484538/comcast-ipv6-not-working-with-tomato I'll try and build tomato and test this, but I've never built tomato before, so if one of the devs can try this out that'd be awesome. Here's the (untested) patch for anyone who's interested: Code: diff --git a/release/src/router/rc/wan.c b/release/src/router/rc/wan.c index ecc953f..bd4337c 100644 --- a/release/src/router/rc/wan.c +++ b/release/src/router/rc/wan.c @@ -828,7 +828,7 @@ void start_wan6_done(const char *wan_ifname) eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048"); break; case IPV6_NATIVE_DHCP: - eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname); + eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname, "metric", "2048"); stop_dhcp6c(); start_dhcp6c(); break; I have verified that IPv6 does work correctly if the gateway-less default entry has a metric of 2048 rather than 1024.
armarkey, are you sure the increased metric solves the problem (and which problem does it solve exactly)? I just tried this manually on my TomatoUSB router: Code: root@gw:/tmp/home/root# route -A inet6 del default gw :: metric 1024 vlan2 root@gw:/tmp/home/root# route -A inet6 add ::/0 dev vlan2 metric 2048 root@gw:/tmp/home/root# ip -6 route 2601:9:4600:4f::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev vlan1 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev vlan2 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 default dev vlan2 metric 2048 mtu 1500 advmss 1440 metric 10 4294967295 unreachable default dev lo proto kernel metric -1 error -128 metric 10 255 ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev vlan1 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev br0 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev vlan2 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 unreachable default dev lo proto kernel metric -1 error -128 metric 10 255 root@gw:/tmp/home/root# ifconfig br0 br0 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C4 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2601:9:4600:4f:e2cb:4eff:fec0:c4/64 Scope:Global inet6 addr: fe80::e2cb:4eff:fec0:c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:8044 errors:0 dropped:0 overruns:0 frame:0 TX packets:7856 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:553866 (540.8 KiB) TX bytes:1203501 (1.1 MiB) root@gw:/tmp/home/root# ifconfig vlan2 vlan2 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C5 inet addr:67.180.84.87 Bcast:67.180.87.255 Mask:255.255.252.0 inet6 addr: fe80::e2cb:4eff:fec0:c5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25707 errors:0 dropped:0 overruns:0 frame:0 TX packets:7155 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2017560 (1.9 MiB) TX bytes:625943 (611.2 KiB) root@gw:/tmp/home/root# ping ipv6.google.com PING ipv6.google.com (2001:4860:4001:802::1011): 56 data bytes --- ipv6.google.com ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss And from a FreeBSD box on the local LAN segment (first testing that the router and the machine can talk to one another): Code: $ ifconfig em0 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> ether 00:30:48:d2:22:d0 inet6 fe80::230:48ff:fed2:22d0%em0 prefixlen 64 scopeid 0x5 inet 192.168.1.51 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2601:9:4600:4f:230:48ff:fed2:22d0 prefixlen 64 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active $ netstat -rn -f inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ... default 2601:9:4600:4f:e2cb:4eff:fec0:c4 UGS em0 ... $ ping6 2601:9:4600:4f:e2cb:4eff:fec0:c4 PING6(56=40+8+8 bytes) 2601:9:4600:4f:230:48ff:fed2:22d0 --> 2601:9:4600:4f:e2cb:4eff:fec0:c4 16 bytes from 2601:9:4600:4f:e2cb:4eff:fec0:c4, icmp_seq=0 hlim=64 time=1.473 ms 16 bytes from 2601:9:4600:4f:e2cb:4eff:fec0:c4, icmp_seq=1 hlim=64 time=0.309 ms 16 bytes from 2601:9:4600:4f:e2cb:4eff:fec0:c4, icmp_seq=2 hlim=64 time=0.394 ms ^C --- 2601:9:4600:4f:e2cb:4eff:fec0:c4 ping6 statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 0.309/0.725/1.473/0.530 ms $ ping6 ipv6.google.com PING6(56=40+8+8 bytes) 2601:9:4600:4f:230:48ff:fed2:22d0 --> 2001:4860:4001:800::1012 ^C --- ipv6.l.google.com ping6 statistics --- 8 packets transmitted, 0 packets received, 100.0% packet loss I should note I do not have Accept RA turned on in TomatoUSB (for WAN), and I'm using DHCPv6 with Prefix Delegation and *without* the IA_NA fix I previously mentioned/linked to. I was able to confirm that the packets from the ping6 I did from the FreeBSD box did make it to the router (via br0). Thoughts? EDIT: I just saw your post on the tomatousb.org forum, specifically these paragraphs: Based on that, I think my "do some route statements after-the-fact" solution is not going to work. In fact, I don't know how to actually test this without a firmware since the ICMP announcement is going to be seen almost immediately. So how did you test this?
Ok, I think that's probably what's preventing it from working for you. I had Accept RA enabled and that must be what allows the linux kernel to automatically create the default route with the correct gateway. The route entry that it creates has a metric of 1024 which is why it is then able to override the gateway-less entry that the wan service creates. If I manually delete the default with gateway route, it is regenerated within a few seconds on my router. And when I ran a remote wireshark capture I saw router advertisements coming in from the WAN every 3 seconds, so I'm pretty sure they're what are triggering the (re)creation of the correct default route. From what I've seen in my testing, it looks like Accept RA MUST be enabled on the WAN to get IPv6 functioning. (Yep, just tested it without the Accept RA and the correct route w/ gateway never gets created so IPv6 never works) The DHCPv6 responses I'm seeing from comcast don't include a gateway router option like the standard IPv4 DHCP responses do. This might be an optional field that comcast isn't using, but I think it's more likely that DHCPv6 just doesn't support a gateway option (since that's what router advertisements are meant to do). This brings up an even bigger issue, why is Accept RA an option if there's absolutely no chance of having a functional network when it's disabled. I think this will also be the case for native IPv6 (manual configuration) since when you chose that configuration there's no field to enter a gateway router. It seems to me that there should be a gateway field if you're manually configuring the address and Accept RA should be mandatory (no checkbox) for DHCP if DHVPv6 doesn't support sending a gateway router in its response packets. Just to be more exact about the configuration I'm using, I also have the Enable Router Advertisements option selected since I'm pretty sure no devices within my network will get a global address without it. By the way, my first attempt at building a tomato image failed. I won't be able to look into the problem until tomorrow evening at the earliest.
Re: DHCPv6 not having a default route: correct. It's not even part of the specification. The default route is provided via IPv6 RAs, which are (as you know) transmitted via IPv6 ICMP. Some factual backup for that statement: * http://snowulf.com/2010/07/09/ipv6-getting-functional-dhcpv6-and-route-advertising-together/ * http://social.technet.microsoft.com...S/thread/4d3a4125-36f1-49b1-b00c-f2513752a508 -- see very bottom of page, last post So a for why TomatoUSB even has the "Accept RA from" checkboxes -- that is a fantastic question. I do not understand the purpose of this toggle, at least for WAN. Otherwise there is no way to assign the default gateway for IPv6 traffic (going out of the router) aside from issuing a manual "ip -6 route add" command. And I think that's exactly what TomatoUSB is doing with the code you mentioned above -- it's issuing (effectively) "ip -6 route add ::/0 dev vlan2" (and/or "metric 2048", hehe) -- note there is no next-hop address provided. Instead it literally is saying "for the default IPv6 gateway on this box, send packets to :: (0:0:0:0:0:0:0:0) via device vlan2". I don't know how this would work. Even FreeBSD when accepting RAs doesn't do that; it actually fills the next-hop with a proper address, not ::. Also, just a comment in passing -- something I got hung up on: don't let the mention of AdvManagedFlag in the first link confuse you. radvd is the daemon which does RA announcements on whatever Ethernet device its told to. In the case of TomatoUSB, that's "interface br0" (see /etc/radvd.conf). I'm fairly certain radvd does not have anything to do with the IPv6 RAs seen across the WAN link (vlan2) from Comcast. So I found this: * http://linux.ardynet.com/ipv6setup.php Which sheds a little more light on the topic. It helps to think of radvd as the "route advertising daemon" or "RA advertising daemon", e.g. it advertises IPv6 routes to clients. That's different than something that *accepts* RAs. So what accepts RAs on TomatoUSB received via the WAN (vlan2)? I'm still not sure. I'm inclined to think the kernel does -- there are a lot of options in /proc/sys/net/ipv6/conf pertaining to RA-related things and RS (route solicitations). BTW, since you have a copy of the TomatoUSB code via git, can you determine what exactly the "Accept RA from" WAN/LAN checkboxes actually do code-wise? I wonder if they toggle some /proc/sys/net/ipv6/conf bits. I would look myself (I've done C for many many years) but I don't have git or any related tools. I might be able to get those working on FreeBSD (so I could look at source) but I don't know where the repo lives. As for issues building TomatoUSB -- I'm absolutely certain Toastman can help out here.
I believe that you may be able to browse the git repo for the various flavors of Toastman's builds at the following locations: http://repo.or.cz/w/tomato.git/tree/Toastman-RT http://repo.or.cz/w/tomato.git/tree/Toastman-RT-N http://repo.or.cz/w/tomato.git/tree/Toastman-IPT-ND
The Accept RA from WAN checkbox causes the code to call "accept_ra(wan_ifname)" when the WAN come up. The LAN checkbox calls "accept_ra(nvram_safe_get("lan_ifname"));" http://repo.or.cz/w/tomato.git/blob/refs/heads/Toastman-RT:/release/src/router/rc/wan.c#l828 http://repo.or.cz/w/tomato.git/blob/refs/heads/Toastman-RT:/release/src/router/rc/services.c#l704 The accept_ra function is as follows: Code: void accept_ra(const char *ifname) { char s[256]; sprintf(s, "/proc/sys/net/ipv6/conf/%s/accept_ra", ifname); f_write_string(s, "2", 0, 0); sprintf(s, "/proc/sys/net/ipv6/conf/%s/forwarding", ifname); f_write_string(s, "2", 0, 0); } http://repo.or.cz/w/tomato.git/blob/refs/heads/Toastman-RT:/release/src/router/rc/network.c#l437 That appears to enable "hybrid mode" which allows RA to be accepted if forwarding is enabled. All the RA processing code is in the following Linux code (which is too complicated for me): http://repo.or.cz/w/tomato.git/blob...lease/src-rt/linux/linux-2.6/net/ipv6/ndisc.c
Thanks Morac. Take a look at this: Code: root@gw:/tmp/home/root# for i in /proc/sys/net/ipv6/conf/*/accept_ra /proc/sys/net/ipv6/conf/*/forwarding; do printf "%-50s `cat $i` \n" $i; done /proc/sys/net/ipv6/conf/all/accept_ra 1 /proc/sys/net/ipv6/conf/br0/accept_ra 1 /proc/sys/net/ipv6/conf/default/accept_ra 1 /proc/sys/net/ipv6/conf/eth0/accept_ra 1 /proc/sys/net/ipv6/conf/eth1/accept_ra 1 /proc/sys/net/ipv6/conf/imq0/accept_ra 1 /proc/sys/net/ipv6/conf/imq1/accept_ra 1 /proc/sys/net/ipv6/conf/imq2/accept_ra 1 /proc/sys/net/ipv6/conf/lo/accept_ra 1 /proc/sys/net/ipv6/conf/vlan1/accept_ra 1 /proc/sys/net/ipv6/conf/vlan2/accept_ra 2 /proc/sys/net/ipv6/conf/all/forwarding 1 /proc/sys/net/ipv6/conf/br0/forwarding 1 /proc/sys/net/ipv6/conf/default/forwarding 1 /proc/sys/net/ipv6/conf/eth0/forwarding 1 /proc/sys/net/ipv6/conf/eth1/forwarding 1 /proc/sys/net/ipv6/conf/imq0/forwarding 1 /proc/sys/net/ipv6/conf/imq1/forwarding 1 /proc/sys/net/ipv6/conf/imq2/forwarding 1 /proc/sys/net/ipv6/conf/lo/forwarding 1 /proc/sys/net/ipv6/conf/vlan1/forwarding 1 /proc/sys/net/ipv6/conf/vlan2/forwarding 1 Two things to note here: 1. "Accept RA from WAN" is enabled/checked on my system, so that explains the value of 2 in the vlan2/accept_ra tunable 2. I would expect /proc/sys/net/ipv6/conf/vlan2/forwarding to also have 2 (that's what accept_ra() is supposed to do), but it only has 1. A value of 2 doesn't do anything anyway, although echo 2 > /proc/sys/net/ipv6/conf/vlan2/forwarding DOES in fact set the value to 2. (Binary-wise, 0 = %00000000, 1 = %00000001, 2 = %00000010, so I'm not sure how the code is setting a value of 2 but it ends up getting set to 1; maybe something else overwrites it later when choosing "Save" ?) Documentation for these tunables (scroll down about 3/4ths): http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt
I'm going to have to split this up into two posts given how long it is. The forum won't let me input more than 15,000 characters -- yeah well, welcome to technical debugging situations, forum! Last night I cleared NVRAM (thorough) and re-configured my RT-N16 manually with all my settings and then let the router sit overnight. I did not make use of the IA-NA fix, or the "spurious default route" fix. I wanted to see what ended up coming across route-wise after things had a chance to settle, so that some other forum folks would have a good/clean example of what the entire system looks like. For IPv6 GUI bits, "DHCPv6 with Prefix Delegation" was chosen, "Enable Router Advertisements" is checked (default), and "Enable RA on WAN" is checked. This is what I ended up with: ifconfig: Code: root@gw:/tmp/home/root# ifconfig br0 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C4 inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: 2601:9:4600:4f:e2cb:4eff:fec0:c4/64 Scope:Global inet6 addr: fe80::e2cb:4eff:fec0:c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:684627 errors:0 dropped:0 overruns:0 frame:0 TX packets:768192 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:76349850 (72.8 MiB) TX bytes:300754305 (286.8 MiB) eth0 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C4 inet6 addr: fe80::e2cb:4eff:fec0:c4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2769467 errors:2 dropped:0 overruns:0 frame:1 TX packets:1451519 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:493208278 (470.3 MiB) TX bytes:391639485 (373.4 MiB) Interrupt:4 Base address:0x2000 eth1 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C6 inet6 addr: fe80::e2cb:4eff:fec0:c6/64 Scope:Link UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:299 errors:1 dropped:0 overruns:0 frame:5367835 TX packets:8813 errors:11 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:50982 (49.7 KiB) TX bytes:3809252 (3.6 MiB) Interrupt:3 Base address:0x1000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1 RX packets:52 errors:0 dropped:0 overruns:0 frame:0 TX packets:52 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:6861 (6.7 KiB) TX bytes:6861 (6.7 KiB) vlan1 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C4 inet6 addr: fe80::e2cb:4eff:fec0:c4/64 Scope:Link UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1 RX packets:684596 errors:0 dropped:0 overruns:0 frame:0 TX packets:768452 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:79089313 (75.4 MiB) TX bytes:303874931 (289.7 MiB) vlan2 Link encap:Ethernet HWaddr E0:CB:4E:C0:00:C5 inet addr:67.180.84.87 Bcast:67.180.87.255 Mask:255.255.252.0 inet6 addr: fe80::e2cb:4eff:fec0:c5/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:2084868 errors:0 dropped:0 overruns:0 frame:0 TX packets:683061 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:364268409 (347.3 MiB) TX bytes:87763926 (83.6 MiB) ip -6 route: Code: root@gw:/tmp/home/root# ip -6 route 2601:9:4600:4f::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev vlan1 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev br0 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev vlan2 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 metric 10 4294967295 default dev vlan2 metric 1024 mtu 1500 advmss 1440 metric 10 4294967295 default via fe80::201:5cff:fe32:6e41 dev vlan2 proto kernel metric 1024 expires 1797sec mtu 1500 advmss 1440 metric 10 4294967295 unreachable default dev lo proto kernel metric -1 error -128 metric 10 255 ff00::/8 dev eth0 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev vlan1 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev br0 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev vlan2 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 ff00::/8 dev eth1 metric 256 mtu 1500 advmss 1440 metric 10 4294967295 unreachable default dev lo proto kernel metric -1 error -128 metric 10 255 ip6tables --list -v: Code: root@gw:/tmp/home/root# ip6tables --list -v Chain INPUT (policy DROP 26 packets, 1560 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all any any anywhere anywhere rt type:0 17 2398 ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT ipv6-nonxt any any anywhere anywhere length 40 1265 152K ACCEPT all br0 any anywhere anywhere 0 0 ACCEPT all lo any anywhere anywhere 3 505 ACCEPT udp any any anywhere anywhere udp dpt:546 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp destination-unreachable 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp packet-too-big 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp time-exceeded 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp parameter-problem 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-request 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-reply 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 130 4800 346K ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 131 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 132 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp router-solicitation 15211 1825K ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp router-advertisement 293 21096 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp neighbour-solicitation 60 4320 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp neighbour-advertisement 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 141 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 142 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 143 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 148 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 149 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 151 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 152 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp type 153 Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP all any any anywhere anywhere rt type:0 0 0 ACCEPT all br0 br0 anywhere anywhere 0 0 DROP all any any anywhere anywhere state INVALID 0 0 ACCEPT all any any anywhere anywhere state RELATED,ESTABLISHED 0 0 DROP all !br0 vlan2 anywhere anywhere 0 0 ACCEPT ipv6-nonxt any any anywhere anywhere length 40 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp destination-unreachable 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp packet-too-big 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp time-exceeded 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp parameter-problem 2 112 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-request 0 0 ACCEPT ipv6-icmp any any anywhere anywhere ipv6-icmp echo-reply 0 0 wanin all vlan2 any anywhere anywhere 0 0 wanout all any vlan2 anywhere anywhere 0 0 ACCEPT all br0 vlan2 anywhere anywhere Chain OUTPUT (policy ACCEPT 1531 packets, 172K bytes) pkts bytes target prot opt in out source destination 0 0 DROP all any any anywhere anywhere rt type:0 Chain wanin (1 references) pkts bytes target prot opt in out source destination Chain wanout (1 references) pkts bytes target prot opt in out source destination brctrl show: Code: root@gw:/tmp/home/root# brctl show bridge name bridge id STP enabled interfaces br0 8000.e0cb4ec000c4 no vlan1 eth1 Things to note here: 1. You can see the "spurious default route" situation which Comcast forum user morrildl mentioned in his Comcast forum post. Since it's hard to see exactly, let me point it out again, as well as show the "route -A inet6" equivalent of those two routes too: ip -6 route (default routes): Code: default dev vlan2 metric 1024 mtu 1500 advmss 1440 metric 10 4294967295 default via fe80::201:5cff:fe32:6e41 dev vlan2 proto kernel metric 1024 expires 1798sec mtu 1500 advmss 1440 metric 10 4294967295 route -A inet6 (default routes): Code: Kernel IPv6 routing table Destination Next Hop Flags Metric Ref Use Iface ::/0 :: U 1024 0 0 vlan2 ::/0 fe80::201:5cff:fe32:6e41 UGDA 1024 0 0 vlan2 This also shows the "competing metric 1024" issue that armarkey pointed out earlier. 2. You can see clearly that the vlan2 interface (WAN) does not have an IP address. With the IA-NA fix (again: that isn't applied here!), what ends up happening is that interface gets a public IPv6 address (/128) which is reachable from the Internet (people can ping it publicly, etc.). 3. ip6tables --list -v does show some dropped packets (count of 26). That's very interesting to me given that nobody has been able to reach my router (IPv6-wise) from the Internet; see my DSLR/BBR forum post about a colleague of mine trying to ping6 me and seeing routing loops (thus max hopcount exceeded).
So given the above state of things, what works and what doesn't? Well, nothing works. ;-) * ping6 ipv6.google.com from the router itself does not work. Packets go out across vlan2 but no responses are ever seen. Here's verification of that using tcpdump: RT-N16 router (separate windows): Code: root@gw:/tmp/home/root# ping6 -c 3 ipv6.google.com PING ipv6.google.com (2001:4860:4001:801::1013): 56 data bytes --- ipv6.google.com ping statistics --- 3 packets transmitted, 0 packets received, 100% packet loss root@gw:/tmp/home/root# tcpdump -p -l -n -s 0 -i vlan2 "ip6 and not ether host 00:01:5c:32:6e:41" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 14:20:20.708318 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:13, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1013 8700 48f2 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0801 0000 0000 0000 1013 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 14:20:21.708287 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:13, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1013 8700 48f2 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0801 0000 0000 0000 1013 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 14:20:22.708300 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:13, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1013 8700 48f2 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0801 0000 0000 0000 1013 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 3 packets captured 3 packets received by filter 0 packets dropped by kernel * ping6 ipv6.google.from from an IPv6 machine on the LAN (FreeBSD box) also does not work. The packets get forwarded from the FreeBSD box to the RT-N16 router, then the RT-N16 router sends them out vlan2 but no responses are ever seen. Here's verification of that using tcpdump: RT-N16 router shows the ICMPv6 echo-request packets coming from the FreeBSD box going out vlan2: Code: root@gw:/tmp/home/root# tcpdump -p -l -n -s 0 -i vlan2 "ip6 and not ether host 00:01:5c:32:6e:41" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan2, link-type EN10MB (Ethernet), capture size 65535 bytes 14:13:42.588315 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:11, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1011 8700 48f7 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0800 0000 0000 0000 1011 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 14:13:43.588289 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:11, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1011 8700 48f7 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0800 0000 0000 0000 1011 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 14:13:44.588288 e0:cb:4e:c0:00:c5 > 33:33:ff:00:10:11, ethertype IPv6 (0x86dd), length 86: 0x0000: 6000 0000 0020 3aff fe80 0000 0000 0000 `.....:......... 0x0010: e2cb 4eff fec0 00c5 ff02 0000 0000 0000 ..N............. 0x0020: 0000 0001 ff00 1011 8700 48f7 0000 0000 ..........H..... 0x0030: 2001 4860 4001 0800 0000 0000 0000 1011 ..H`@........... 0x0040: 0101 e0cb 4ec0 00c5 ....N... 3 packets captured 3 packets received by filter 0 packets dropped by kernel FreeBSD box doing the ping6 and tcpdump (separate windows): Code: $ ping6 -c 3 ipv6.google.com PING6(56=40+8+8 bytes) 2601:9:4600:4f:230:48ff:fed2:22d0 --> 2001:4860:4001:800::1011 --- ipv6.l.google.com ping6 statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss # tcpdump -p -l -n -s 0 -i em0 "ip6" tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 65535 bytes 14:13:42.650183 IP6 2601:9:4600:4f:230:48ff:fed2:22d0 > 2001:4860:4001:800::1011: ICMP6, echo request, seq 0, length 16 14:13:43.650222 IP6 2601:9:4600:4f:230:48ff:fed2:22d0 > 2001:4860:4001:800::1011: ICMP6, echo request, seq 1, length 16 14:13:44.650213 IP6 2601:9:4600:4f:230:48ff:fed2:22d0 > 2001:4860:4001:800::1011: ICMP6, echo request, seq 2, length 16 14:13:45.661567 IP6 2601:9:4600:4f:e2cb:4eff:fec0:c4 > ff02::1:ffd2:22d0: ICMP6, neighbor solicitation, who has 2601:9:4600:4f:230:48ff:fed2:22d0, length 32 14:13:45.661589 IP6 2601:9:4600:4f:230:48ff:fed2:22d0 > 2601:9:4600:4f:e2cb:4eff:fec0:c4: ICMP6, neighbor advertisement, tgt is 2601:9:4600:4f:230:48ff:fed2:22d0, length 32 14:13:45.661939 IP6 2601:9:4600:4f:e2cb:4eff:fec0:c4 > 2601:9:4600:4f:230:48ff:fed2:22d0: ICMP6, destination unreachable, unreachable address 2001:4860:4001:800::1011, length 64 14:13:45.661946 IP6 2601:9:4600:4f:e2cb:4eff:fec0:c4 > 2601:9:4600:4f:230:48ff:fed2:22d0: ICMP6, destination unreachable, unreachable address 2001:4860:4001:800::1011, length 64 14:13:45.661951 IP6 2601:9:4600:4f:e2cb:4eff:fec0:c4 > 2601:9:4600:4f:230:48ff:fed2:22d0: ICMP6, destination unreachable, unreachable address 2001:4860:4001:800::1011, length 64 14:13:47.649203 IP6 2601:9:4600:4f:230:48ff:fed2:22d0 > 2601:9:4600:4f:e2cb:4eff:fec0:c4: ICMP6, neighbor solicitation, who has 2601:9:4600:4f:e2cb:4eff:fec0:c4, length 32 14:13:47.649474 IP6 2601:9:4600:4f:e2cb:4eff:fec0:c4 > 2601:9:4600:4f:230:48ff:fed2:22d0: ICMP6, neighbor advertisement, tgt is 2601:9:4600:4f:e2cb:4eff:fec0:c4, length 24 ^C 10 packets captured 1637 packets received by filter 0 packets dropped by kernel What's interesting in the tcpdump on the FreeBSD box is that it sees responses from the RT-N16 box stating ICMP6 destination unreachable! * I also verified that after the above ping6 attempts that the INPUT chain in ip6tables did not show an increase in dropped packets compared to earlier: Code: root@gw:/tmp/home/root# ip6tables --list -v | head -1 Chain INPUT (policy DROP 26 packets, 1560 bytes) And finally ifconfig and route details for the FreeBSD box, since I wanted to put those last to keep things from being too confusing, which shows the box is 2601:9:4600:4f:230:48ff:fed2:22d0 and uses a default route of 2601:9:4600:4f:e2cb:4eff:fec0:c4 : Code: $ ifconfig em0 em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO> ether 00:30:48:d2:22:d0 inet6 fe80::230:48ff:fed2:22d0%em0 prefixlen 64 scopeid 0x5 inet 192.168.1.51 netmask 0xffffff00 broadcast 192.168.1.255 inet6 2601:9:4600:4f:230:48ff:fed2:22d0 prefixlen 64 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> media: Ethernet autoselect (1000baseT <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb inet 127.0.0.1 netmask 0xff000000 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> $ netstat -rn -f inet6 Routing tables Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default 2601:9:4600:4f:e2cb:4eff:fec0:c4 UGS em0 ::1 link#11 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2601:9:4600:4f::/64 link#5 U em0 2601:9:4600:4f:230:48ff:fed2:22d0 link#5 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%em0/64 link#5 U em0 fe80::230:48ff:fed2:22d0%em0 link#5 UHS lo0 fe80::%lo0/64 link#11 U lo0 fe80::1%lo0 link#11 UHS lo0 ff01::%em0/32 fe80::230:48ff:fed2:22d0%em0 U em0 ff01::%lo0/32 ::1 U lo0 ff02::/16 ::1 UGRS lo0 ff02::%em0/32 fe80::230:48ff:fed2:22d0%em0 U em0 ff02::%lo0/32 ::1 U lo0
Since DHCPv6 isn't enabled in my area I can't test this, but are you manually assigning addresses to your local clients or is Tomato doing so? Based on what I've seen, it looks like having the "enable router advertisements" checked is a LAN side only thing designed to allow stateless configuration of local clients. It runs radvd which says its LAN only. Also it does a few things with the dhcp6c client. I found a nvram variable which enables debugging for both of those, "debug_ipv6". Also it looks like most of the dhcpv6 executables take a "-d" or "-D" argument to enabled debugging. For example http://manpages.ubuntu.com/manpages/lucid/man8/dhcp6c.8.html As I pointed out over at BroadbandReports all the code regarding dhcpv6, router advertisements and ipv6 are in: http://repo.or.cz/w/tomato.git/tree/refs/heads/Toastman-RT:/release/src/router/rc (dhcp.c and service.c) http://repo.or.cz/w/tomato.git/tree/refs/heads/Toastman-RT:/release/src/router/dhcpv6 (using WIDE-DHCPv6) http://repo.or.cz/w/tomato.git/tree/refs/heads/Toastman-RT:/release/src-rt/linux/linux-2.6/net/ipv6 It looks like dhcpv6 and router advertisements are external packages. IPv6 is part of the linux code. And simply because I found this page useful: http://www.networksorcery.com/enp/protocol/dhcpv6.htm
Thanks Morac. Hopefully I can shed some light on all of what you've said: 1. The FreeBSD box ("local client" or "LAN client") has its IPv6 address statically configured, as well as its default IPv6 gateway statically configured. This cannot be changed for reasons I'd rather not get into here (honest). The FreeBSD box does not accept RAs either (again this is intentional for reasons I'd rather not get into here). The important part is that the FreeBSD box is configured as 2601:9:4600:4f:230:48ff:fed2:22d0 with a prefix length of 64. The RT-N16 br0 interface is configured (dynamically via DHCPv6 Prefix data received from Comcast) as 2601:9:4600:4f:e2cb:4eff:fec0:c4 with a prefix length of 64. Thus, both of these system (FreeBSD box and RT-N16) are on the same network segment (2601:9:4600:4f::/64). They can talk, obviously, because my packet captures show packets from the FreeBSD box making their way through the RT-N16 and out the WAN port. 2. The "Enable Router Advertisements" GUI option probably does control IPv6 RAs on the LAN (specifically doing IPv6 RAs across br0). As you state, it controls bits pertaining to /etc/radvd.conf, which is used by the radvd daemon. The radvd daemon **absolutely** is only sending out RAs across br0, thus radvd == for the LAN. It has nothing to do with the WAN or RAs sent from Comcast. 3. I would like to know how "Enable Router Advertisements" has anything to do with dhcp6c. dhcp6c is used for sending out DHCPv6 requests across the WAN (vlan2). dhcp6c does have knowledge of the LAN (br0), and it has to, because the IPv6 subnet and prefix which is obtained via Comcast has to be assigned to the br0 interface. See /etc/dhcp6c.conf for details there. 4. dhcp6c on TomatoUSB appears to be some horribly created beast that doesn't appear to be the same thing found in man pages for Linux (Ubuntu, Debian, etc.). In fact, I'm still not sure what it is. Busybox 1.20.x onward has its own native DHCPv6 client (see d6_* files) but TomatoUSB is using Busybox 1.18.5 which doesn't have those. So I still do not know ""what version"" dhcp6c is on TomatoUSB. Also, dhcp6c on TomatoUSB has mention of some weird arguments such as "-T LL" which I can't find documentation for anywhere. I'm growing very tired of these weird outdated utilities that seem broken or inconsistent with present-day tools; this is the absolute #1 problem with consumer routers/firmwares like this, and has been the case for years. I've tried using the -D and -d arguments, in combination with -f (keep daemon in foreground) -- they don't change anything. No debug printing or verbose details are provided; -d and -D act as no-ops. -f does work though. Maybe there is some modification to dhcp6c in TomatoUSB where it requires the NVRAM debug_ipv6 variable to be set? 5. The Linux kernel is what's handling RAs received across the WAN (vlan2). For the default gateway, DHCPv6 doesn't provide that field any longer (proof); instead, RAs sent from the ISP (Comcast) are what eventually add the default route (added by the Linux kernel). This is the issue armarkey and myself were discussing above. In TomatoUSB when "DHCPv6 with Prefix Delegation" is chosen in the GUI, TomatoUSB itself issues a manual "ip -6 route add" command when that is completely/totally unnecessary. So, the "Enable RA from (WAN or LAN)" feature, when "DHCPv6 with Prefix Delegation" is used, serves zero purpose -- you must accept RAs from the WAN if using DHCPv6!
I've been experimenting with a couple things and have some interesting results to share. First, even though the public IPv6 address is being bound to the LAN port, I've been able to successfully ping my router's IPv6 address over the internet. I connected a laptop to a friend's wifi network checked that I had a tunneled IPv6 address (teredo tunnel on win7). Then I tried to ping the router and I got some echos back. I had quite a few dropped packets and high latency, but that may have just been due to using an automatic IPv6 tunnel. Second, I ran wireshark while my router had the spurious route and I think I can shed a little more light of what is happening in that case. Whenever I tried to do a ping6 google.com from the router or a computer within my network, the router would send out neighbor solicitation requests on the WAN. Since google obviously doesn't have any servers connected directly to the WAN port of my router there would be no response to any of these solicitation requests. About 2 or 3 seconds after the router send the neighbor solicitation packet on the WAN, it generated an address unreachable icmp reply on the LAN. The only packets I see on the WAN port are router advertisements and neighbor solicitations, whereas the LAN has only echo requests and address unreachable. Since the spurious route entry is missing a gateway, the linux kernel thinks it's directly connected to everything and that no packets will require any further routing hops. So when a packet is going to be sent out on that interface, it first has to perform the neighbor solicitation to make get the destination's mac address. When it doesn't get a neighbor advertisement reply within a few seconds, the packet is dropped and the address unreachable packet gets sent back to the source computer on the LAN. And finally: As far as getting a workaround that doesn't get trashed when the router reboots, I ran a test earlier today and got a working system. I took an old wrt54gl I had laying around connected it to only a single laptop (not the cable modem) and put a the most recent mini-ipv6 shibby firmware. Then I went to the Basic - IPv6 page and 1) selected DHCPv6 with Prefix Delegation 2) left the Enable Router Advertisements option selected 3) selected the Accept RA from WAN box (this one was off by default) Next I went to Administration - Scripts - WAN Up and added only the following line from koitsu's previous workaround script: Code: route -A inet6 del default gw :: metric 1024 `nvram get wan_iface` Once all that was done and everything saved, I pulled the power plug from the router and my cable modem and plugged the cable modem into the WAN port. Then I powered everything back on and once everything finished booting I had a router with working IPv6 forwarding. Since I did this on a newly flashed router (and nothing else), I think this can be considered the minimum configuration requirement than anyone should be able to setup and get things working. I'm guessing the missing step for people who didn't have success with the workaround script was that they didn't have the Accept RA from WAN box checked. Hopefully this will get IPv6 working for anyone still having issues.
You are the man. This worked for me. Thanks everybody for all of your efforts especially armarkey and koitsu. FYI : All I did was place the script in WAN Up and rebooted the router and I was good to go.
armarkey, it sounds like you and I found the solution at basically the same time. http://www.dslreports.com/forum/r27238880- http://www.dslreports.com/forum/r27239063- The only difference about my setup (compared to yours I think) is that for my FreeBSD box I statically configured the IPv6 address (again, don't want to get into explaining why -- it's a FreeBSD issue/thing and specific to my environment), and the IPv6 default route. The trick for me on FreeBSD was that for the default IPv6 route I had to use the zone index specifier (specifically "%em0") otherwise the system had no idea how to reach fe80::e2cb:4eff:fec0:c4. You should also probably consider using my WAN Up script methodology mentioned in the 2nd dslreports.com URL above instead of the blind "route -A inet6 del default gw" method. My script comments explain the situation a little more clearly. I intentionally flush (delete) all the IPv6 default routes, because I found that the "route del" and "ip route del" commands do not properly handle situations where there are multiple routes with the same metric. The only way to be ultimately sure that the right one gets deleted is to cease RA acceptance, flush all the default routes, and re-enable RA acceptance. In the previous version of the WAN Up script, there was a chance that the (RA-announced) default route might get deleted, depending on how soon Now a comment for Toastman -- and I need your general opinion/signoff on this, armarkey: I think the proper fix for this in the firmware is the following combination of things: 1. "Enable RA from WAN" should always be enabled when using "DHCPv6 with Prefix Delegation": period. It shouldn't even be a GUI option if that pulldown is chosen. 2. In release/src/router/rc/wan.c under the "case IPV6_NATIVE_DHCP" section, completely remove the "eval("ip", "route", "add", "::/0", "dev", (char *)wan_ifname);" call. IPv6 RA (via WAN) will take care of adding this default route. Once that's complete, the WAN Up script I mentioned in my 2nd dslreports.com URL above won't be needed. And of course, just to be clear: The IA-NA fix previously discovered is not needed. One does not need a /128 assigned to the WAN interface; it serves no purpose since the /64 delegated by Comcast includes an IP that TomatoUSB itself gets (assigned to br0).
Agreed, I think that should get us a build where the only setup step required is selecting DHCPv6. There are a few other changes that I think might be good but aren't needed to fix the current problems. 1. When configuring a native (manual) IPv6 address, there is no field to specify a gateway router. This means that the native manual configuration will have the exact same problems when trying to forward packets if "Enable RA from WAN" isn't checked. I think the correct thing to do here would be to give users the option of specifying a gateway and forcing the "Enable RA from WAN" option to be enabled if no gateway was specified. 2. For the IPV6_NATIVE case in rc/wan.c start_wan_done(), I think the eval("ip", "route"... line should only be executed if a specific gateway was configured (obviously the line will also need to be changed to pass the gateway to the ip command). 3. While everything seems to be functioning fine with the global address only bound to the LAN port, I think it would be better if an IPv6 address was bound to the WAN port as well. This could be the same address as the LAN port or even a different address. This would fix the issue we have now where the Status - Overview page doesn't show an IPv6 address on the WAN port which was adding somewhat to the confusion over what was actually broken. 4. start_dhcp6c() in rc/dhcp.c currently overwrites the /etc/dhcp6c.conf file every time the DHCP service is started. It would be nice if this was some way to prevent this if someone really wants to manually modify the configuration. I'd say this is the least necessary change since a sane autogenerated config that include suggestion #3 will probably eliminate just about any need to do this. But still, maybe an nvram option to disable writing the file if it already exists would be useful even if only as a debugging tool. 5. As koitsu mentioned earlier, the DHCPv6 client seems to be a modified version of the WIDE client that has some very weird behavior in its argument parsing. The debug options are ignored and it takes an extra undocumented -T option than no other clients use. I'd like to see this replaced or updated to something more modern and common. This is definitely a lower priority since it works as is and won't really affect any users. That's all I have for now. I'll probably start looking into #3 myself this weekend since that's the only thing that's still annoying me now that everything it working.
Can anyone shed some light on why it is that when I have IPv6 running on Tomato in any form (6to4, or tunnel or DHPCv6-PD) my logs fill up with "Neighbour table overflow" errors?
I'm not seeing that here, Lance (just checked) using DHCPv6 with Prefix Delegation. It's important to point out that, given our private Email discussion ( ), you are using the VPN tunnel feature of TomatoUSB, so I wouldn't be surprised if that had something to do with it. Could be some kind of route or packet forwarding ordeal where there's a loop of some kind (internal on the router itself). Hard to explain.
I don't think so. I think it's a lot more likely you're seeing too much ARP traffic, and probably from the WAN. It's well-known that with cable modems ARP broadcasts are happening constantly on the WAN side of things -- literally every customers' ARP traffic is received by other customers. It's been this way forever, even going back to the days of @Home (am I the only one who remembers them? Later named Excite@Home?). http://labs.cre8tivetech.com/2012/04/neighbour-table-overflow/ https://supportcenter.checkpoint.co...t_doGoviewsolutiondetails=&solutionid=sk43772 http://www.serveradminblog.com/2011/02/neighbour-table-overflow-sysctl-conf-tunning/ http://linuxman.wikispaces.com/Neighbour table overflow http://www.cyberciti.biz/faq/centos-redhat-debian-linux-neighbor-table-overflow/ Some of the articles mention using /etc/sysctl.conf. sysctl isn't available on TomatoUSB (not built into the kernel nor are the binaries available), tus /etc/sysctl.conf has no bearing on anything However, one of the articles provides the necessary /proc/sys/net equivalents of the variables. Those should work fine on TomatoUSB. Code: root@gw:/tmp/home/root# ls -l /proc/sys/net/ipv4/neigh/default/gc_thresh* -rw-r--r-- 1 root root 0 Jun 15 15:08 /proc/sys/net/ipv4/neigh/default/gc_thresh1 -rw-r--r-- 1 root root 0 Jun 15 15:08 /proc/sys/net/ipv4/neigh/default/gc_thresh2 -rw-r--r-- 1 root root 0 Jun 15 15:08 /proc/sys/net/ipv4/neigh/default/gc_thresh3 root@gw:/tmp/home/root# cat /proc/sys/net/ipv4/neigh/default/gc_thresh* 128 512 1024 I would recommend changing those to larger values, per the 2nd URL mentioned above. E.g.: Code: echo 256 > /proc/sys/net/ipv4/neigh/default/gc_thresh1 echo 512 > /proc/sys/net/ipv4/neigh/default/gc_thresh2 echo 1024 > /proc/sys/net/ipv4/neigh/default/gc_thresh3 However, keep in mind that IPv6 also has its own (separate) variables too: Code: root@gw:/tmp/home/root# ls -l /proc/sys/net/ipv6/neigh/default/gc_thresh* -rw-r--r-- 1 root root 0 Jun 14 23:56 /proc/sys/net/ipv6/neigh/default/gc_thresh1 -rw-r--r-- 1 root root 0 Jun 14 23:56 /proc/sys/net/ipv6/neigh/default/gc_thresh2 -rw-r--r-- 1 root root 0 Jun 14 23:56 /proc/sys/net/ipv6/neigh/default/gc_thresh3 root@gw:/tmp/home/root# cat /proc/sys/net/ipv6/neigh/default/gc_thresh* 128 512 1024 So you'd need to change both. You can change them on-the-fly (telnet/ssh in, etc.). If they work/solve your problem, then you can make them permanent (restored on reboot) by adding the commands to the Administration -> Scripts -> Init section of TomatoUSB. I think what's happening is that with the introduction of the IPv6 stack enabled, there's now twice as much ARP flowing (than if only IPv4 was being used), thus the thresholds need to be increased. The important part is that this has absolutely nothing to do with IRC. ARP is a layer 2 protocol; IRC is purely TCP (layer 4). I know way too much about IRC -- been on it since 1991, and helped write some of the code in ircd-hybrid and ircd-ratbox (open-source IRC servers).
Hi all, I've followed the discussion here, and tried the fixes discussed, and I've run into a problem that I haven't seen mentioned, and I'm not sure where the cause might be. Once I'd followed all the instructions, I found that I was able to route and ping, etc, and I thought everything was sorted - but then it suddenly stopped working, and then later on it would start again for a bit and so on and so on. It appears that I'm losing my default route, spontaneously, and then getting it back again eventually, and then losing it, and on and on forever. I've rebooted the cable modem and router a couple of times, with no effect. The logs on the router are unhelpful (just a stream of icmpv6_send errors, which might be due to my ping tests or maybe the failed RA? I don't know how to query the default route (the RA route never appears in the route -A inet6 output?) and if I do a successful traceroute6 and then try to ping or traceroute to the first hop during those times when things are broken, that doesn't work - but I don't know if the first hop is my modem or the first router past it. Does this make sense to anyone? One possibility is flaky hardware on the Comcast end, but I'm not sure how to establish that - I assume if I call tech support, they'll have no idea what I'm on about.
First, the model of router (E4200, etc.) likely has no bearing here. IPv6 is the same on the RT-N16 as it is on the E4200 as it is on the WRT54GS, etc... Secondly, let's please not turn this into one of those ever-so-common threads on the Internet where people start coming out of the woodwork to just post things like "me too". Thirdly, the issue described sounds like it may be caused by a physical problem (such as some layer 1 or layer 2 issue happening on the cable network -- your cable modem logs would greatly help here, as well as signal levels, etc.), but it's difficult for me to say. This would impact IPv4 too, but the only difference is that if this happened you wouldn't lose your default route in IPv4 (as well as things like DHCP, etc.) because of the nature of how it all works. (If you lost physical Ethernet link between your cable modem and your router that'd be different). The way all of this works is very different with IPv6. You've provided no output whatsoever from any command, so it's basically impossible for anyone here to troubleshoot. There's also the possibility that you're in a region where IPv6 support has been rolled out but its broken, or in a region where its in the process of being rolled out and is presently unstable. There's no way for anyone on this forum to determine that. Re: "I don't know how to query the default route (the RA route never appears in the route -A inet6 output?)" -- I don't even know what this means. You seem to think that IPv6 RA consists of "announcing a single route" -- it doesn't. Comcast is sending IPv6 RAs across the wire to IPv6 customers constantly. Many, many routes are announced. The default route is just one of them. There is no "single RA route" -- that term itself doesn't even make sense in this context. Re: "and if I do a successful traceroute6 and then try to ping or traceroute to the first hop during those times when things are broken, that doesn't work - but I don't know if the first hop is my modem or the first router past it" -- this is equally as confusing to comprehend. Assuming you're running traceroute6 from the router itself, the first hop would be a Comcast router. However, there isn't going to be a route announced for that router or anything like that (you need to learn how routing works ) if that's what you're thinking. If you're running traceroute6 from a machine on your LAN or WiFi network, then the first hop would be your TomatoUSB router. Next, the term "flaky hardware on the Comcast end" is totally grasping at straws. I don't think that's the case. But possibly something misconfigured on their network, bad RAs (or ones which are rejected), are very possible however. Finally, given what you're describing (and what appears to be (and I say this sincerely/humbly, honest!) a lack of networking knowledge), I think it would be easiest if someone was there in person to analyse your situation. Chances are tools like tcpdump are going to have to be used to look at the RAs and so on.
I've also been having the same problem.. but after much work over the weekend I believe I have it fixed. check out the thread at http://forums.comcast.com/t5/Home-Networking-and-Router-Help/Tomato-IPv6/td-p/1306317 I know MrKiasu has been following that thread... we've been back and forth on this problem. basically, something is causing the router to send neighbor solicitations (for the next hop, cable CMTS) on the wrong interface - it sends them on eth0 instead of vlan2. I've 'fixed' it by dropping and re-adding the link local addresses on br0, eth0, vlan1 so that vlan2 becomes the first interface in the route list. with that nasty hack, my IPv6 has been stable for hours now. my guess (at the moment) is that it's a bug in dhcp6c - not setting the correct scope_id (interface number) on the packets it sends, so it defaults to zero (first one in the list). a quick look at the source code suggests it is trying to do this.. but may not be getting it right. since my tomato compile blows up with openssl link errors, I can't get as far as rebuilding dhcp6c or even cross-compiling some simple test programs to get any further, yet.
Doing a quick read up on neighbor solicitations, it looks like they are designed to replace ARP and are used to find neighbors on your network so why would that have anything to do with dhcp6c? Looking at dhcp6c, I can't even find anything about neighbor solicitation or advertisements in it. The only thing I found in the code related to neighbor solicitations is in Zebra, iptables (icmp6) and the linux kernal (icmp6). Where do you believe the problem code lies? Also shouldn't the CMTS be returned by DHCPv6 already via the router assignment messages? Based on what I read on linked page below, it sounds like routers should response to router solicitations and actual neighbors (other devices on your network) should respond to neighbor solicitations. As such I would think neighbor solicitations being sent to your network would be correct. Then again, I'm still learning ipv6. http://packetlife.net/blog/2008/aug/28/ipv6-neighbor-discovery/
I believe the neighbor solicitations are done at the kernel level, yes. but the only software that is attempting to talk to the CMTS is dhcp6c (at least at first). because it uses link local addresses to talk to the CMTS, it must include the interface number (scope) out of band in the address. my theory, which I'm working on testing, is that it is not correctly setting the scope (although there is code there to do that, it may be broken..) if it doesn't set the scope, then it probably (most of the time) defaults to zero... which will be the first interface in the list. this is a theory ATM.. I've only just managed to get a tomato build to work, so I can cross compile some test programs. the other possibility is that the kernel is screwed..
OK, dhcpv6 appears to be doing the right thing. which tends to point to a kernel bug. I see this out there, which seems to be someone complaining of the same (or similar) issue on older kernels.. went away around 2.6.28.
I will be very impressed if the kernel can even be upgraded in TomatoUSB. The main reason relates to the binary blobs used for wifi capability being very ABI-sensitive (that means "userland-to-kernel" interface" for those not familiar; see Wikipedia for "application binary interface"). OpenWRT has been dealing with this situation for a very long time with some success, but gets stuck every so often (for example the reason they can't do RT-N16 support is because of Broadcom IP bullshit; they're talking with Broadcom directly right now but the company so far seems to be stonewalling/delaying giving them what they want or even providing regular responses). This is one of the main reasons I absolutely loathe Broadcom.
openwrt seems to be up to 2.6.39 at least.. that said, still not 100% certain it's a kernel bug.. could just be configuration screwup. if it IS a kernel bug, maybe we can determine when/how it was fixed and backpatch the fix.
My guess is it would be somewhere in the following code: http://repo.or.cz/w/tomato.git/tree/refs/heads/Toastman-RT:/release/src-rt/linux/linux-2.6/net/ipv6 Anyone know where Tomato's equivalent of the /etc/config/network file is? Also while not exactly related, when searching around, I noticed that apparently Linux also has issues with forwarding neighbor solicitations messages to devices behind gateways. See: http://www.ipsidixit.net/2010/03/24/239/ https://forum.openwrt.org/viewtopic.php?pid=150087
yes... I have a candidate patch that I'm looking at that was done between 2.6.27 and 2.6.28: http://git.et.redhat.com/?p=kernel-...in;h=dd3abc4ef52597ec8268274222574b2700ba3ded I've hand patched that into the 2.6.22 tomato kernel. the patch was a fix for using the routing tables to determine where to send packets, instead of preferring the source interface. I'll give it a whirl tonight and see if it makes any difference... and hopefully doesn't brick my router ;-O. I think both those are setup issues, either on the ISP or the router side.
OK, I've tried various kernel patches and not found one that fixes anything... HOWEVER I've figured out exactly what is triggering the kernel bug. the issue is that multicast ICMP packets (ie: those used by IPv6 for neighbor solicitation, routing, etc) get routed incorrectly if they get 'marked' by the conntrack code. this happens if you have QOS turned on, because all sorts of marking rules get added to the ip6 mangle firewall tables. so the simple 'fix' is to add a rule to the mangle tables to not mark icmp packets - we let 'ping' packets through, but all other ICMP is unmarked (and this does not get priority QOS.. which could be a slight problem). anyhow, add the following to your Administration->Scripts->Firewall: Code: # prevent neighbor solicitations and other low level ICMP messages from being 'marked', since # it seems to trigger a kernel bug that prevents them being sent on the correct interface ip6tables -t mangle -I OUTPUT 1 -o `nvram get wan_iface` -p icmpv6 \! --icmpv6-type echo-request -j RETURN so, in short: if you have QOS turned on, and use IPv6, you need the above script, or IPv6 will be flaky and drop out regularly.
Wow, nice find Adam. Yep, I don't use QoS features so I wouldn't have caught this. Again, very nice find. Another bug that needs to get fixed in a future TomatoUSB build... Also, just to clarify: I assume this firewall script needs to be added **in addition** to the existing IPv6 workaround scripts (in WAN Up)? I see all of these as separate issues and not compounded by each other.
I'd still like to find a kernel patch that could be applied - it's possible that a heavily congested connection could suffer with this 'fix', because we're deliberately not prioritizing the 'infrastructure' ICMP packets. that could cause problems (brief stalls, for example) if the neighbor solicitations can't make their way through the other traffic in a timely manner. I'll spend a little more time on this to see if I can find a kernel patch.
Sorry to double post: So a fix was found for ipv6 not working properly with Comcast, but neither Toastman, Teaman, nor Shibby have implemented it in their firmwares yet?
Yes that is correct, although phrased a bit crass (meaning I read it like "Toastman, Shibby, and Teaman are being lazy sods" ). Adam is working on trying to figure out if some of the oddities he's seen involve kernel fixes or not, because if they do, they should be applied there. The workarounds that are documented in this thread, for the time being, should be sufficient.
I'd just like to mention that when using TomatoUSB for IPv6 over PPP/ADSL, Accept RA from WAN *isn't* required when using DHCPv6 with Prefix Delegation. So it's not 100% true that Accept RA should *always* be on when using Prefix Delegation. You guys might be right about it in theory (and for Comcast cable), but in practice I've been running with it disabled for over 18 months using Internode (Australia) IPv6 ADSL with 0 issues I've not needed any special routes configured or firewall rules. But, just to make sure that any changes proposed aren't going to break connectivity for Internode users, I turned on Accept RA from WAN, disconnected PPP and then re-established a connection. I didn't reboot the router as I'm quite proud of the 114 days uptime . It all still works. So to clarify, using IPv6 PPP, this works: DHCPv6 with Prefix Delegation Prefix Length: 56 Enable Router Advertisements: On Accept RA from WAN: On or Off, doesn't matter. Accept RA from LAN: Off/Disabled Edit: Well, I just noticed that my iPhone now doesn't seem to have IPv6 any more. So I turned Accept RA from WAN back off, and the iPhone *still* doesn't. Hmm. Router and iMac are fine either way. So perhaps my iPhone IPv6 connectivity has been broken for a while and I didn't notice. It definitely used to work - it has done for months and months. Paul
Thread is about Comcast, not ISPs in Ozland. The need for having Accept RA on WAN checked is verified/validated here: http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/#post-184445 http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006/#post-184480 So again: you should have that checkbox checked given what the underlying code actually does with it (it allows IPv6 route announcements seen on the WAN to be forwarded to devices on the LAN, so that all your devices on the network that use IPv6 can get proper routes). Your ISP's behaviour may vary -- such seems to be the case for you, as they do not appear to advertise the default route using route announcements. However, there may come a time when they do, and you will be bit in the butt for having it off.
Yes, I'm aware the thread is about Comcast, I've read the whole thing. My point is that conclusions about certain features being broken and redundant were made with only Comcast as the test case. These conclusions are the basis for proposing changes to Tomato firmware, firmware that's used all over the world. I don't agree with the suggestion that the option 'Accept RAs from WAN' should be removed. Why bother? It's not breaking anything, other that its default value not being the most universally compatible. Fedor aka. TeddyB is/was a great developer and he didn't add features for the hell of it. He was very careful to stop TomatoUSB going down the route of being only an edge-facing device. Perhaps he though of reasons why you would want it turned off? I've just demonstrated that turning it off is completely fine for some people on some ISPs. My proposal would be to leave the option, but default it to On. And as for Internode potentially breaking my connection? Maybe. But they've been running the same system for nearly 3 years, and have worked with multiple CPE providers to get IPv6 support added. They'd be very careful not to break the ecosystem they developed. I dare say they've done more to get IPv6 to consumers (aside from scale) than Comcast have. The current DHCPv6 PD support in both Tomato and OpenWRT wouldn't be here without Internode customers 'scratching an itch'.
I am completely fine with the idea of leaving the option as toggle-able but defaulting to it being on. There should probably be a Notes section added to explain what the option actually does and how it may or may not be necessary on some ISPs with some examples ("ex. Comcast requires this, while Internode in Australia does not"). How's that sound?
Sounds good. I built from the Toastman-RT branch the other day for the first time in about 5 months. Once I'm happy with that I'll have a play around with changing the behaviour of the basic-ipv6 page, which would be nicer than just changing the default value to 1 here: http://repo.or.cz/w/tomato.git/blob/refs/heads/Toastman-RT:/release/src/router/nvram/defaults.c#l172 I was thinking that it would be nice if when you chose DHCPv6 with Prefix Delegation it checked the Accept RA WAN box for you, as a hint to what the most compatible default would be. Edit: Fixed typo - Lan should have been WAN
I think your issues are not specific to Comcast. My router is Buffalo WHR-G54S and the firmware is tomato-K26-1.28.7821MIPSR1-Toastman-ND-MiniIPv6.trx Everything worked fine using Hurricane Electric tunnel including computers running windows 7 and XPsp2. Then i got native ipv6 from internode.on.net which works fine with the router they supplied, Billion 7800N. Having ascertained that the native ipv6 connection works, I then switched to the Buffalo router running tomato. I have applied the gateway mod route -A inet6 del default gw :: metric 1024 `vnram get wan_iface` all linux boxes work OK , but the windows do not. Window ipconfig looks similar to as it did with the tunnel. Windows can ping the ipv6 gateway, the router and that's as far as they can go. No ping to ipv6.google.com. Switching from static tunnel mode to DHCPv6(prefix delegation) killed windows but did not kill linuxes and I wonder why?
I don't know why this fix (post #24) never got added to my releases. I will rectify that situation in the next release 7502. Apologies for the oversight.
