dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
17789
share rss forum feed


RR Conductor
NWP RR Inc.,serving NW CA
Premium
join:2002-04-02
Redwood Valley, CA
kudos:1
reply to RR Conductor

Re: TomatoUSB and Comcast IPv6 -- bugs found

My setup-

Zoom 5341J Modem
Asus RT-N66U Router running Merlin's custom build of Asus's 3.0.0.3.108 FW.

I was thinking of trying out Tomato USB on my router, I am glad now I held off.



whfsdude
Premium
join:2003-04-05
Washington, DC
Reviews:
·Comcast
reply to RR Conductor

said by RR Conductor:

I just ran a test using Comcast's 6to4 Relay, and got this-

Speed tests are going to be highly inconsistent on 6to4. Comcast's relay is only for outbound traffic on 6to4 and has nothing to do with your inbound 6to4 path. That's determined by the network you're trying to connect to. They use their nearest 6to4 relay to send to you.


whfsdude
Premium
join:2003-04-05
Washington, DC
Reviews:
·Comcast

2 edits
reply to koitsu

Can you post the output of these three commands. I've set DHCPv6 w/ DHCPv6-PD on linux before so I might be able to help.

route -6 -n
brctl show
ifconfig -a

My guess is you're trying to route the PD prefix to Comcast's gateway when in fact its gateway is your point to point /128.

Edit for clarity:
/64's default gateway is your /128.

So you shouldn't need an outbound route for the /64 link as it should be the same as a connected route. Inbound you will need a route pointing the /64 to the br interface.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

2 edits

1 recommendation

Output in question is here, sans brctl.

»tomatousb.org/forum/t-484538/com···-1479712

brctl output is plain and simple, nothing crazy, and doesn't involve vlan2 (you wouldn't want to bridge that!).

root@gw:/tmp/home/root# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.e0cb4ec000c4       no              vlan1
                                                        eth1
 

Edit for clarity:
/64's default gateway is your /128.

We don't get a /128 on vlan2 unless the IA-NA fix (see first post of this thread) is put in place. And even if that fix is put in place, the default IPv6 gateway (::/0) chosen per IPv6 RA ends up being fe80::201:5cff:fe32:6e41 (which is a link-local address completely unrelated to anything on the router itself). Proof of that is available in this thread.

Edit: Actually, that proof isn't quite valid given the preceding statement in the same paragraph. That proof is without the IA-NA fix and without the default route fix in place (you can see that from the fact that the vlan2 interface has no /128 and the "spurious ::/0" route).

Welcome to the mess. :-) You might consider taking part in this thread over on the linksysinfo.org forums where armarkey and I are trying to figure out what's actually going on under the hood:

»www.linksysinfo.org/index.php?th···t.38006/
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


HunterZ

join:2003-07-16
Kent, WA

1 recommendation

reply to koitsu

koitsu, thanks a ton for keeping everyone posted on this. Hopefully it will be ironed out by the time Comcast turns on ipv6 in my area



Morac
Cat god

join:2001-08-30
Riverside, NJ
kudos:1
Reviews:
·Comcast
reply to koitsu

I've been trying to read up on how this is all supposed to work ( »manpages.ubuntu.com/manpages/har···f.5.html, »www.ietf.org/rfc/rfc3315.txt, »www.ietf.org/rfc/rfc3633.txt ) and from my understanding the delegating router (i.e. Comcast) is supposed to assign the requesting router (Tomato) a prefix. It's up to the requesting router to divvy that up into subnets and addresses and give it to local clients.

If Tomato is getting the prefix, which it sounds like it is, then Comcast should know to route any responses back to addresses that falls in that Prefix to Tomato, unless Tomato is mangling the outbound requests, but you already tested trying to do an inbound traceroute (which failed) so that seems unlikely. As such it sounds like the initial DHCPv6 setup is screwy since the delegating router doesn't know where the requesting router is.

Has anyone dumped out the actual DHCPv6 requests going back and forth?

The thing I find a bit odd is that Tomato does not appear to use the prefix to assign itself an iPv6 address on the WAN side. You'd think it would need one in order to talk for itself (as opposed to LAN clients) on the WAN side.

