1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

IPv6 and Comcast

Discussion in 'Tomato Firmware' started by thunderforce, Jun 3, 2012.

  1. thunderforce

    thunderforce Networkin' Nut Member

    [​IMG]

    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]
     
  2. Daryl Martin

    Daryl Martin Serious Server Member

    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.
     
  3. nick ant0ny

    nick ant0ny Networkin' Nut Member

    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.
     
  4. zurk

    zurk Addicted to LI Member

    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
     
  5. LanceMoreland

    LanceMoreland Network Guru Member

    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.
     
  6. tvlz

    tvlz Addicted to LI Member

  7. LanceMoreland

    LanceMoreland Network Guru Member

    I see that. Now we just need to get it baked into the firmware so that a reboot doesn't wipe the changes.
     
  8. koitsu

    koitsu Network Guru Member

    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
     
  9. koitsu

    koitsu Network Guru Member

  10. LanceMoreland

    LanceMoreland Network Guru Member

    koitsu, I really appreciate it but I can't make it work.
     
  11. armarkey

    armarkey Serious Server Member

    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.
     
  12. koitsu

    koitsu Network Guru Member

    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?
     
  13. armarkey

    armarkey Serious Server Member

    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.
     
  14. koitsu

    koitsu Network Guru Member

    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.
     
  15. HunterZ

    HunterZ LI Guru Member

  16. Morac

    Morac Network Guru Member

    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
     
  17. koitsu

    koitsu Network Guru Member

    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
     
  18. koitsu

    koitsu Network Guru Member

    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).
     
  19. koitsu

    koitsu Network Guru Member

    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
    
     
  20. Morac

    Morac Network Guru Member

    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
     
  21. koitsu

    koitsu Network Guru Member

    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!
     
  22. armarkey

    armarkey Serious Server Member

    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.
     
  23. LanceMoreland

    LanceMoreland Network Guru Member

    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.

    [​IMG]
     
  24. koitsu

    koitsu Network Guru Member

    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).
     
  25. armarkey

    armarkey Serious Server Member

    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.
     
  26. LanceMoreland

    LanceMoreland Network Guru Member

    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?
     
  27. koitsu

    koitsu Network Guru Member

    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.
     
  28. LanceMoreland

    LanceMoreland Network Guru Member

    My son uses IRC and I have always suspected that has something to do with it.
     
  29. koitsu

    koitsu Network Guru Member

    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).
     
    beatnik likes this.
  30. LanceMoreland

    LanceMoreland Network Guru Member

    @Koitsu, Thanks
     
  31. MrKiasu

    MrKiasu Serious Server Member

    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.
     
  32. ROCKnTIME

    ROCKnTIME Serious Server Member

    I'm having the same issue with my E4200..
     
  33. koitsu

    koitsu Network Guru Member

    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.
     
  34. Adam Gundy

    Adam Gundy Serious Server Member

    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.
     
  35. Morac

    Morac Network Guru Member

    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/
     
  36. Adam Gundy

    Adam Gundy Serious Server Member

    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..
     
  37. Adam Gundy

    Adam Gundy Serious Server Member

    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.
     
  38. koitsu

    koitsu Network Guru Member

    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.
     
  39. Adam Gundy

    Adam Gundy Serious Server Member

    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.
     
  40. Morac

    Morac Network Guru Member

    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
     
  41. Adam Gundy

    Adam Gundy Serious Server Member

    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.
     
  42. Adam Gundy

    Adam Gundy Serious Server Member

    nope. same behavior. sigh.
     
  43. Adam Gundy

    Adam Gundy Serious Server Member


    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.
     
  44. koitsu

    koitsu Network Guru Member

    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.
     
  45. Adam Gundy

    Adam Gundy Serious Server Member

    yes, you also need the one-liner to remove the default IPv6 route.
     
  46. Adam Gundy

    Adam Gundy Serious Server Member

    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.
     
  47. thunderforce

    thunderforce Networkin' Nut Member

    Who would've thought my ipv6 question would spawn a programming party? :eek:
     
  48. thunderforce

    thunderforce Networkin' Nut Member

    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?
     
  49. koitsu

    koitsu Network Guru Member

    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.
     
  50. pmd

    pmd Networkin' Nut Member

    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 :D. 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
     
  51. koitsu

    koitsu Network Guru Member

    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.
     
  52. pmd

    pmd Networkin' Nut Member

    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'.
     
  53. koitsu

    koitsu Network Guru Member

    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?
     
  54. pmd

    pmd Networkin' Nut Member

    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
     
  55. Jaro Gress

    Jaro Gress Serious Server Member

    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?
     
  56. Toastman

    Toastman Super Moderator Staff Member Member

    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.
     
  57. tji

    tji Network Guru Member

    Just another comcast user reporting in.. Once I added Koitsu's script to my WAN-UP, My IPv6 worked fine.

    I am using a Toastman build from late 2012, so I guess I should upgrade that. With current builds, should this work without adding the script?
     
  58. koitsu

    koitsu Network Guru Member

    Yes. However, in recent builds the IPv6 RA capability has been moved to a different daemon (I'm not sure if this was reverted or not -- Kevin, can you comment?), which has introduced other/different problems. So don't confuse the two things.
     
  59. thunderforce

    thunderforce Networkin' Nut Member

    That's good to hear, koitsu, and it's much appreciated.
     
  60. Mohnish

    Mohnish Serious Server Member

    @koitsu I'm on Shibby's experimental ARM build and have Comcast as my ISP. With/without your script, I get the IP6 address for my router but ping fails from router to outside world. Error, "ping6: sendto: Network is unreachable". Any ideas why?

    Here's my ifconfig:

    br0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    inet addr:192.168.2.1 Bcast:192.168.2.255 Mask:255.255.255.0
    inet6 addr: 2601:4:1480:407:62a4:4cff:fe6b:d410/64 Scope:Global
    inet6 addr: fe80::62a4:4cff:fe6b:d410/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:4793 errors:0 dropped:0 overruns:0 frame:0
    TX packets:5330 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:587646 (573.8 KiB) TX bytes:2525689 (2.4 MiB)

    eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:21583 errors:0 dropped:0 overruns:0 frame:0
    TX packets:2629 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2008525 (1.9 MiB) TX bytes:483899 (472.5 KiB)
    Interrupt:179 Base address:0x4000

    eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:1178 errors:0 dropped:0 overruns:0 frame:117925
    TX packets:2099 errors:3 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:154576 (150.9 KiB) TX bytes:756182 (738.4 KiB)
    Interrupt:163

    eth2 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    inet6 addr: fe80::62a4:4cff:fe6b:d414/64 Scope:Link
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:3335 errors:0 dropped:0 overruns:0 frame:213
    TX packets:4197 errors:1 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:447480 (436.9 KiB) TX bytes:1981595 (1.8 MiB)
    Interrupt:169

    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:99 errors:0 dropped:0 overruns:0 frame:0
    TX packets:99 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:11088 (10.8 KiB) TX bytes:11088 (10.8 KiB)

    vlan1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    UP BROADCAST RUNNING ALLMULTI MULTICAST MTU:1500 Metric:1
    RX packets:235 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1285 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:44700 (43.6 KiB) TX bytes:260164 (254.0 KiB)

    vlan2 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
    inet addr:76.112.76.55 Bcast:76.112.79.255 Mask:255.255.252.0
    inet6 addr: fe80::62a4:4cff:fe6b:d411/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:21344 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1344 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:1575131 (1.5 MiB) TX bytes:223735 (218.4 KiB)
     
  61. rpress

    rpress Connected Client Member

    See my post here:

    Tomato for ARM routers
     
  62. Morac

    Morac Network Guru Member

    Does anyone know if it's still necessary to increase ARP cache sizes and GC thresholds in Toastman's (or anyone elses) builds to prevent the "Neighbour table overflow" warnings as mentioned in post #29.
     
  63. koitsu

    koitsu Network Guru Member

    "Necessary" is based upon your local area and environment; some people may need this, others may not. These shouldn't be increased by default / in a firmware update blindly either, because different router models have different amounts of RAM/resources. (There has been a strange increase in the number of people showing up on the forum with very tiny routers (little flash, little RAM) in the past month or so, for example).

    If you're asking "have the default values for these tunables changed?", the answer is no. If you want to know what changes between builds, you should check the source (find the tag you're interested in, click on "Log", then go through the "commitdiff" to see).

    Here are the "Comcast DSCP" commits:

    http://repo.or.cz/w/tomato.git/commitdiff/dec669e689f290e34b6fe9ad2f23b9b6bb93f75e
    http://repo.or.cz/w/tomato.git/commitdiff/870616169bce98c099f5bf273eb66e584db23de0

    P.S. -- @lancethepants you should fix the comment in release/src/router/nvram/defaults.c (you misspelled Comcast as Comacst :) ).
     
    Last edited: Aug 24, 2014
  64. jalind

    jalind Serious Server Member

    I am posting this here as it was last edited in August and is very clearly the newest of all the threads I've found in various forums regarding Comcast IPv6 not working with Tomato firmware . . .

    After several extremely frustrating days I'm about to declare that Tomato is once again broken regarding Comcast IPv6 - at least the Shibby variant - and very strongly suspect that some revision between 2012 when these threads started and now (November 2014) has broken it again. I am using an ASUS RT-N66U with Shibby 1.28.0000 MIPSR2-123 K26 USB AIO-64K which was released October 2014.

    I've tried everything here and in other threads, and including Comcast's own official documentation regarding their IPv6 and Tomato firmware. It does not work. To verify that IPv6 has been implemented in my area, I directly connected my Win7 desktop PC to the SURFboard SB6183 cable modem and rebooted both. The PC got native IPv6 without any problems and completely passed all the tests on the IPv6 test site. Through the router I only get the LAN IPv6 address, and do not get a WAN IPv6 address, the same symptoms many others reported with Comcast's IPv6.

    WAN:
    MAC Address 10:C3:7B:E0:96:21
    Connection Type DHCP
    IP Address 50.151.69.103
    Subnet Mask 255.255.254.0
    Gateway 50.151.68.1
    DNS 75.75.75.75:53, 75.75.76.76:53
    MTU 1500

    Status Connected
    Connection Uptime 0 days, 00:21:28
    Remaining Lease Time 2 days, 06:57:40​

    LAN:
    Router MAC Address 10:C3:7B:E0:96:20
    Router IP Addresses br0 (LAN) - 172.23.63.31/16
    Router IPv6 Address 2601:d:b300:3d5:12c3:7bff:fee0:9620
    IPv6 Link-local Address fe80::12c3:7bff:fee0:9620
    DHCP br0 (LAN) - 172.23.63.100 - 172.23.63.149​

    The router has IPv6 (in the Basic) section set to "DHCPv6 with Prefix Delegation" and a prefix length of 64, per Comcast's instructions and information here (and in several other threads on other forums). Please note that the check box for "Enable Router Advertisements" that is depicted everywhere there's a screen shot of the IPv6 configuration page, is now missing. Only the two check boxes for "Accept RA from: WAN and LAN" are there, both of which I've checked as I have two wireless bridges also on my LAN:
    Shibby Tomato IPv6 Config Page.jpg

    I've entered the two scripts for Firewall and WAN up. I've tried rebooting the cable modem, then the router, and rebooting the router, then the modem, and rebooting both simultaneously (simulating power outage and restoration). Nothing works. No IPv6 WAN address.

    One clue I did find that may explain the missing check box is this discovery browsing back through the change log and finding this under release 109:
    – Remove radvd & libdaemon, use dnsmasq for IPv6 RA instead – thx @Kevindiscovery​

    If that's the case, and the deletion of these has made the previous Firewall and Wan up scripts useless. Dropping back to Shibby 108 which contains these is a Big No Go. It's prior to the SSL Heartbleed fix (among other things; that's the deal breaker). If removal of radvd and libdaemon is the cause of breaking Comcast IPv6 again, what do I put into the custom dnsmasq to fix it? I've found this thread regarding custom dnsmasq in lieu of the radvd module (with recommendations to delete it and libdaemon from Tomato), but am clueless about exactly what script to use.
    http://www.linksysinfo.org/index.php?threads/ipv6-using-dnsmasq-for-ipv6-instead-of-radvd.68396/

    I'm left wondering what other versions of Tomato have also deleted radvd and libdaemon from their builds. I realize there are folks who have worked to unravel what was going on with Comcast and Tomato, most of which I do not understand very well, and what I do comprehend is at a very high level, not down into the nuts and bolts minutiae.

    Thanks,
    John
     
    AllenJ likes this.
  65. LanceMoreland

    LanceMoreland Network Guru Member

    Accept RA from Wan only and add the following lines to your firewall script

    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
    ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i vlan2 -d ff02::1:ff00:0/104 -j DROP

    This works for me with Shibby's firmware and will eliminate the neighbor table overflow errors.
     
  66. jalind

    jalind Serious Server Member

    Tried your Firewall script. Same as before. No WAN IPv6, only a LAN. Which Shibby build are you using? Is it 109 or later without radvd and libdaemon?

    If I understand earlier postings in this thread correctly, the firewall script(s) to deal with neighbor table overflow relate to issues that arise when QOS is enabled, which I have not done (it's disabled). If I've misunderstood your firewall script's purpose, please tell me.

    If I also understand how the RA Comcast requires works, without the radvd and libdaemon in Shibby's builds starting with 109, there must be a custom configuration entry in the dnsmasq section of the DHCP/DNS settings (under Advanced) to perform the required RA that was formerly done by radvd. That module (??) is no longer present to provide it and that's the reason the check box for it is now missing from the IPv6 settings. If this isn't a correct understanding, please enlighten me. I'm struggling very hard to understand how all this works, and it's why I asked about what script to use in the custom dnsmasq configuration section.

    Thanks,
    John
    [quickly wearing out the reboot buttons in the modem and router]
     
  67. LanceMoreland

    LanceMoreland Network Guru Member

    I am on Shibby 123. The neighbor overflow errors occur with or without QOS enabled but are area dependent. You may or may not get them depending on where you are. Before you give up on the first script for getting a WAN IPv6 address, make sure you reboot your modem and router. I have also seen other reports that indicate it may take a while for your modem to obtain an IPv6 address, even though I have never experienced that issue.

    Edit: Also make sure you have "Announce IPv6 on LAN" checked in the "Advanced">"DHCP/DNS" section.
     
  68. Morac

    Morac Network Guru Member

    IPV6 is working fine for me with Comcast on the latest Toastman version. I have "DHCPv6 with Prefix Delegation" set, the prefix length set to 64 and only WAN check for "Accept RA from".

    The Firewall and WAN scripts are no longer needed since the fixes have been built into firmware code. Also nothing needs to be added to the custom configuration entry in the dnsmasq section or anywhere else. IPv6 should just work without further tweaking.

    There's two new "Announce IPV6 on LAN" option in the "Advanced">"DHCP/DNS" section in the latest firmware as mentioned by LanceMoreland. One controls getting an IPv6 address via SLAAC and the other via DHCP. Both should be checked by default, which would give you two public IPV6 addresses. If neither is checked, you won't get a public IPv6 address on your LAN devices. Note that some devices only get SLAAC addresses and others only get DHCP addresses.
     
    beatnik likes this.
  69. jalind

    jalind Serious Server Member

    I've got that IPv6 option under "Advanced DHCP/DNS" checked, which I believe is the default, at least when IPv6 is enabled in some form in the Basic IPv6 settings. Is that the only script you are using, or are you using that in addition to the WAN Up script from armarkey and koitsu? It's still not working here in the ASUS.

    Thanks
    John
     
  70. jalind

    jalind Serious Server Member

    This is interesting as it's apparent from you description that Shibby has not (yet) implemented the changes Toastman made that satisfy the Comcast RA requirement(s). The current (as of Nov. 2014) 123 Shibby only has one "Announce IPv6 on LAN" option in the DHCP/DNS section -- a check box to turn it on or off. It may be worth an experiment with the current Toastman, although I'm reluctant to permanently convert everything from Shibby.

    From a practical perspective, getting IPv6 working isn't an urgent necessity at for me at this time and it doesn't have a high priority. I will continue picking away at it in between some things with higher priorities.

    Thanks,
    John
     
  71. Morac

    Morac Network Guru Member

    That change shouldn't be required to get an IP address. The check box was separated into two in Toastman's version after someone complained he was getting 2 public IPv6 addresses (SLAAC and DHCP assigned) and only wanted one.

    You can turn on logging of LAN side ipv6 RA, DHCP and SLAAC messages and see what's going on.
     
  72. AllenJ

    AllenJ Reformed Router Member

    Thanks for posting this excellent update. I have virtually the same configuration and have had no luck except for ping6 directly from the Tomato shell. I am running Shibby Tomato Firmware 1.28.0000 MIPSR2-124 K26AC USB AIO-64K.

    Thanks for all the hard work from everyone.

    EDIT: WTH?! -- ** IT WORKS NOW ** I checked immediately after posting this and making my latest round of edits. IT WORKS - for real. 10/10 from test-ipv6.com

    Best I can tell the Advanced -> DHCP/DNS -> Announce IPv6 on LAN did the main part of the fix.

    In Basic -> IPv6 I have DHCPv6 with Prefix Delegation - 64 - WAN checked... although I do get the "ip6tables-restore: line 89 failed" or "ip6tables-restore: line 88 failed" still.

    I also have the script fixes in place and for now, not going to touch them:

    Firewall:
    Code:
    # alternate fix per http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006
    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
    ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i vlan2 -d ff02::1:ff00:0/104 -j DROP
    
    WAN Up:
    Code:
    # http://www.dslreports.com/forum/r27234575-TomatoUSB-and-Comcast-IPv6-bugs-found
    #
    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
    ip -6 route flush default dev `nvram get wan_iface`
    echo 2 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
    I also did this earlier today via Windows CMD:
    netsh interface teredo set state disabled

    If anyone wants to debug and report, we would all be grateful.
     
    Last edited: Jan 2, 2015
  73. komugi

    komugi Addicted to LI Member


    These settings are working for me as well. I had everything but the Firewall script, after I added that script it worked.
     
  74. LanceMoreland

    LanceMoreland Network Guru Member

    Mine is working fine with the firewall scripts only.
     
  75. komugi

    komugi Addicted to LI Member

    This was previously working, but as of Build 128, it seems I am no longer able to pass the test-ipv6 site. However I can still ping6 ipv6.google.com from router SSH.

    I saw that shibby implemented SLAAC and DHCP ipv6 LAN items, and various changes. Has anyone gotten this working on the new build?


    EDIT: Seems like scripts are no longer needed. At least as of Build 128 (Not sure if this was implemented earlier or not).

    The options that needs to be enabled for proper IPv6 are as follows:
    [​IMG]
    [​IMG]

    Seems like 'Other ISP Config' makes it unnecessary to put in the scripts.
     
    Last edited: Mar 27, 2015
  76. LanceMoreland

    LanceMoreland Network Guru Member

    I couldn't make it work without the script.
     
  77. Matt Altus

    Matt Altus New Member Member

    So noticed that my httpd server was constantly restarting, tracked it back to dhcp6c constantly restarting it. It seems that since the 'send ia-na;' line was added to /etc/dhcp6c.conf (commit e3a7e88c2af327c9bcacfd2ac26c54f57185a23a) it constantly sends and receives packets. I have an Internode service and others in this thread have mentioned they were working.

    I've managed to work around the problem with the following wanup script.

    killall dhcp6c
    sed -i "s|send ia\-na 0;||g" /etc/dhcp6c.conf
    dhcp6c -T LL -d -D `nvram get wan_iface`

    Anyway would be nice to have an option to enable or disable this.
     
    Last edited: May 5, 2015
  78. churles

    churles New Member Member

    Struggled quite a bit but thanks to this thread was able to get IPv6 working on Comcast with Build 130.

    Basic > IPv6:

    DHCPv6 With Prefix Allocation
    Prefix Length: 64
    Accept RA From: WAN

    Other ISP Config NOT checked.

    The following Scripts as posted above by AllenJ:

    Firewall:

    Code:
    # alternate fix per http://www.linksysinfo.org/index.php?threads/ipv6-and-comcast.38006
    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/forwarding
    ip6tables -A PREROUTING -t mangle -p icmpv6 --icmpv6-type neighbor-solicitation -i vlan2 -d ff02::1:ff00:0/104 -j DROP
    WAN Up:

    Code:
    echo 0 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
    ip -6 route flush default dev `nvram get wan_iface`
    echo 2 > /proc/sys/net/ipv6/conf/`nvram get wan_iface`/accept_ra
     
  79. LanceMoreland

    LanceMoreland Network Guru Member

    Shibby's 131 release for ARM is now working properly with Comcast's IPv6 without the firewall scripts for me.

    Edit: I do still need the neighbor table overflow script though.
     
    Last edited: Aug 9, 2015
  80. Connor McCaffrey

    Connor McCaffrey Serious Server Member

    could you please tell me the script you are using?!?! :) please and thanks
     
  81. Connor McCaffrey

    Connor McCaffrey Serious Server Member

    you are my freakin hero, been at this 2 weeks and couldnt get it, this script instantly had everything working
     
  82. Beast

    Beast Network Guru Member

    I don't have comcast, I have charter cable. And this may be a dumb question.
    Charter uses 6rd relay and the 6rd Routed Prefix is defined like this 2602:100::/32

    What is the correct way to enter this into tomato???

    (1.) 6rd Routed Prefix 2602:100::/
    6rd Prefix Length 32


    (2.) 6rd Routed Prefix 2602:100::
    6rd Prefix Length 32

    (3.) 6rd Routed Prefix 2602:100
    6rd Prefix Length 32

    TIA
     
  83. tvlz

    tvlz Addicted to LI Member

    Should be this one
     
  84. dbz2k

    dbz2k New Member Member

    is wan up script still necessary because I keep getting weird issue with android and ipv6 it works great most of time, but sometimes ipv6 completely I wonder if that could be because it trying to use dhcpv6 instead of slaac which android doesn't support it for weird reasons.
     

Share This Page