Gargoyle Forum

OK let me start off by saying, thank you for the time and hard work you have put in on this project. I really like the idea of a very slick looking, simple, yet functional webUI and ssh for the more in depth stuff. I have yet to see a GUI give the options of a CLI and not look cluttered when dealing with an app of any size.

Questions:
1. It is my understanding that Gargoyle unlike Luci&Xwrt will not work as a "feed", since it patches the kernel and maybe some other base files. If this is the case could I use the "feed" feature of openwrt and manually patch the files?

2. if ipkg/opkg can install Gargoyle onto a installed openwrt, could I simply grab the package(s) that apply/replace the patches you have made and build the rest of Gargoyle into my firmware?

3.Have the patches needed to run Gargoyle been submitted upstream, if so has there been any feedback?

4.Is Gargoyle simply a webUI for openwrt or are you headed towards a fork?

5.Understandably stability is the main focus at this point, but do you envision Gargoyle becoming as easily integrated into openwrt as xwrt&luci via a feeds download?

6.How does gargoyle-qos compare to the paid dd-wrt,luci,tomato (which I have heard is very good), and others? If yours is better, why?

Thank you and keep up the good work.

1) The only things that can't be installed on top of default OpenWrt, and require a kernel patch, are the module necessary for client bridging on atheros devices, and a very minor patch to the atheros ethernet driver. There are some other iptables kernel modules that are built, but these should work with a default kernel.

However.. those iptables modules are the biggest problem for building as a feed. The way I have it set up is to have a special patch script that can generate the necessary files/modifications (there's a TON of modifications necessary) to add a new iptables module. This means I don't have to re-generate a patch file every time I modify one of the modules -- all the necessary modifications just get computed at compile time. Since OpenWrt doesn't have my patch script (or anything similar), compiling these modules from a default OpenWrt build environment is problematic. These modules are absolutely essential for many of the best features of Gargoyle, in particular bandwidth quotas.

2. You can download and install packages I've made on top of a default openwrt installation with ipkg/opkg. Atheros wireless bridging won't work though. If you apply the patches in the target directory before building openwrt that will work too. The iptables modules are hard to build, but not hard to install.

3. No. Let me tell you a story:

The first back-end package I built for Gargoyle was dynamic dns, in early 2008. The lates dynamic dns package used by Gargoyle is in C so that it has support for updates via https (more secure), but that initial version was just shell scripts. I initially hoped to get a lot of the Gargoyle packages into OpenWrt, so I submitted the package, and waited. And waited. And waited. And waited. For two months, not a peep -- not even a "thanks, please wait while we look over your submission." Then, finally, two months later, it was unceremoniously added to the repository.

That two month wait really annoyed me... but what happened next made the problem worse. Someone found a bug in the code and submitted a patch. All well and good... except the patch was ignored. And ignored. And ignored. After the first person submitted a suggested fix to the TRAC, I thought maybe no one had seen it so I sent the same fix to the mailing list. That was ignored too. So, here I had my code in their repository, which had my name on it, which had a bug that I had no way of patching/fixing. While bugs are inevitable, I'd prefer to keep as much of the code that has my name on it as bug free as possible! Otherwise, it makes me look bad.

They finally patched the bug, something like 5-6 months later, but dealing with this insanity convinced me that anyone who submits code to the OpenWrt development team should be prepared to wait for Hell to freeze over before they get a response.

Just to drive the point home: I submitted another patch to a problem preventing client (sta) mode wireless without an AP from working on broadcom based routers in July 2008. It was just added 6 weeks ago (June 2009), 11 months later! No one even contacted me to let me know -- I wouldn't have noticed except that when building Gargoyle I no longer needed to apply my own patch that fixed this.

Until the developers over at OpenWrt get their collective heads out of their collective asses and fix their patch submission process, I will never submit anything to them again. Of course, my code is GPL -- anyone (you?) are perfectly free to submit it if you wish. Just don't expect a response.

4. I have no intention of making Gargoyle a fork. Despite my extreme creative differences with the OpenWrt developers, their code is very good. The first step of building Gargoyle will always be to check out the OpenWrt code base. However, I'm not sure that saying Gargoyle is "simply" a GUI is entirely correct. There's a lot of back-end functionality that I've added. A better way of looking at it, is to just say that it's built on top of OpenWrt, in much the same way Linux Mint is built on top of Ubuntu Linux, and Ubuntu is built on top of Debian Linux.

5. No, for the reasons outlined in (1)

6. In Tomato there are at most 10 service classes you can have for traffic. Gargoyle allows you to define unlimited (though the realistic limit is actually about 100) classes. Also, unlike Tomato (I think -- I haven't checked this recently, it may have been implemented since then in Tomato) you can classify and limit both upload and download traffic. Finally, Tomato reports graphs of qos usage, but you can't specify what time-frame this applies to. In Gargoyle, you can specify multiple time-frames over which you can report the usage of the various service classes. The only thing reported by Tomato that I do not report is the number of connections currently in each service class.

I don't know how this compares to paid dd-wrt -- I'm not willing to pay for a version of dd-wrt.

Thank you for clearing up the questions I had, I am much more comfortable using gargoyle now.
It is unfortunate that openwrt treats 3rd-party devs in the way you have outlined.
Two more questions when you get the time.

1. How modular/scalable is Gargoyle or put another way, how much effort would it take for an outside dev add features/pages to Gargoyle. Or are you even interested in other devs working on the Gargoyle project?

2.As far as submission to openwrt goes there is not much that can be changed from the outside. But if you where in charge, how might you go about extending openwrt's package system to allow for kernel patching? It would seem that since you have gone to the trouble of putting all of your patches into a nice script, that some where in the build system a script could be called to apply the needed patches. Even if it meant checking a box (allow untrusted kernel patches) or some similar warning.

In closing thank you for not simply giving up, your work is very much appreciated.

p.s. I realize the window for features is probably closed as you appear to be working on a 1.0 release; However when you have the time, I really like the dd-wrt interface, (although not enough to use a product i feel takes advantage of the open source community with out giving back) It seems to pack allot of information into each page. While there use of frames keeps the information from becoming over whelming and cluttered.
When you are creating the look and feel of gargoyle I would love to dd-wrt's ui be of influence to you.
(Note: I'm not asking for a rip-off of there ui or dd-Gargoyle, Simply that when some thing is done well, Others see if it maybe of use to there work as well.)

1) I would LOVE to have others contribute to Gargoyle, but so far no one has volunteered. I state in the FAQ that I'm happy to give commit access to anyone who has proven themselves by submitting 3 patches that get incorporated into Gargoyle.

I've tried to make Gargoyle as modular as possible. The navigation menu is controlled by a UCI config file (/etc/config/gargoyle). Adding or removing a section from the menu is as simple as modifying the UCI config file. The individual pages are haserl scripts (shell code embedded in html markup). There's a utility called gargoyle_header_footer which gets called at the top and bottom of each page, which generates the menu from the UCI config file. In between it's just plain html markup. If you want to know more about creating a page or editing existing pages let me know -- I'm happy to explain how the system works if you're confused.

2) What I would like to see is some hooks for user-defined configuration scripts in the build process. You could have a directory called "user-scripts" , and you could integrate downloading of configuration scripts into the current feeds system (or build an analagous system to the feed system for user-defined configuration scripts).

Ideally there would be three places where user-defined configuration scripts could be called: A) Before ANYTHING else is done in the build process, B) immediately after .config file is created (note that if it already exists this script should still be called, right after it is verified that the .config file exists), and C) immediately after the root directory is done being built but before the final firmware images are built from it.

