TomatoUSB

WRT360N v3 is running IPv6 "Native from ISP". Wireless mode is set as "Access Point"

WRT54GL router upstairs is also running TomatoUSB, however as a "Client Bridge", connecting to the access point of WRT360N, allowing me to connect ethernet to the router and transfer over wifi.

My question is, connecting directly to the WRT360N with my laptop, I get IPv6 no problem, however connecting via Ethernet from the WRT54GL to the WRT360N over wifi does not work, I get no IPv6.

Is this possible, am I missing a setting?

Thanks,
Sam

Hmmm. You're probably not missing anything — there haven't been any GUI settings added for managing IPv6 subnets, and I don't think anything has been tested or written to ensure IPv6 is working in bridging configurations.

Is the wireless mode on the GL set to "Wireless Ethernet Bridge" or "Wireless Client" ?

If "Wireless Ethernet Bridge": it *probably* should automatically work, but I wouldn't be surprised to hear it doesn't. I'm not really familiar with how that's set up but I think that mode is mostly a function of the (closed source) Broadcom wireless driver, which would make hard to fix to work as it should. You could, as a workaround, do what I describe for the other case, but then your IPv4 and IPv6 subnets won't line up, which could cause problems/weirdness.

If "Wireless Client": it won't work on its own, you'll need to configure the second router to advertise its own IPv6 subnet, and set the first router to route that subnet.

You're with TekSavvy, right?

Let's assume the /56 prefix they assigned you was 2607:f2c0:1234:ab00:: — those last two zeros there are the 8 bits you can use to define your own subnets (individual subnets are normally /64 bits in IPv6). The following directions should set the first router to use […]:ab00::/64, the second router to use […]:ab01::/64, and tells the first router to send traffic for that second subnet to the second router.

1. Make sure the IPv6 prefix on the first router is set to 2607:f2c0:1234:ab00:: and prefix length 64. Enable Router Advertisements. That's the important part. You can leave the Router IP field blank and it will default to 2607:f2c0:1234:ab00::1
2. On the second, client router, set the IPv6 mode to Native, and the prefix to 2607:f2c0:1234:ab01:: with prefix length 64, and enable Router Advertisements.
3. Figure out what the second router's link-local address on its Wifi interface will be. With the GL, if IPv6 is already enabled on it, you can check this by running

ip -o -6 addr show dev eth1 scope link

If the MAC address is 00:14:BC:4A:B3:67 then it's link-local IPv6 address will be fe80::0214:bcff:fe4a:b367, which is (roughly) derived as follows:

1. Always starts with fe80::
2. the first digit of the mac address, THE SECOND DIGIT PLUS TWO, the third and fourth digits, then colon.
3. 5th and 6th digits, then "ff:fe"
4. then the rest of the MAC address, with a colon placed appropriately so that everything is nicely divided into four-character segments.

Once you have that address, add a line to the Init script of the *first* router to establish a route pointing to the second, e.g.:

ip route add 2607:f2c0:1234:ab01::/64 via fe80::214:bcff:fe4a:b367 dev br0

This is all off the top of my head. It *should* work but I'm not in a position to test it at the moment, so there might be minor glitches.

Later this week I'll have a chance to borrow a router my brother isn't using so I can actually test this, and probably make some simple changes that should make the last step unnecessary.

IPv6 won't work in the Wireless Ethernet Bridge mode. This is because the Broadcom driver doesn't support it, see some explanation here, for example (this is about the hardware wireless bridge, but the same concepts apply to the WET mode on a Broadcom router). I've played with this before, and got the same results as described in the article linked above - the bridge router and the clients connected to it were able to obtain the advertised prefix, and configure the IPv6 address and routing just fine, but no ping of the outside addresses possible.

