Ok, so I've been working away on my own to add a bunch of IPv6 features to TomatoUSB. Definitely some of my work would be of general interest. I'm working off a local git repository, but I'm new to using git, and I could use some guidance regarding how to create and send patches in a useful format.
IPv6 features I've added, so far:
- Added an IPv6 section to Basic Settings page, with options to enable IPv6, and choose between native ipv6 from your ISP or using a 6in4 (SIT) tunnel (eg, from Hurricane Electric), along with all the corresponding configuration settings.
- Added rc/service entries for ipv6, radvd, and tunnel configuration, corresponding to the above; all addresses and routes are assigned as appropriate and radvd is configured and started, so a user doesn't need any custom scripting to get ipv6 routing up and running.
- QOS classification rules are also output to ip6tables where applicable (times when they aren't applicable: when a src/dst IP is specified, or when an ipp2p or l7 rule is used).
- To allow the above: added "set-return" action to the ipv6 side of netfilter, added an ipv6-ized versions of connbytes iptables module.
- Add ipv6 support to httpd. You can access the web interface over an ipv6-only connection!
- For connection counts, and the QOS Detailed table, I've converted httpd to read from nf_conntrack instead of ip_conntrack, which lists both ipv4 and ipv6 connections with otherwise identical formatting. So, now the listings show both protocol families. (Also added support for doing reverse-lookups on ipv6 addresses.)
- Switched QOS from using "mport" to "multiport" module. mport doesn't support ipv6, multiport does, and (at least under K26) multiport seems otherwise identical to mport in terms of features and parameter names.
- Played around with the "stickiness" aspect of QOS rules. Previously, if a byte range was specified all subsequent rules would be un-sticky, creating a lot of mostly unnecessary processing for the router if you happened to have a connbytes rule near the top of your chain. (A connection classified by any un-sticky rule has to re-traverse the chain and be reclassified for every outgoing packet.) I devised another way of checking to see if a connection has exceeded its classified limit that doesn't require this. I've tested it pretty thoroughly, and it works exactly as intended. I suspect, based on my own experience, that this change might *really* help reduce some of toastyman's connection storm/resetting issues.
- Added a "hosts_custom" field to the advanced dns/dhcp settings page. This lets you add custom additional dns entries — e.g., for ipv6 addresses! Anything you enter in the box gets added onto the end hosts.dnsmasq, the same way that anything in dnsmasq_custom gets added to the end of dnsmasq.conf.
- Bug fix: matrixssl must be built even if HTTPS is turned off.
- Added "bytes in" and "bytes out" columns to the QOS Detailed table, showing how much data the tracked connection has actually transferred. (Since the data is now in the conntrack table anyway, why not use it?) It's not as helpful in practice as I'd hoped it would be, but that might be because of formatting — I've placed them next to the respective ports columns and it gets a bit confusing. Might make more sense to tack them onto the end, after the classification label, instead.
Still to do:
- Detecting whether a connection is coming into the LAN or leaving it and flipping it before displaying it in the QOS Detailed table (to maintain LAN -> WAN organization) isn't working quite right for ipv6 connections
- Tomato interface / rc can't handle IPv6 addresses for DNS servers.
- Firewall! Right now I'm using a custom script. There's enough differences between ipv4 and ipv6 that it doesn't make sense to reuse firewall rules the way it does for QOS rules. The existing firewall interface presumes (and heavily depends on) the use of a NAT, so a lot of what it does is either impossible or unnecessary in IPv6land.
- Testing non-IPv6 and K24 builds to make sure I haven't accidentally broken anything there.
- Is there a reason the iptables package being used is still version 1.3.8? With 1.4.x they switched to the common/shared xt_* form (like what K26 uses in the netfilter backend) for userspace modules, instead of requiring separate ones for ipv4 and ipv6.
- When coding, I used a lot of #ifdef TCONFIG_IPV6, and assumed that IPv6 implied K26. A subsequent examination of the core Makefile shows this isn't necessarily the case, so there will be problems if someone tries to manually compile a K24 + ipv6 config (specifically: the nf_conntrack stuff). I'm of the opinion that if you want IPv6 support, you really should be running K26 as well, but the Makefile isn't currently enforcing that.
- Are there "bytes=" fields in /proc/net/ip_conntrack under K24? I assumed yes, but I haven't confirmed that.