So, you would have PRE-CONFIG, POST-CONFIG and POST-BUILD scripts. These could be subdirectories within the user-scripts folder. The feeds/scripts-download system would download .sh files into this directory. You could optionally set up your script-feed to download directories (which would be subdirectories of user-scripts/[script-type]/) of necessary patch files used by the scripts. Because they are scripts they can be as involved or as simple as necessary and could easily be used to configure a build environment to a user's specifications with a high degree of flexibility.

A PRE-CONFIG or POST-CONFIG script could easily be used to patch the kernel in this system. The reason you need both is that it would be useful for calculating patches dynamically. PRE-CONFIG would prepare the openwrt makefiles necessary, but the POST-CONFIG, which has access to information about the architecture being built could calculate what the actual kernel patch should be (which might be different depending on whether it's a 2.4 or 2.6 kernel, which was specified by the .config file).

Regarding the GUI and comparison with DD-WRT:
The user interface of Gargoyle is actually inspired to a large degree by Tomato, not DD-WRT. When I read people's reviews of Tomato and DD-WRT the general consensus seems to be that Tomato has a slicker UI, but DD-WRT has a larger number of features. I have therefore endeavored to incorporate a lot of the design elements of Tomato into my UI.

Instead of saying generally "I like DD-WRT's UI", could you be specific about exactly which elements/pages you like and how/why you feel the DD-WRT UI meets your needs better than the Gargoyle UI? Screenshots of both DD-WRT and Gargoyle with the relevant features circled in red (along with the explanation) would be ideal. I am always trying to improve, and if you can convince me that there's a clear advantage in the way DD-WRT is doing something I'm happy to try to incorporate something similar into Gargoyle.

I will try my best to put my finger on what I like about dd-wrt's UI. Although I must admit I have used tomato only looked at the screen shots I could find of it.

In general terms tomato seems to have a lot of white space on each page. DD-wrt by comparison utilizes much more of the screen real-estate, by using smaller spaces between lines and putting more information along an x-axis.
To illustrate what I'm talking about better take a look at.

The tomato basic network page and a quick gimp mock up of the same page I find this a better utilization of space, not just from a utility point of view but from an aesthetic one as well. Keep in mind I'm not talking this page as much of the general idea of how to better use space on any given screen.

In addition I would like to see a well stocked general info page (perhaps as the first page after successful login.) Have it divided into sub-sections based on the available modules in the Gargoyle build currently running.For instance perhaps have a section of the page labeled Process, where all of the running process which Gargoyle can configure are listed. Clicking on any of the listed process brings me to the Gargoyle configuration page for that process such as Dropbear or NTP. While clicking on the Process label it self brings me to the Gargoyle page for managing system processes.

You could have a similar section for System Stats. With avg. network speed/utilization, current RAM and SWAP usage, CPU load, How much of the bandwidth quota(s) has been used so far. Clicking on the small quota graph could take you to the quota config page, while the network speed/utilization might take you to the QOS page.

An other useful section might be Router where you could display the MAC of all NICs in the router as well as the different IPs the box has and what mode the router is in GW/AP/etc... None of which could be changed from the current page but all of which could be linked to the appropriate page to make the needed changes.

Here is a page similar to the one I have just described.


For me the separation of pages purely for information/linking and pages for configuration allows for lots of information to be displayed in one place without adding confusion when trying to make some sort of change to a given setting. I do not know if others would find this to be the case or not though. I would be interested to hear your thoughts on this and please let me know if I have not conveyed my recommendation appropriately.