1.0 Final

[Eric]

As promised, Gargoyle v1.0 is here! After one year of development, Gargoyle is officially out of Beta.

Improvements in this release include:

• Improved Bandwidth Quotas.
• New Web authentication system
• New Access Restrictions Implementation
• Significantly improved stability
• Major bug fixes in the bandwidth monitor
• Numerous minor bug fixes

One known issue exists: There is a major bug preventing wireless AP+Client mode from working properly on Atheros devices (e.g. La Fonera, Dir-300). Broadcom devices (e.g. WRT54GL, ASUS WL500GP) are unaffected. This problem exists in the latest releases of OpenWrt (on which Gargoyle is based). I am currently working to resolve this.

Also, from now on, instead of uploading "bleeding edge" firmware, I will increment the third digit of the version every time I make a new firmware upload. All versions X.Y.Z will be unstable/bleeding edge if Z is not zero, while stable versions will be of the form X.Y.0 This will help keep track of which bleeding edge version is running on a given system.

[DoesItMatter]

What are the different versions for Atheros?

gargoyle_1.0.0-atheros-ubnt2-pico2-squashfs.bin
gargoyle_1.0.0-atheros-ubnt2-squashfs.bin
gargoyle_1.0.0-atheros-ubnt5-squashfs.bin

Are these compiled under different systems?

Do they have any performance gain?

Thanks for the 1.0.0! Uploading the default one now!

[Eric]

Those versions are specifically for ubiquity routers, which require different files from what other atheros routers do. A couple people have requested them in the forums, so I'm just posting them to the download page for this release .

[sticky]

Hi
Looking good! Quotas working as expected.
Slight problem with the 'Download bandwidth data' It just produces:

USAGE: bw-stats [OPTIONS] [MONITOR NAMES]
" -h display output in human readable format"
" -m display output in minimalistic format"
" -u print usage and exit"

S

[Eric]

Oops...

I fixed the bandwidth data issue before, but somehow forgot to commit/build the fix (which is just one line of code). I just applied it and uploaded new 1.0.0 firmware (for real this time!). I figure a minor one-line fix less than 24 hours after release doesn't deserve a different release number.

[beowulf62381]

With the release of a stable 1.0, will there be a stable branch added to svn?

[Eric]

No, at least not yet. This is for 2 reasons:

1) I don't have any radical changes planned that would take the software in a radically different direction -- features that exist in 1.0 will exist in 1.1, though they will be added upon/improved. Branching is most important when a completely new/experimental approach is being taken, and a LOT of things are likely to break.

2) Branch maintenance is hard work, and very tricky to get right. I've had some problems with the OpenWrt "stable" branch -- it seems that the developers are a bit overzealous in committing new patches and it's broken things in the past, and they have a bunch of people working on this, trying to get it right. I am currently the only developer of Gargoyle (though I'm always looking for help... anyone interested? ) and I think my time is better spent (at least for now) working on improving the main trunk than doing branch maintenance.

[beowulf62381]

Thank you in light of your comments I feel you have made a very well reasoned decision.

I do have a rather Newb question though, What is the purpose of svn TAGs is this simply so we can build on the same revision that that a release was built on?

p.s. Unfortunately I have no codding skills and can barley write a bash script, although your commenting practices make this doable to a degree for me, thank you. With that said, as I become more aqwanted with Gargoyle I would be more than happy to help with other parts of Gargoyle creation such as documentation if it would be useful to you or the community.

[Eric]

The idea of a tag is to build a version of the software exactly as it was when the tag was created. A branch includes fixes for problems that are found after it was created, but only critical fixes and not the new, experimental upgrades. Tags are easy: they're just a snapshot of the the trunk at the time they were created. Branches are hard because you have to maintain them.

[sticky]

Oops...

I fixed the bandwidth data issue before, but somehow forgot to commit/build the fix (which is just one line of code). I just applied it and uploaded new 1.0.0 firmware (for real this time!). I figure a minor one-line fix less than 24 hours after release doesn't deserve a different release number.

Just a small Q, what format is the date/time in?
Thanks
S