I have setup a syslog server and have redirected the log to that server: http://www.gargoyle-router.com/phpbb/vi ... f=7&t=1736asayler wrote:Which log did you check?hnl_dk wrote: 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.
Version 1.4.2
Moderator: Moderators
Re: Version 1.4.2
Router: TL-WR1043ND - Gargoyle 1.5.4
AP: TL-WR1043ND - Gargoyle 1.5.4
AP: TL-WR1043ND - Gargoyle 1.5.4
Re: Version 1.4.2
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
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
Re: Version 1.4.2
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?
Re: Version 1.4.2
according to this, block-extroot has been merged with block-mount.laskovy wrote: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?
Try to have a read: http://wiki.openwrt.org/doc/howtobuild/ ... howtobuild
Router: TL-WR1043ND - Gargoyle 1.5.4
AP: TL-WR1043ND - Gargoyle 1.5.4
AP: TL-WR1043ND - Gargoyle 1.5.4
Re: Version 1.4.2
Ok, problem is solved. I don't know how but now block-extroot was installed by
After that we must restore our backup, log in to console and type
and restart ofcourse. Now everythink works fine.
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
Re: Version 1.4.2
I have very similar problems on a LinkSys/Cisco WRT160NL.mix wrote: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 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.
Re: Version 1.4.2
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?
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?
WRT54GL v1.1
Gargoyle 1.4.7
Gargoyle 1.4.7
Re: Version 1.4.2
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.mix wrote: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?
http://www.gargoyle-router.com/gargoyle/
Re: Version 1.4.2
There is a difference between trunk and the backfire branch. Thanks.
WRT54GL v1.1
Gargoyle 1.4.7
Gargoyle 1.4.7
Re: Version 1.4.2
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.
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.
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM