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'
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…