I have not experimented with IPv6 in a wireless client mode, but I see no reason for it not to work - please post your experience here if you try what Westacular suggested. Another alternative is WDS which also should work with IPv6 (although WDS in general might be tricky to setup - but that's another subject).

Hello Westacular and teddy_b,

I indeed tried with Wireless Ethernet Bridge, and it did not work. Checking that explanation that was linked, and your own experience, I did have the same results, obtained the prefix, proper routing, but no pings outside.

Pinging ipv6.l.google.com [2001:4860:b007::6a] with 32 bytes of data:
Destination host unreachable.

I have been quite busy this week so to attempt either Wireless Client or WDS, I'll do it ASAP and get back to you regarding my results. Never even heard of WDS, so I'll probably just go for Wireless Client.

Thanks for the help you 2 and I'll try your suggestions out!

-Sam

I have a few things to amend my previous directions. (This is as much a note to myself as it is anything else — I just did some testing of this, but I'm not currently at home to actually do the coding to fix this)

Some of the automatic settings on the second router won't work and need to be replaced/overridden. Specifically: the firewall rules stop it from being able to do neighbour detection on the WAN link (WAN in this case being the LAN to the first router) and the default route on the second router won't work ("default dev eth1" is only functional on a point-to-point link).

Figure out what the link-local IPv6 address of the first router is (by doing the same as above, or looking at what the default ipv6 route/gateway is for clients connected to it). Let's say it's fe80::212:17ff:fed8:6391.

Then place the following in the WAN Up script on the second router:

ip -6 route del default dev eth1
ip -6 route add 2607:f2c0:1234:ab00::/64 dev eth1
ip -6 route add default via fe80::212:17ff:fed8:6391 dev eth1

(assuming, as before, that 2607:f2c0:1234:ab00::/64 is the prefix set for the first router, and eth1 is the device name for the wifi on the second)

and in the Firewall script:

ip6tables -A INPUT -p icmpv6 -i eth1 -j ACCEPT

Though really, all of the extra stuff in this post shouldn't be necessary once a few things are fixed. Teddy_bear just added a "listen for Route Advertisements on WAN" option that would almost do all of this, but there are a few bugs that need to be fixed. Specifically: (a) if that setting is enabled, the firewall rules should automatically allow the appropriate ICMPv6 traffic on the WAN port to actually ALLOW that to happen, and (b) if that setting is enabled (and/or possibly if the basic WAN setting is static or DHCP, implying it's not a point-to-point link), the router should NOT set an ipv6 route of "default dev $wanface", because that won't work and will just get in the way.

I'm also thinking that if would be helpful (especially for those new to IPv6) to automatically list the router's configured ipv6 addresses, especially the link-local ones, on the status and/or IPv6 config pages. With some improvements to ipv6-enable the static routing settings, it should be possible to do all this directly with information and settings in the web ui, and without any scripting.

Teddy_bear just added a "listen for Route Advertisements on WAN" option that would almost do all of this, but there are a few bugs that need to be fixed.

Yep, these changes are not finished yet, and so far I've only been playing with it from the LAN side.

ICMPv6: what do you think about allowing all traffic listed in RFC4890 sec. 4.4.1 through the INPUT chain, regardless of any router settings (while leaving the FORWARD chain as it is now)? Seems to me it would be simple enough, and won't cause any security risks…

Route: that default route is only created for native/dhcp6/6in4 types, so it should not be a problem - the auto-configuration probably should not be used with any of these connection types anyway (except maybe dhcp6?). Regardless, you're right about the default route only needed in some cases - possibly only for 6in4 tunnel, and for ppp WAN connections?

Hello Westacular and teddy_b,

First of all, I just want you guys to know I'm appreciating this so much :).

I just got a rebuilt build for the WRT54GL and I did notice the new "Listen for WA on:" options, however I left those unchecked.

Now, I didn't get it to work. however I'll outline everything I did.

ISP: 2607:f2c0:f00e:ac00::/56

Router 1 (Main)
IPv6: Native ISP - 2607:f2c0:f00e:ac00:: - Prefix /64
MAC (WAN): 00:23:69:FB:05:3D
IPv6 Link-local: fe80::223:69ff:fefb:53d
Init Script: ip -6 route add 2607:f2c0:f00e:ac01::/64 via fe80::21d:7eff:fecc:9940 dev br0

—-

Router 2:
IPv6: Native ISP - 2607:f2c0:f00e:ac01:: - Prefix /64
MAC (WAN): 00:1D:7E:CC:99:40
IPv6 Link-local: fe80::21d:7eff:fecc:9940
WAN Up:
ip -6 route del default dev eth1
ip -6 route add 2607:f2c0:f00e:ac00::/64 dev eth1
ip -6 route add default via fe80::223:69ff:fefb:053d dev eth1
Firewall:
ip6tables -A INPUT -p icmpv6 -i eth1 -j ACCEPT

—-

However, once again IPv4 works fine, but IPv6 doesn't.

C:\Users\SonicSam>ping ipv6.google.com

Pinging ipv6.l.google.com [2001:4860:b007::93] with 32 bytes of data:
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.
Destination host unreachable.

—-

I hope I'm not doing anything wrong, I tried following your initial post followed by your amendments to the best I could.

Thanks,
Sam

I've been trying to the above with a similar setup to OP, I've never worked with Client Mode before, only Client Bridge Ethernet, so this was all new to me, but the information doesn't seem to help.

My instructions probably have a few mistakes or omissions… but there's been a number of fixes/changes made recently that make most of my instructions unnecessary. After a couple more fixes, I'll be able to post some much simpler directions for how to set up IPv6 subnets when using Client Mode in newer builds.

In other news: the missing piece needed to make Wireless Ethernet Bridge work with IPv6 is Neighbour Discovery Proxy. There's an RFC about it. Kernel 2.6 actually supports doing that, but the support is pretty limited, with little documentation, and possible bugs in the version used by Tomato. I was unable to make it work in my own little tests, and I'm not sure if that's because of mistakes on my part, bugs with the proxying itself, or interference/incompatible with Broadcom's Wireless Ethernet Bridge driver.

Even if I did make it work, it's not really ready for primetime; you must manually configure it for each individual address to be proxied.

For those curious, the feature is controlled by

echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
ip -6 neigh add proxy [IPV6 address to be proxied] dev [interface]

Hello Westacular,

Since you're mentioning IPv6 Client Mode will be less of a hassle in a future build, I won't struggle to get this working at the moment, thanks for all of what you're doing :)!

I have switched back to Wireless Ethernet Bridge Mode until such a build is ready, I can live without IPv6 for the moment, heh.

Hopefully you can find out if the Client Bridge Ethernet issue is something that can be fixed, best of luck!

Thanks,
Sam