Speaking of the later, it sounds like the router is supposed to assign addresses to the LAN using the prefix with stateless address autoconfiguration and then announce those using router advertisements. That could be why routing is failing.

One thing I did notice looking at the code is that there is a "debug_ipv6" nvram setting which appears to enable debugging for both dhcp and radvd (but not dhcpv6).

Most of the code regarding DHCP and router advertisements is in dhcp.c and services.c in »repo.or.cz/w/tomato.git/tree/ref···outer/rc

DHCPv6 is implemented in »repo.or.cz/w/tomato.git/tree/ref···r/dhcpv6

ipV6 is implemented as part of Linux in »repo.or.cz/w/tomato.git/tree/ref···net/ipv6
--
The Comcast Disney Avatar has been retired.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

said by Morac:

I've been trying to read up on how this is all supposed to work ( »manpages.ubuntu.com/manpages/har···f.5.html, »www.ietf.org/rfc/rfc3315.txt, »www.ietf.org/rfc/rfc3633.txt ) and from my understanding the delegating router (i.e. Comcast) is supposed to assign the requesting router (Tomato) a prefix. It's up to the requesting router to divvy that up into subnets and addresses and give it to local clients.

If Tomato is getting the prefix, which it sounds like it is, then Comcast should know to route any responses back to addresses that falls in that Prefix to Tomato, unless Tomato is mangling the outbound requests, but you already tested trying to do an inbound traceroute (which failed) so that seems unlikely. As such it sounds like the initial DHCPv6 setup is screwy since the delegating router doesn't know where the requesting router is.

Has anyone dumped out the actual DHCPv6 requests going back and forth?

Yes, I have done this. Let me explain the annoyance however:

The problem with using tcpdump on TomatoUSB is that it (and libpcap) is extremely old and does not have decent IPv6 support. I'm using the one available via ipkg, which come from »ipkg.nslu2-linux.org/feeds/optwa···/stable/ --

libpcap - 1.0.0-2 - PCAP Library
tcpdump - 4.0.0-1 - tcpdump dumps the traffic on a network
 

Old. Ancient. Horrible. The problem is that these can detect IPv6 packets (based on protocol header) but it cannot decode any of the IPv6 header data/etc.. This requires one to do the following:

kill `cat /var/run/dhcp6c.pid`
tcpdump -p -l -n -s 0 -i vlan2 -w /tmp/filename.pcap
 

Then in another window...

dhcp6c -T LL vlan2
 

Then wait a while, let things settle (it can sometimes take up to 120 seconds for DHCPv6 to fully do its thing; sometimes Comcast's servers don't respond to the request immediately). Then once you decide "I hope things are done", you have to do:

scp -p /tmp/filename.pcap user@someboxthatrunssshd:
 

And then look at the file using Wireshark.

It would be a lot easier if I had an inline tap which could look at packets flowing across the WAN port of my RT-N16, but I'd rather not go down to my garage and have to dig out my rack-mounted HP ProCurve switches just to get port mirroring. I do not have any hubs (god forbid anyone! ;-) ).

said by Morac:

The thing I find a bit odd is that Tomato does not appear to use the prefix to assign itself an iPv6 address on the WAN side. You'd think it would need one in order to talk for itself (as opposed to LAN clients) on the WAN side.

And that is exactly what the IA-NA problem/fix is about. By enabling IA-NA in dhcp6c.conf, you do get a single IPv6 address (/128) on vlan2. However, as arkmarkley and other people have stated, this shouldn't be needed.

What should be happening is that Comcast should be delegating a /64 prefix to the customer, which then gets assigned to the br0 interface on TomatoUSB. That part works.

TomatoUSB should then be forwarding any outbound packets (from any IPv6 member on the /64 LAN to the Internet) to the default IPv6 gateway on the router itself.

Likewise, Comcast's routers should know that packets destined to the /64 prefix should be sent to the address delegated with that /64. Let me explain what I mean by that:

Comcast DHCPv6 hands me 2601:9:4600:4f:e2cb:4eff:fec0:c4/64, which gets assigned to br0.

In English (using wildcard syntax), that means 2601:9:4600:4f:* is mine.

