New to Gargoyle, just built & flashed on AR7

[geekgirl]

I had been looking briefly into gargoyle sources the other day to familiarize myself with it, and today I built it for AR7 and flashed it on a D-Link DSL-2640T (ver. B1).

Honestly, seeing files being written all over the place, I did not have a good feeling about this.

/etc/original_backup (iirc, written only at inital setup?)
/usr/data/bwmon (bunch of files in there, written once a day?)
/usr/data/quotas (seems to be one file per quota rule, written once a day?)

There's also a reference to "/usr/data/webmon.txt" in "/etc/config/webmon_gargoyle", which I haven't looked into yet..

I know this was discussed prior in the following thread:
Quotas and shutdown

But I still feel a bit worried..

The best information I could find about this topic was at:
http://en.wikipedia.org/wiki/Flash_memory#Memory_wear

Most commercially available flash products are guaranteed to withstand around 100,000 write-erase-cycles, before the wear begins to deteriorate the integrity of the storage.

But the referenced source is titled: "NAND Flash Solid State Storage for the Enterprise, An In-depth Look at Reliability"

I'm not sure if flash memory in home-routers would really match those aimed at the Enterprise. Something tells me, unlikely..

The guaranteed cycle count may apply only to block zero (as is the case with TSOP NAND parts), or to all blocks (as in NOR).

And are the (limited) flash chips in routers as sturdy/tough as those sold in "USB sticks"?

Moreover, from:
http://en.wikipedia.org/wiki/Wear_levelling

EEPROM and flash memory media have individually erasable segments, each of which can be put through a limited number of erase cycles before becoming unreliable. This is usually around 1000 cycles[citation needed] but many flash devices have one block with a specially extended life of 100,000+ cycles that can be used by wear levelling controllers.

moreover:

In flash memory, one block is usually longer lifed than the others so that the wear levelling controller can store operational data with less chance of its corruption.

1000 (read, one thousand), does not sound like a lot at all.. If the 100,000+ cycles is limited to only one block, then it would explain why many router manufacturers limit the config area to only a 64 or 128kb block of the flash chip.

Think of how many times you update/flash different firmware version to the entire chip, how many times you change/commit changes, how often you install/update packages to (the root overlay) jffs partition, etc.. Saving to multiple files once a day is only sure to speed up wearing out the flash chip quite rapidly. I don't think flash memory in home/small-office routers were designed to withstand such.

I looked up the datasheet for the flash chip in my router, a Samsung K8D3216UBC-PI07
It says:

Endurance : 100,000 Program/Erase Cycles Minimum

And that is the only reference to "erase cycles" or "endurance". It doesn't explicitly state whether that is guaranteed for the entire writeable area, or for a specific block..
As I'm still learning and experimenting with different firmwares (some custom-built), so I could appreciate a little more reassurance.

Anyhow, it would be really nice if there was an option in config to allow the end-user to choose whether they want the statistical data saved to tmpfs or to jffs.
Moreover, an option to run the monitor(s)/daemon(s) in sensor-mode, sending data to a remote SQL server (like BandwidthD) would also be fantastic.

Now, on to the technicalities:

1. Checked out gargoyle's (and kamikaze) sources from svn, as described in there documentation here.

2. Ran `make custom`, which in turn took me to the standard OpenWRT `make menuconfig` step.
Briefly, the main things I chose:

Code: Select all

Target System (TI AR7 [2.6])
Target Profile (Texas Instruments WiFi); adds kmod-acx-mac80211
Base system:
  br2684ctl (for pppoe, just in case i ever need it)
  busybox
      Configuration
         Networking Utilities
            [ ] udhcp Client (udhcpc) <- removed it, since the WAN is PPP
            [ ] httpd <- removed it, since gargoyle has its own  ;) 
Network
   hostapd-mini
   ppp
       ppp-mod-pppoa                          (for PPPoA)
