OK. now i've tried OpenWRT (8.09.2 / latest stable) with a 2.6.26.8 kernel:
- DSL works just as well, though there's a minor bug in 8.09.2, paricularly w/ PPPoA, that wan interface doesn't auto-start on init, but fixable via a simple patch (affects three files), or manually started via `ifup wan`.
The fix (r17527) described in #2781 is most likely committed to latest snapshot, but I doubt it will be backported to 8.09.2 (r18961) as this was allegedly the last update to the 8.09.x release.
- Switch not (yet) natively supported, of course, so cannot setup VLANs through switch page in LuCI.
- Wireless not picked up by default, though seems to be detected by acx driver in init (will investigate this more later):
root@OpenWrt:~# dmesg | grep -i acx
acx: this driver is still EXPERIMENTAL
acx: reading README file and/or Craig's HOWTO is recommended, visit
http://acx100.sf.net in case of further questions/discussion
acx: compiled to use 32bit I/O access. I/O timing issues might occur, such as non-working firmware upload. Report them
acx: running on a little-endian CPU
acx: PCI/VLYNQ module v0.3.37 initialized, waiting for cards to probe...
acx: found TI TNETW1350-based wireless network card at vlynq0, irq:80, phymem:0x4000000, mem:0xa4000000
acx: eCPU is already running. reset_dev() FAILED
Default openwrt-ar7-squashfs.bin leaves about 1.4MB of space for jffs partition, of which about 200kb are used (leaving 1.2MB Free allowing to install packages with opkg)
Installed qos-scripts package (which pulls all its dependancies), luci-app-qos (frontend for qos), and a few other packages like luci-app-firewall, luci-app-statistics (pulls rrdtool1 and collectd w/ a few collectd-mod-* packages), luci-app-initmgr, and luci-app-p2pblock (just to see what it does)
Oh, not to forget, 5.6M free on /tmp (tmpfs) and minimum 2.5MB FREE as reported by `free` command (and /proc/mem +988kb inactive) after several hours of uptime with all the above installed / running / actively being used.
Code: Select all
root@OpenWrt:~# uname -a
Linux OpenWrt 2.6.26.8 #1 Wed Dec 2 15:14:35 UTC 2009 mips unknown
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
rootfs 1.6M 1.6M 0 100% /
/dev/root 1.6M 1.6M 0 100% /rom
tmpfs 6.2M 596.0k 5.6M 9% /tmp
tmpfs 512.0k 0 512.0k 0% /dev
/dev/mtdblock4 1.4M 1.2M 220.0k 85% /jffs
mini_fo:/jffs 1.6M 1.6M 0 100% /
root@OpenWrt:~# free
total used free shared buffers
Mem: 12684 10168 2516 0 160
Swap: 0 0 0
Total: 12684 10168 2516
P2P block, which I later disabled cuz I don't think it will really help if a torrent client started using encryption (or port 80) to bypass blocks:
http://i41.tinypic.com/1586wex.jpg
Default qos config in /etc/config/qos looks pretty good (elegantly simplified in LuCI interface in Network -> QoS):
http://i40.tinypic.com/2w4wwg5.jpg
QoS works WONDERS... My throughput actually increased; prior to using QoS on OpenWRT, I could only get max of 90-94kb/sec download while having severe lags + quite high latencies, now get 106-108kb/sec stable downloads, with negligible increase in latency. De-prioritizing p2p/bittorrent traffic to "bulk" class is also comforting to know I have. Bottom line: Standard Linux QoS (with HFSC+SFQ+IMQ) / Fair queuing is working very very well, and can be setup fairly easily from LuCI as you could see above in the screenshot.
However, I'm still clueless as to how to set (hard) rate limits for certain clients. As the qos-scripts package uses tc along with HFSC+SFQ, I'm unsure how to do this as I would with HTB. `qos-stat` command-line output is quite complex, and re-learning everything will mean a steep curve.
Another thing is, OpenWRT doesnt have a ipt-account package like RouterTech does, and I could not find any decent/recent info on how to accomplish a similar task, without too much pain. To my disappointment, luci-app-statistics isn't much useful (for all the dependencies and the space usage tradeoff):
http://i40.tinypic.com/4vhbph.jpg
http://i39.tinypic.com/fc2m4i.jpg
So I have to say, RouterTech firmware is definitely much more attractive in that regard (and working wifi)
Gargoyle in the other hand is much more promising in terms of features/control over bandwidth/QoS, as it offers many options that match some of the very useful features of routertech firmware (like ip accounting usage stats in quota page, and web usage similar to darkstat, etc..)
But... Installing gargoyle is not as straightforward for us people who are on AR7 hardware. While the available binaries in gargoyle for bcm-2.4 should still be mipsel-based - and therefore compatible, I think there is at least one caveat (iirc, something about a virtual kernel package 2.4.35.4-brcm-2.4-1). Also, even though gargoyle's docs on installing it as packages with opkg (on top of currently installed OpenWRT) should take about ~800kb for broadcom-based hardware, even with skipping wireless/ddns/upnp packages, I quickly ran out of the 1.2MB available space and was unable to install the final package (gargoyle) and its dependencies. The reason for that is qos-scripts alone pulls so many packages and takes up its fair share for space on the jffs partiton. I actually had to do `mtd erase mtd4`, reboot, and reconfig my router to get back all the space lost , due to jffs crashing when it reaches very near to 100% usage (opkg remove doesnt actually remove files in this case, it actually end up using more space to say the files are no longer available - since jffs is really only an overlay to the read-only squashfs root)
So I'm probably going to have to look into building OpenWRT (probably latest trunk) + Gargoyle from scratch, for now.. I'm sure Gargoyle project could use 1 more (even semi-) supported architecture.
Hope that satisfies your curiosity, mstombs (it sure did mine)