Likewise, since Comcast has delegated me 2601:9:4600:4f:e2cb:4eff:fec0:c4 -- which is a single IPv6 address -- their routers should know to send packets destined for 2601:9:4600:4f::/64 to 2601:9:4600:4f:e2cb:4eff:fec0:c4.

Thus, the whole IA-NA fix ("getting a /128 IPv6 WAN IP on vlan2") really shouldn't be required. The TomatoUSB router which gets 2601:9:4600:4f:e2cb:4eff:fec0:c4 should be able to talk to the world using that address, and clients (on the LAN) using that same /64 prefix should be able to talk to the world as well.

said by Morac:

Speaking of the later, it sounds like the router is supposed to assign addresses to the LAN using the prefix with stateless address autoconfiguration and then announce those using router advertisements. That could be why routing is failing.

But that wouldn't explain why in my case (see Linksysinfo.org forum posts) with statically-assigned IPv6 it isn't working.

To me, this almost looks like something on the Comcast side is not configured, route-wise, to forward packets destined to the /64 prefix to the IPv6 address they delegate.

The official Comcast forum thread with people testing IPv6 using a web browser isn't helpful because nobody is showing what actually gets delegated / announced / etc.. The only post I can find that has even remotely useful information is this picture, which is from a customer's router, where he also decided to edit the picture and hide his MAC prefix section:

»forums.comcast.com/t5/image/serv···-1&px=-1

VERY IMPORTANT: Note that in that photo, he has a "WAN IPv6 Address" with a /128. The only way to get that is to enable the IA-NA fix I mentioned in this thread (first post), but doing that DOES NOT solve the issue of packets from the /64 prefix LAN going out the Internet and coming back.

I wish that guy would have provided his router's routing table!!

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23
reply to koitsu

HOLY CRAP, I GOT IT WORKING! (packets via LAN)

$ uname -a
FreeBSD icarus.home.lan 9.0-STABLE FreeBSD 9.0-STABLE #0: Fri Jun  8 18:09:07 PDT 2012     root@icarus.home.lan:/usr/obj/usr/src/sys/X7SBA_RELENG_9_amd64  amd64
$ ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2601:9:4600:4f:230:48ff:fed2:22d0 --> 2001:4860:4001:800::1011
16 bytes from 2001:4860:4001:800::1011, icmp_seq=0 hlim=55 time=74.223 ms
16 bytes from 2001:4860:4001:800::1011, icmp_seq=1 hlim=55 time=78.878 ms
16 bytes from 2001:4860:4001:800::1011, icmp_seq=2 hlim=55 time=130.185 ms
^C
--- ipv6.l.google.com ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 74.223/94.429/130.185/25.355 ms
 

Still doing more testing though... please hold...

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 edit

2 recommendations

Okay, a follow-up to my own "IT WORKS!" post with some details.

I can confirm that at this point:

1. My TomatoUSB router is able to talk IPv6 to the Internet directly (e.g. ping6 ipv6.google.com from TomatoUSB natively works),

2. My FreeBSD box on my LAN is able to talk IPv6 to the Internet directly (e.g. ping6 ipv6.google.com from FreeBSD works). IMPORTANT: My FreeBSD box is statically configured for IPv6, it is not configured to dynamically get an IPv6 prefix/etc. from the TomatoUSB router.

I have rebooted my RT-N16 and done the manual fix-ups needed and it does in fact work reliably.

Now for the details:

1. The IA-NA fix (in dhcp6c.conf) ISN'T NEEDED. And that seems correct/logical given what I described in my earlier post. There is absolutely no need for a /128 address on the WAN interface (vlan2).

2. The "spurious default route" fix IS NEEDED. Removing the spurious route is absolutely required. Simply put: there should be only one default route for ::/0 and it should be an fe80::xxx address (negotiated via IPv6 RAs announced from Comcast).

3. Under Basic / IPv6, the WAN checkbox for "Accept RA from" must be checked. This is the only way to ensure that the TomatoUSB router gets a default IPv6 gateway from Comcast (DHCPv6 does not negotiate this; its announced via IPv6 RAs. This greatly differs from classic IPv6 DHCP, for those familiar with it).

4. Under Basic / IPv6, the "Enable Router Advertisements" checkbox is probably required for systems on a LAN which don't have statically configured IPv6 addresses and default IPv6 gateways. This checkbox makes it so that IPv6 RAs (from TomatoUSB to the LAN) are sent across the LAN. It has no bearing on the IPv6 RAs received via WAN from COmcast.