Kernel modules
   Network Devices
       kmod-sangam-atm-annex-a    (for DSL over POTS, I'm not in Germany, so dont need annex-b - DSL over ISDN)

3. after the kernel/modules/packages were all built, comes "CUSTOM GARGOYLE CONFIGURATION" called from "custom-src/include/image.mk", and the building process stops with an error, because it is looking for a file that is not there...
particularly, this line:

Code: Select all

IPKG_INSTROOT=$(TARGET_DIR) sh $(TARGET_DIR)/etc/rc.common $(TARGET_DIR)/etc/init.d/httpd disable

Well, obviously I removed "httpd" from busybox in menuconfig, doh
Luckily I was able to figure it all out quickly, commented out that line in "custom-src/include/image.mk" as well as in "custom-sdk/include/image.mk" just in case, resumed where it stopped, by evaluating the variables passed to make from full-build-809.sh to mimic the exact procedure, and a copy of the script slightly modified to pickup exactly where it left, and all went well.
N.B.: just in case these files get rewritten on next build, I modified:
"targets-8.09/custom/patches/06-image_mk.patch"
and commented out the culprit, so I don't run into this again
Perhaps we should have a condition there, to check if the file exists, before attempting to invoke it?
I mean, it's an httpd, not adding it to the image (since Gargoyle has its own ssl-capable httpd) means more space for other adding things, as well as less RAM (tmpfs) usage, no?

Caveats:

1. acx support is still broken for the wifi chip in this router (a TNETW1350A), so acx driver doesn't pick it up, and attempting to `rmmod acx` causes a segfault... Would be interesting to try openwrt trunk rather than 8.09.2 (stable) to see if this has changed any.
So for now, no chances for me to add wireless support for wireless on this platform, since it is broken in kamikaze (and probably will stay so for a while due to slow pace of development over at acx100 project). There's support for the wireless chip in RouterTech firmware, but that's based on Acorp's proprietary TI firmware which was GPL'ed at least four years back, so driver support is limited to 2.4.17 MontaVista Linux kernel, so don't know if it would be easy to port it even to a standard 2.4.x kernel in OpenWRT and lock it at that till we get decent wireless support in 2.6.x, as the case with brcm-2.4

2. I understand that gargoyle has not yet supported any DSL-equipped routers, but I would like to add at least some preliminary support so I can test other stuff, like QoS etc.

I'm a bit tired now, and have to get back to real-life later today for work, etc.. So if someone could save me the effort of having to find out for myself, and answer some basic questions for me (or provide any pointers), I'd be extremely grateful

I. Is the QoS/quota functionality in the interface dependant on WAN config detection - which is also in the interface?
I added a simple rule in "Quotas" (600MB combined/day limit for subnet 192.168.96/29) to see how it will be reflected on the command-line (checking by using `tc [qdisc|class|filter] show dev [eth0|ppp0|br-lan]`, etc.. but it doesn't seem like it actually did anything. Only result I got was for eth0 qdisc:

Code: Select all

root@OpenWrt:~# tc qdisc show dev eth0
qdisc pfifo_fast 0: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

and the quotas file:

Code: Select all

root@OpenWrt:~# cat /usr/data/quotas/quota_192.168.1.96_29_combined 
789            
0.0.0.0        	0

Hmm? Need to look into the scripts to understand how it all works.. Brief pointers would be very much appreciated

II. I configured the ppp0 (wan) interface manually in /etc/config/network, but in the interface, Connection->Basic page, "Internet / WAN" -> "Connect Via:" is set to "disabled" , and there are only "DHCP (wireless)" and "Static (wireless") options, and that's understandable. "Ethernet Port Connects to:" is set to "LAN", so it seems to be picking up that part of the network config okay.
Any ideas/pointers on where to start? Preferable way(s) to implement this to possibly be able to propose a preliminary platform-independant support patch? Anyone already started working on this?

That's it for now... Cheers

[Eric]

I think 100,000 flash/erase cycles is fairly accurate. I've heard it cited numerous times. Also, I've been running Gargoyle since it was in development, and the router it's running on hasn't died, despite daily rewrites, not to mention at least 100 complete re-flashes in that time. The recent versions actually write 6x per day, and it still hasn't died. The value of having more up-to-date bandwidth/quota information if the power dies is worth the potential danger of more frequent writes. Also those files are fairly small in most cases -- if a couple sectors go bad, I'm pretty sure the file system can deal with it.

I. The quotas are set on the wan interface. I believe you can still set them up even if no wan interface is detected, or exists. However, if uci wan interface is defined (even if the GUI can't detect it) they will get configured properly.

However, the quotas aren't implemented as a qdisc, so tc qdisc show won't tell you anything. The quota implementation depends on the custom bandwidth iptables kernel module. Make sure that the bandwidth, weburl and timerange iptables modules are selected in menuconfig. If they are, and you have a WAN interface, run iptables -t mangle -L and you will see the quota chains, if you have any defined quotas.

II. The file you need to modify to get this working is in package/gargoyle/files/www/js/basic.js, which corresponds to /www/js/basic.js on the router. This is the javascript for the controls on the connection/basic page, where most of the logic for this is located. Just to warn you: it's very ugly. Any help you want to provide in cleaning it up/improving it would be much appreciated. Also, you may need to modify the corresponding haserl script (www/basic.sh) if you need to run additional commands on the back-end.

[geekgirl]

Eric, thank you very much for your detailed reply.

Obviously I was too tired at the time of writing to think straight. Of course, it makes sense tc qdisc has nothing to do with with Quotas. had too many thoughts going through my head, and was curious about how QoS & Quotas work in Gargoyle, and ended up making a nice spaghetti post..

Code: Select all

$ grep "^CONFIG_PACKAGE_iptables-mod" custom-src/.config-ar7
CONFIG_PACKAGE_iptables-mod-bandwidth=y
CONFIG_PACKAGE_iptables-mod-conntrack=y
CONFIG_PACKAGE_iptables-mod-conntrack-extra=y
CONFIG_PACKAGE_iptables-mod-filter=y
CONFIG_PACKAGE_iptables-mod-imq=y
CONFIG_PACKAGE_iptables-mod-ipopt=y
CONFIG_PACKAGE_iptables-mod-iprange=y
CONFIG_PACKAGE_iptables-mod-nat=y
CONFIG_PACKAGE_iptables-mod-nat-extra=y
CONFIG_PACKAGE_iptables-mod-timerange=y
CONFIG_PACKAGE_iptables-mod-weburl=y

N.B.:
iptables-mod-weburl & iptables-mod-timerange are auto-selected by gargoyle-firewall-util
iptables-mod-bandwidth is auto-selected by libiptbwctl, and libiptbwctl in turn is auto-selected by gargoyle-firewall-util
gargyole-firewall is also auto-selected by bwmon-gargoyle

So selecting gargoyle-firewall-util (or bwmon-gargoyle) subsequently forces selection of all the modules you mentioned. Of course, if I failed to select any of gargoyle's critical components, I deserve to get shot, not get help

Bad experience, Installing Gargoyle as a set of packages:

I forgot to mention that at first (few days earlier), I tried to install gargoyle as a set of packages (on jffs2) w/ opkg. That didn't really go well, despite skipping all the platform-dependant and optional packages, as well as the ddns / upnp stuff. I couldn't get far, even with initial 1.2MB of free space on /jffs , because I was mislead by the docs that the whole thing would take ~800kb. i.e. when I got to the last step of installing the "gargoyle" package, I was bummed out to realize that it needed more space than all the other packages I had just installed.

Perhaps the info in the last section of the following page is a little outdated?
http://www.gargoyle-router.com/wiki/dok ... f_packages

Before you begin installation on a broadcom router you should verify that you have ~800kb of free space available, or ~2.0Mb on an atheros router. That's how much space gargoyle, along with all of it's dependencies requires. Atheros requires so much more space because it requires libopenssl (which is HUGE) to enable WPA wireless encryption.

The package list on the repo reveals that package "gargoyle" alone is 890344 (~869kb) installed size.

Package: gargoyle
Version: 1.1.3-6
[...]
Installed-Size: 890344

I had to do a little hacking to unpack the ipk onto tmpfs, imitate postinst script along with creating a few symlinks/edits here and there to simulate a real install just to get a look at the actual interface. That was very dirty tbh. But it was worth all the effort, at least for some general ideas. That sure helped me familiarise myself with the core components of Gargoyle before going for the real build

Thanks again for all your help. I look forward to doing something useful for gargoyle, and contributing back soon

[Eric]

Yeah, Gargoyle has grown a bit over the past two years, so that information is a bit out of date. I really need to get around to using a javascript minimizer at compile time to shrink the size.