Version 1.4.2

[hnl_dk]

If I where you, I would check the log. I have also had trouble with my router. It did reboot itself and looking at the log I discovered that the router was constantly complaining about my AP.

Which log did you check?

I have setup a syslog server and have redirected the log to that server: viewtopic.php?f=7&t=1736

[mesquito]

I'm not seeing the BW graphs anymore.
Just started using Gargoyle (today) and I loaded 1.3.x initially. The BW graphs worked fine there. I discovered fw 1.4.2 and loaded that (flashed from fon-flash) and now the graphs don't work.
Tested it on Safari and Firefox (OS X).
Device is Engenius EOC-1650 which is not confirmed to be supported, but is functioning flawlessly with this great firmware! Just missing the BW graphs.
Thanks

[laskovy]

I repeat my problem: after upgrading from 1.3.16 to 1.4.2 external root don't work. Even block-extroot package is missing. Any advice or I must change back to 1.3.16?

[hnl_dk]

I repeat my problem: after upgrading from 1.3.16 to 1.4.2 external root don't work. Even block-extroot package is missing. Any advice or I must change back to 1.3.16?

according to this, block-extroot has been merged with block-mount.
Try to have a read: http://wiki.openwrt.org/doc/howtobuild/ ... howtobuild

[laskovy]

Ok, problem is solved. I don't know how but now block-extroot was installed by

Code: Select all

#opkg install block-extroot

After that we must restore our backup, log in to console and type

Code: Select all

#cp /.extroot.md5sum /tmp/overlay-disabled/etc/extroot.md5sum

and restart ofcourse. Now everythink works fine.

[Adri]

asayler: Immediately after your wireless drops out (or whatever you are experiencing), connect to the router with ssh with a wired client. What is the output of the "logread" command? Something in it will most likely correspond with the timing of the outage occurring.

I have very similar problems on a LinkSys/Cisco WRT160NL.
I am using it as a client bridge on 2.4 Ghz, 20 Mhz bandwith with WPA2+PSK. After a reboot it connects to the Access Point, but after a while it looses wireless connectivity.
When this happens I see no messages from 'logread' or from 'dmesg' indicating any errors.
When I use 'ssh' to login from a wired client, using 'wl wlan0 station dump', I can see the rx packets and tx packets incrementing, so something gets send and received on the wireless interface, but nothing gets routed.
After some time, the wireless connection might come back on it own.
When connectivity is lost, the gargoyle client bridge stays associated with the Access Point. If I close the connection from the Access Point, gargoyle will immediately reassociate and connectivity is restored.
This happens on version 1.4.0, 1.4.1 and 1.4.2.
It makes gargoyle very unstable and unusable at the moment.
Does anyone know how to get gargoyle running stable as a client bridge without repeater function?

Adri.

[mix]

I've asked this question in previous releases, and have never gotten a response. But do the gargoyle developers understand the relationship between txqueuelen and latency? Apparently this is now in OpenWRT trunk:

https://dev.openwrt.org/changeset/28251

Should this also be the default for gargoyle, which has advanced QoS features? Shouldn't ethernet interfaces be less than 1000 as well, especially if they aren't gigabit?

[sco77]

I've asked this question in previous releases, and have never gotten a response. But do the gargoyle developers understand the relationship between txqueuelen and latency? Apparently this is now in OpenWRT trunk:

https://dev.openwrt.org/changeset/28251

Should this also be the default for gargoyle, which has advanced QoS features? Shouldn't ethernet interfaces be less than 1000 as well, especially if they aren't gigabit?

Since Gargoyle is based on latest builds, I can only assume it will be in the next release since the repository is an updated build.

http://www.gargoyle-router.com/gargoyle/

[mix]

There is a difference between trunk and the backfire branch. Thanks.

[pbix]

Gargoyle is based on the latest stable branch of OpenWRT. At this moment that is Backfire. If our friends over at OpenWRT see fit to backport this change to Backfire then it will get incorporated.

Of course you can always build your own version of Gargoyle and incorporate any bleeding edge patches you like.

For most folks their WAN link is much slower than their LAN link so this change will help communication latency for Wifi nodes when the Wifi link is saturated due to additional LAN<->LAN traffic. If traffic is limited to LAN<->WAN communication (the usual case) then QoS can handle this issue and there would be no additional benefit from this patch.