5. For statically-configured IPv6 machines on a LAN (like my FreeBSD box) only, it's very important that for the default gateway you ensure that you use the link-local IPv6 address of the TomatoUSB system (that would be the "Scope:Link" IPv6 address shown for interface br0), and that you use a zone index using the %index syntax as described here:

»en.wikipedia.org/wiki/IPv6_addre···_indices

Without use of the zone index, you cannot do something like "route add -inet6 default fe80::e2cb:4eff:fec0:c4" because the system has no idea what interface (zone index) is associated with the fe80::xxx address. On FreeBSD, without the zone index specifier, you get an error such as "Network unreachable" when trying to add the default route.

In the case of machines which are not statically routed, I imagine that IPv6 RAs (received from the TomatoUSB router across the LAN) should negotiate all of this stuff dynamically. I haven't gotten to that phase yet; I imagine that is the phase/methodology that most of the people on this forum will use, but for my setup I cannot use it at this point in time (has to do with issues/complexities with FreeBSD and what it does when recieving IPv6 RAs). Baby steps!

So, the WAN Up script I'm using now is the following, again, with 100% success (including after a reboot):

#
# Workaround for TomatoUSB bug where a spurious default IPv6 route is
# added for no justified reason, resulting in packets getting forwarded
# effectively to /dev/null.
#
# 1. Temporarily disable accepting IPv6 RAs on the WAN interface.  This
#    will stop the kernel from automatically adding a default IPv6 route
#    when such an RA is received via the WAN.
# 2. Delete ALL default IPv6 routes.  In effect this deletes the spurious
#    IPv6 default route, as well as any default IPv6 routes received via RA.
#    Sadly the "ip" command does not give you a way to differentiate between
#    the two, since the one we truly want to delete lacks "proto kernel".
# 3. Restore honouring IPv6 RAs via the WAN.  Within 60-120 seconds (often
#    within seconds on Comcast) a default IPv6 route should be added by the
#    kernel.  You can use "ip -6 route show default dev `nvram get wan_iface`"
#    to verify; you should have only one route ("default via fe80::xxx ...").
#
# 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
 

And before criticising the script ( :-) ) please be sure to read the comments in the script; its written this way for a reason.

