TomatoUSB

I'm running the latest Toastman (v1.28.7495 MIPSR2-Toastman-VLAN-RT-BETA K26 USB VPN).
When I try to set the LAN to a /21 address (i.e. 192.168.0.0 with netmask 255.255.248.0), I get the message "Netmask must have at least 22 bits set".

This seems like an arbitrary restriction - what am I missing?

Got the same problem on Netgear-3500Lv2-K26USB-1.28.RT-N—088V-BT-VPN

This is a major bug - it makes the router useless on a class A or B LAN.

The restriction would be corect on a class C net, but it that doesnt seem to matter. Even then - if someone have the need to fake a subnetmask the router-os shouldnt interfear.

it`s not a bug but limitation.

http://repo.or.cz/w/tomato.git/commit/458b34f0fe9ece2bb252a21e36d92a7d1e28a5f2

do you need more than 1022 hosts in subnet?!?!? sorry

Why have any such arbitrary restriction - 10.0.0.0/8 is a valid RFC 1918 Private IPv4 address space

There is no valid reason to restrict the netmask. This check was not in the last official release by TeddyBear (v54), so somebody added it afterwards. Why? Was this an attempt to fix a bug? Or just an arbitrary changes for no particular reason?
Based on the reply quoted below, I'd guess the latter.

do you need more than 1022 hosts in subnet?!?!?

This is the problem with people with limited experience (not that there is anything wrong with that) making decisions based on incomplete understanding of the issues.

phoibos had it right: "if someone have the need to fake a subnetmask the router-os shouldnt interfere."

This is a major bug - it makes the router useless on a class A or B LAN.

No, this is not a bug. And no, it does not make the router any less useful on any kind/size/class of LAN/network. This is actually part of a new feature and has its origins on branch Teaman-IPTraffic. As it turns out, this particular validation/rule has been implemented only at the web UI level so it could still be manually overridden in situations that might require using a larger subnet/mask:

nvram set lan_netmask='255.255.0.0'
nvram commit
service net restart

There is no valid reason to restrict the netmask.

Agreed: such restriction, by itself, doesn't make much sense in most cases.

This check was not in the last official release by TeddyBear (v54), so somebody added it afterwards. Why?

IP Traffic data is based on stats/counters provided by an iptables match/module called 'ipt-account', which keeps track of several/detailed counters and makes those available via a file under /proc/net/ipt_account (one line per IP address within a specified range). While implementing this feature, I realized there were quite a few hard-coded references and/or assumptions that LAN would be always a class C network (24 bits). There's the possibility I may have misinterpreted something in there, but then I realized it was probably best try to follow whatever seemingly existing behavior already on/inside the web UI and originally this 'check' used to be 24 bits, then later reduced to 16 bits, back in October (but I'm not exactly sure how/when exactly it got changed to 22 bits on K26 trees ATM). So, why this kind of limit has been introduced?

Basically, because allowing setting up a class A network on a IP Traffic-enabled build… may have a few implications:

* when IP Traffic data/stats gathering functions are called (either via web UI or read by cstats) the router will look for any files it can find under /proc/net/ipt_account/*
* there should be one file for each configured LAN bridge (with its own range of IP addresses)
* if we have a class A network, then this means reading/parsing 16M lines (we're talking about 20+ counters for each and every line/IP)

Also, it was originally thought/planned/designed so it should be able of running even on a WRT54GL (and other similar/older routers, on K24) and considering IP Traffic was implemented following the same model as the Bandwidth monitoring related/subsystem, the 'real-time' parts of both were always functional/enabled - mostly, this was about trying to achieve consistent/similar behavior across vaguely/seemingly related features.

With those things considered, the idea of trying to help/prevent some possible/unfortunate accident/misconfiguration was sounding quite appealing back at those days… So I guess this helps a bit understanding why this web UI rule/validation has been there.

Was this an attempt to fix a bug?
Or just an arbitrary changes for no particular reason?

Not at all - its main goal has mostly been about trying to prevent problems from happening in the first place ;)

It's just that… this has been merged quite a few months ago into different mods (Teaman, Toastman, Shibby, possibly others), but I don't think it was ever brought up as some sort of 'major show-stopper' kind of problem - that is, until now.

Still - IP Traffic code has been updated recently and can now be optionally disabled at runtime. So perhaps this whole approach of just "not allowing" such large networks needs revision (i.e. allow such networks to be configured, provided IP Traffic is disabled, etc..). I guess I'll have to think of something…

http://www.linksysinfo.org/index.php?threads/cstats-keeps-crashing.36206/#post-176249
http://code.google.com/p/tomato-sdhc-vlan/wiki/TeamanIPTraffic
http://repo.or.cz/w/tomato.git/shortlog/refs/heads/Teaman-IPTraffic
http://code.google.com/p/ipt-account/
http://code.google.com/p/tomato-sdhc-vlan/

The categorization of Classes A, B, and C became obsolete in the early days of the internet, due the the inherent restrictions of the class sizes. IIRC, that's why the concept of "netmask" came into being. Nowadays the classes are a historical oddity and everything is done with netmasks.
"Classful network design served its purpose in the startup stage of the Internet, but it lacked scalability in the face of the rapid expansion of the network in the 1990s. The class system of the address space was replaced with [netmask] in 1993."

It is not strictly required for the netmask to have contiguous 1 bits. It is legit (although rare) for a netmask to have 0's in the string of 1's.

Also, 10.x.x.x/8 is a perfectly valid private network, just as valid as 172.16.x.x/12 and 192.168.x.x/16. This check on the number of bits in the netmask is wrong and should not be done.
Another implication of this is that you can legitimately subdivided these and have private networks like 10.192.x.x/10 or 192.168.128.x/17. I see this in large corporate networks all the time.They'll take the class A address of 10 and split it into many networks by merely increasing the number of bits in the netmask. My employer, for example, had about 80,000 computers on their internal network, spread across 15 US states and 10 countries on 4 continents.

• when IP Traffic data/stats gathering functions are called (either via web UI or read by cstats) the router will look for any files it can find under /proc/net/ipt_account/* * there should be one file for each configured LAN bridge (with its own range of IP addresses) * if we have a class A network, then this means reading/parsing 16M lines (we're talking about 20+ counters for each and every line/IP)

But there is no longer such a thing as a Class A/B/C network — there is only netmask.

One of the challeges of programming systems is to avoid making choices that make restirctions for the user in order to make the programmer's implementation task easier. I believe this is one of those cases.

I haven't looked at the traffic stats code you mentioned, but it *must* be implemented in such a way that doesn't restrict the netmask, and doesn't assume that the "class" has any meaning. Even without looking at that code, a few possibilities come to mind. One is a dynamic hashed array list similar to the way the kernel handles disk block numbers and NVRAM key/value parameter pairs. Another is a self-organizing list of the N most recently used ip addrs (with N on the order of 1000 or so), perhaps also in combination with a hashed array list.

I have admit this whole things sounds abit strange to me. I have been using 172.31.0.0/16 for years now and never had a problem. Now with IPv6, I can well think of uses where I might want to make the IPv4 just 0.0.0.0/0 to make sure only IPv6 is routed to the internet. This whole 22 bit restriction that must have been added in since the last time I rebuilt TomatoUSB should just be scrapped, as it sounds even worse than useless.

I've been using 10.0.0.0/16 on my network (multiple routers) using regular TomatoUSB, and just now flashed Shibby's build
This 22-bit restriction just does not make sense.
Isn't the whole point of using firmware like Tomato/DD-WRT/OpenWRT to increase possibilities and not be bound by arbitrary restrictions?

You can see a full list of all the variables using:
nvram show » /etc/nvram
and then opening the newly created nvram file in any text editor (such as the one built into winscp)

For anyone googling and getting this page, these are example commands for ip address, subnet mask, dhcp range, and dhcp enable:

nvram set lan_ipaddr=10.0.0.1
nvram set lan_netmask=255.255.0.0
nvram set dhcpd_start=10.0.0.100
nvram set dhcpd_end=10.0.255.254
nvram set dhcpd=1
nvram commit