Yesterday I flashed my Netgear WNR3500L from TomatoUSB-Ext Build 52 to TomatoUSB-VPN Build 54. I made two 30-30-30 resets and reconfigured manually my router. My Hurricane Electric IPv6 tunnel worked fine before (with Build 52) and now it will not with Build 54. I made a simple copy/paste of my previous "Wan Up" script and all works fine except if I add a route… Here is the code:

If the "ip route" line is commented, no reboot occurs but obviously, I can't come out and "play" on the IPv6 Internet :( I suspect the ip6t_ROUTE module to be somewhat wrecked or invalid but I have no evident clue to this. Any other idea ?

I forgot to say that the router does not reboot immediatly after adding a route unless there is some traffic (trying to go out of the tunnel) initiated by other machines than the router itself. So I can do a "ping6" from the router itself (hence no "forward") without harm but if I do a "ping6" to anywhere on the Internet form another machine, a reboot occurs instantly.

Further investigations show me that since the ip6t_ROUTE was not necessary to operate the tunnel previously, so it is with the new build. With or without this module, adding a route through the 6in4 tunnel and then pinging a distant host is enough to automatically reboot the router. If no IPv6 route is present, pinging a distant host - hence unreachable - has no effect on the router operations. Weird.

I just tested this, and I can confirm the regression: traffic in the SIT tunnel causes an instant crash/reboot.

However, the problem isn't with ipv6 routing; I have native IPv6 over PPPoE and it's working fine. If I set up a tunnel (named "sit1" in my case) in addition to that, but *without* adding any routes to it, then

ping6 fe80::%sit1

causes a crash. But — interestingly — not if I forget to update the tunnel provider with my current IP address. So, sending traffic isn't the problem, it's something that requires receiving traffic too.

As I said before, I only discarded [u]one[/u] possible problem ;) I had too many crashes to make a thorough diagnostic before I got fed up and reverted to my previous config (i.e. tunnel and radvd set up back in a few minutes on an always-on server on my lan).

Heh, fair enough. You're right that this was definitely working in Build 52, though… I was just looking at the revision history, and TomatoUSB's tunnel-related kernel code hasn't been modified in several months.

It must be that there's some conflict/bug with a patch to other core networking code from the past few weeks. There's only been a couple IPv6-specific changes, and they were minor and probably couldn't have caused this … I think the most likely culprit is the big Broadcom SDK / Wireless driver update?

I think the most likely culprit is the big Broadcom SDK / Wireless driver update?

I doubt so - there are very few networking-related kernel changes in this update either (other than the driver itself), and most of them should have no effect without loading the new ctf module (which Tomato does not do). But anything's possible - aand this will be relatively easy to verify…

@Westacular - you've been compiling Tomato for yourself with your extra changes on top… Have you been using build 52 sources as the base, or one of the later git snapshots? If so - what was the last state of the code that worked for you without the error?

I didn't notice any significant change in wifi or ethernet networking since build 52. Wifi N works fine @ ~250-300Mbits with WPA2/AES within a few meters distance and gigabit ports still deliver an average ~700Mbit throughput :)

@Westacular - you've been compiling Tomato for yourself with your extra changes on top… Have you been using build 52 sources as the base, or one of the later git snapshots? If so - what was the last state of the code that worked for you without the error?

I was initially using build 52. I rebased my branch on tomato-RT (its 2010-11-12 state), and since then I've periodically merged changes on tomato-RT onto my branch.

It definitely worked in build 52, and I'm pretty sure it worked after 2010-11-12. I have an build image from just after a merge on 2010-11-25… When I get a chance, I'll check in that one, which should narrow things down.

Yeah, it was broken in that 2010-11-25 build but working prior to the merge I did just before that.

In other words: it was broken by something that was committed in tomato-RT before 215d3ebd (2010-11-23) but after a4ef5f2d (2010-11-12). The Broadcom SDK stuff looks like the only major change to any kernel net code in that period.