For those who have tried/used the IA-NA fix previously mentioned, please replace your WAN Up script with the one above and then reboot the router. (Yes, there is a way to do this without rebooting, but the instructions would be long and I'd rather not explain it. It involves editing /etc/dhcp6c.conf to remove the ia-na bit, restarting dhcp6c with its previous arguments, then running the above WAN Up script by hand)

--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


NathanO

join:2008-08-21
Moorestown, NJ

Can you post your ifconfig output?



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

said by NathanO:

Can you post your ifconfig output?

For which box? The TomatoUSB router or my FreeBSD system?
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


NathanO

join:2008-08-21
Moorestown, NJ

TomatoUSB If you don't mind.



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

2 edits

1 recommendation

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:45925 errors:0 dropped:0 overruns:0 frame:0
           TX packets:47375 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:3860081 (3.6 MiB)  TX bytes:11130952 (10.6 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:181168 errors:0 dropped:0 overruns:0 frame:0
           TX packets:92179 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:21808810 (20.7 MiB)  TX bytes:15741818 (15.0 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:15 errors:0 dropped:0 overruns:0 frame:438284
           TX packets:640 errors:9 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:2846 (2.7 KiB)  TX bytes:272035 (265.6 KiB)
           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:10 errors:0 dropped:0 overruns:0 frame:0
           TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:1330 (1.2 KiB)  TX bytes:1330 (1.2 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:45918 errors:0 dropped:0 overruns:0 frame:0
           TX packets:47392 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:4043263 (3.8 MiB)  TX bytes:11323312 (10.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:135247 errors:0 dropped:0 overruns:0 frame:0
           TX packets:44781 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:14504373 (13.8 MiB)  TX bytes:4417878 (4.2 MiB)
 

Important bits:

1. Comcast via DHCPv6 delegates to me 2601:9:4600:4f::/64. This will certainly vary per person.

2. My br0 interface (WiFi+LAN) has the IPv6 address 2601:9:4600:4f:e2cb:4eff:fec0:c4. This is part of the delegation from Comcast (hard to explain; the last 64 bits are a combination of the interface MAC address -- rather not get into it).

3. Be sure when reading the IPv6 addresses that you take note of the Scope:Global and Scope:Link specifiers. Global what comes from Comcast (effectively), and Link is the local-link address (self-generated).

And just to add further clarification: my FreeBSD box has IPv6 address 2601:9:4600:4f:230:48ff:fed2:22d0 (prefix length 64 too), and as you can see, that also falls within 2601:9:4600:4f::/64 which is delegated by Comcast.

It's actually classic/simple subnetting, just with two octets (16 bits) per section (0-65535, or 0 to ffff) and a colon delimiter, rather than a single octet (8 bits per section, or 0-255) and a dot/period delimiter like IPv4.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


starsilk

@comcast.net
reply to koitsu

there is an ipv6 enabled version of tcpdump that works fine in tomato here:

»code.google.com/p/wl500g/downloa···can=2&q=



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

said by starsilk :

there is an ipv6 enabled version of tcpdump that works fine in tomato here:

»code.google.com/p/wl500g/downloa···can=2&q=

Thank you -- yeah, that one seems to have decent support for decoding packets, although it's still incredibly old. I found this to be much more useful and up-to-date:

»multics.minidns.net/blog/article···ilities/

The guy who does all these builds is user rhester72 on the linksysinfo.org forums.

You can download either a statically-linked version of the software you need from here:

»multics.minidns.net/tomato/PRECO···-static/

Or you can download dynamically-linked versions from here, but you'll need to know which libraries the binary is linked to (can determine that from ldd or just running the binary and seeing what libxxx.so.x files it complains about):

»multics.minidns.net/tomato/PRECOMPILED/
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.

Petermjjh

join:2005-04-03
Bloomfield Hills, MI
reply to koitsu

Thank you for all of your hard work koitsu!! This morning I updated my router to Toastman's latest build and added your script to the WAN UP section, IPv6 worked perfectly right away! Thank you again!

I was afraid I would need to go out and buy an AirPort Extreme if the community couldn't get this working. You were sure to keep everyone on the same page while bringing multiple communities together to help. Not to mention you did loads of investigative work yourself and wrote the fix.

I am looking forward to the release of an updated firmware with both the fix and other IPv6 enhancements you and the community suggest baked in.



RR Conductor
NWP RR Inc.,serving NW CA
Premium
join:2002-04-02
Redwood Valley, CA
kudos:1
reply to koitsu

Re: [IPv6] TomatoUSB and Comcast IPv6 -- bugs found

Maybe one of you guys can get Native IPv6 working on the Asus RT-N66U now



koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 recommendation

said by RR Conductor:

Maybe one of you guys can get Native IPv6 working on the Asus RT-N66U now

I believe the issue/bug in question would apply to all TomatoUSB Toastman builds with IPv6 support, regardless of hardware model. The "spurious default route" issue does not apply to a specific model of device.

The RT-N builds (for MIPSR2 CPUs, which includes the Asus RT-N66U) from Toastman are here (most people will want the STD builds, not VLAN; IPv6 is only included in the builds labelled "VPN" or "MiniIPV6"): »www.4shared.com/dir/v1BuINP3/Toa···18604379

It looks like 4shared is having problems though (either that or something else is going on; maybe Toastman is doing firmware builds right now?) where there are no files shown in those directories.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.


RR Conductor
NWP RR Inc.,serving NW CA
Premium
join:2002-04-02
Redwood Valley, CA
kudos:1

said by koitsu:

said by RR Conductor:

Maybe one of you guys can get Native IPv6 working on the Asus RT-N66U now

I believe the issue/bug in question would apply to all TomatoUSB Toastman builds with IPv6 support, regardless of hardware model. The "spurious default route" issue does not apply to a specific model of device.

The RT-N builds (for MIPSR2 CPUs, which includes the Asus RT-N66U) from Toastman are here (most people will want the STD builds, not VLAN; IPv6 is only included in the builds labelled "VPN" or "MiniIPV6"): »www.4shared.com/dir/v1BuINP3/Toa···18604379

It looks like 4shared is having problems though (either that or something else is going on; maybe Toastman is doing firmware builds right now?) where there are no files shown in those directories.

Thanks for the info and links!
--
»www.amtrak.com
»www.freightrailworks.org
»www.isu.edu
»www.northcoastrailroad.org
»www.amtrakcalifornia.com
»www.cahighspeedrail.gov

scajjr

join:2005-03-01
Kingston, NH
Reviews:
·Comcast
reply to koitsu

said by koitsu:

said by RR Conductor:

Maybe one of you guys can get Native IPv6 working on the Asus RT-N66U now

»www.4shared.com/dir/v1BuINP3/Toa···18604379

It looks like 4shared is having problems though (either that or something else is going on; maybe Toastman is doing firmware builds right now?) where there are no files shown in those directories.

Hit refresh on your browser after you select a directory then the files show up.

Another RT-N66U user BTW.
Sam


RR Conductor
NWP RR Inc.,serving NW CA
Premium
join:2002-04-02
Redwood Valley, CA
kudos:1
reply to koitsu

Well, Asus released the new FW for this router today, but unfortunately Native IPv6 STILL isn't working.

»support.asus.com/download.aspx?S···GWzVROxT



whfsdude
Premium
join:2003-04-05
Washington, DC
Reviews:
·Comcast

said by RR Conductor:

Well, Asus released the new FW for this router today, but unfortunately Native IPv6 STILL isn't working.

If you haven't yet, I would open a ticket with them for DHCPv6-PD support. Probably by email would be best if you want it to get passed along.


RR Conductor
NWP RR Inc.,serving NW CA
Premium
join:2002-04-02
Redwood Valley, CA
kudos:1

1 recommendation

said by whfsdude:

said by RR Conductor:

Well, Asus released the new FW for this router today, but unfortunately Native IPv6 STILL isn't working.

If you haven't yet, I would open a ticket with them for DHCPv6-PD support. Probably by email would be best if you want it to get passed along.

We have over on the Asus forums, but Asus either has said certain issues don't exist, or they promise things they never deliver on. I love their stuff, but their customer support leaves a LOT to be desired. I guess we'll keep bugging them, maybe it will actually pay off someday.
--
»www.amtrak.com
»www.freightrailworks.org
»www.isu.edu
»www.nwprr.net
»www.amtrakcalifornia.com
»www.cahighspeedrail.gov


koitsu
Premium,MVM
join:2002-07-16
Mountain View, CA
kudos:23

1 recommendation

reply to koitsu

Another bug relating to IPv6 support in TomatoUSB was found today by a user over on the Linksysinfo.org forums.

This one applies only to individuals with QoS enabled and IPv6 enabled in their routers.

Details:

It appears that when QoS is enabled in TomatoUSB, ICMPv6 messages used for IPv6 neighbour solicitations and IPv6 RAs will be sent out across the wrong physical interface. The impact will be flaky or unreliable IPv6 connectivity in general. (I personally did not encounter this bug because I do not use QoS).

Whether or not this is an actual kernel bug that has been fixed in a newer Linux 2.6 release is unknown at this time. Changing/upgrading kernels in Tomato/TomatoUSB is difficult given that the WiFi driver for many routers is a binary blob provided by Broadcom, and the kernel ABI in Linux tends to change. In other words, changing kernel versions may cause WiFi driver problems or incompatibility issues, so upgrades must be done carefully -- else fixed backported manually (which is time-consuming and often complex).

Permanent fix:

There is currently no permanent fix. The necessary code changes are being discussed with Toastman.

This section will be updated when a new beta/test Toastman build is available with the fixes.

Workarounds:

User Adam Gundy on the Linksysinfo.org forums has provided a workaround script. Details are in this post:

* »www.linksysinfo.org/index.php?th···t-184811

The workaround script should be placed in Administration -> Scripts -> Firewall.

Furthermore, this workaround is independent of the previous/aforementioned workarounds for IPv6 support. Meaning: if you use QoS, you will have to apply this workaround, in addition to the ones mentioned in earlier in this thread.
--
Making life hard for others since 1977.
I speak for myself and not my employer/affiliates of my employer.