Conserving RAM on a Fon+

[westbywest]

I recently installed Gargoyle beta4 on a Fon+ 2201 as I am looking for a a decent QoS solution in a Fon-sized package. Since the Fon/Fon+ routers only have 13MB of RAM, the effectiveness of QoS depends very heavily on the available memory (I've noticed). So, here are steps I've taken to squeeze down Gargoyle's memory footprint and eek out more usefulness in the QoS...

Based on http://gargoyle-router.com/phpbb/viewtopic.php?f=5&t=58, add these lines to /etc/firewall.user to limite the # of new P2P connections per minute, where [start]:[end] is the port range of your P2P application.

Code: Select all

iptables -N limitP2P
iptables -I FORWARD -j limitP2P
iptables -I INPUT -j limitP2P
iptables -A limitP2P -p tcp --dport [start]:[end] -m state --state NEW -m limit --limit 10/minute --limit-burst 10 -j RETURN
iptables -A limitP2P -p tcp --dport [start]:[end] -m state --state NEW -j DROP

Irrelevant to conserving RAM, but relevant to making the Fon+ more useful, add this line to /etc/firewall.user too so that the wired LAN port may connect with clients on the WLAN (from http://gargoyle-router.com/phpbb/viewto ... p=180#p188).

Code: Select all

iptables -I zone_lan_forward -i br-lan -o br-lan -j ACCEPT

To apply these new firewall rules, append these lines to /etc/config/firewall

Code: Select all

config 'include'                  
   option 'path' '/etc/firewall.user'

Now append/modify these lines in /etc/sysctl.conf:

Code: Select all

net.ipv4.netfilter.ip_conntrack_max=1024
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3600
net.ipv4.netfilter.ip_conntrack_udp_timeout=60
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=180

You will note this limits the # of simultaneous connections to 1024, which is certainly on the low end for heavy P2P traffic, but in my experience the only option when you want both P2P 24/7 and some sort of passable QoS. Having your cake and eating is difficult with only 13MB of RAM.

Finally, I disabled non-critical services like Dynamic DNS (not needed), the bandwidth monitor, and even the Web interface at the SSH console.

Code: Select all

/etc/init.d/ddns_gargoyle disable
/etc/init.d/ddns_gargoyle stop
/etc/init.d/httpd_gargoyle disable
/etc/init.d/httpd_gargoyle stop
/etc/init.d/bwmon_gargoyle stop  
/etc/init.d/bwmon_gargoyle disable

It's pretty trivial to remotely restart/stop the web admin console as needed:

Code: Select all

ssh root@[router IP] /etc/init.d/httpd_gargoyle start
ssh root@[router IP] /etc/init.d/httpd_gargoyle stop

... where [router IP] is the internal IP of the Gargoyle router, e.g. 192.168.1.1. Public key authentication (I believe dropbear supports this, right?) would help streamline the process for starting/restarting the web interface.

And that's it. I can now get almost near-realtime response on services requiring minimum latency (e.g. typing at a remote SSH console), along with P2P traffic backgrounded so as not to be too disruptive. Or to put it plainly, the QoS now works noticeably better than it did using Gargoyle firmware out of the box.

Could folks share their own RAM-conserving tips?

[Eric]

I think I may have found a way to (at least partially) help address the RAM problem (which is implemented in the latest bleeding edge firmware -- upgrade is strongly recommended).

The way the layer7 matching works is that you need to monitor the content of the connection, not just the first few bytes. This means all packets of connections are tested, and these matches are far more computationally demanding than other iptables matches. The new firmware looks only at the first few packets in a connection, so that it has a chance to classify it based on content, but after that doesn't do any more checking. This should free up (some) memory, but it is of course still going to be a tight fit.

Also, the Fon+ 2201 router has 16MB, not 13MB. The reason you're seeing 13MB in the status tab of Gargoyle, is that this excludes memory used by the kernel -- it's the user-space memory available. The memory reported by the system typically excludes kernel memory. On larger linux systems this is usually small enough it can be ignored, but it becomes more apparent when you only have 16MB to begin with

[westbywest]

That's good news.

Is there perhaps an upgrade path from Gargoyle beta4 to the bleeding edge firmware that doesn't require re-flashing, e.g. just using opkg? I've made a number of manual tweaks to the config beyond what the web interface can control (as outlined in the original post), that I would otherwise need to capture and then re-apply to the re-flashed router.

Or, would it at least be safe to take the config tarball created by the web interface and apply it to a reflashed router? I would still have to apply the manual tweaks.

Also, on a related note, tho I think this was asked somewhere in the forums, but I can't find it now. Does Gargoyle support 3rd party l7-filters, e.g. Skype filters http://protocolinfo.org/wiki/Skype

[FRiC]

Maybe it's time to call it "beta 5"? All the 4.x is starting to get confusing especially when they all say beta 4 in the web interface.

[Eric]

If you do a backup there will be a few incompatibilities. In particular you will need to change an include section in /etc/config/firewall so that instead of pointing to /etc/parse_remote_accept.firewall it points to /usr/lib/gargoyle_firewall_util/gargoyle_additions.firewall That was the problem here. There may be one or two other small gotchas, but that's the big one.

As for custom l7 patterns.... it's possible to integrate new ones but it's not trivial. "Supported", is probably too strong a word. At some point I'd like to make their inclusion automatic, or at least straightforward, but for now it's not. The thread you were referring to with directions on how to integrate custom patterns is here.

FRiC: I've definitely considered it. I was hoping to go straight to the 1.0 release or RC1 with the next release, so I've been taking extra time to try and get as much right as possible. But, unlike previous releases which mostly introduced new functionality (I hibernated for most of last October and November building the restriction section), some serious bugs have been identified and fixed, so people should really be using the latest firmware, and another Beta release might encourage that.

I'd love to hear other people's thoughts on this issue -- so if you have an opinion please post it.