Gargoyle Forum

Hello,

I'm a long time OpenWrt/Gargoyle user and I usually just like to read the forums but I felt compelled to report on pmerrill's workaround as a good solution for other ar71xx routers. I've implemented pmerrill's suggestion of the disassoc_low_ack and disabling of ani wireless workarounds on a TL-MR3020, Netgear WNDR3700 V1 and Netgear WNDRMAC V2 and wireless has been performing excellently on all three devices since I've implemented them. Before this, I had contemplated trying DD-WRT on the Netgear units as the wireless was so iffy with Openwrt/Gargoyle but it's rock solid now. These workarounds have improved reliability of the wifi connection even at great distances. I can now go to my neighbors home who is about 2 brick homes away from mine and still get very good and reliable signal. Thank you to pmerrill for this suggestion and Eric for this awesome version of OpenWrt!

dieselz wrote:@pmerrill
is it possible to have that 11b mode i don't care if each devices gets equal 11mb but at least i get to have that amazing signal i had, if so what do i do?

There is a couple reasons why you can only get 11b, one of which is the devices talking to the router, like an old laptop or an old wireless network card? The other problem can be old drivers or settings on your wifi device. You can have a new laptop but old drivers can cause it to go slow. My suggestion is leave the settings on Gargoyle as is and check out the drivers for your devices. If you have a new-ish android phone handy connect it the the internet via wifi and check out the speed under settings. My Galaxy S3 will indicates 135Mbps, which is good for that phone. You should see the same.

Eric wrote:pmerrill -- Thank you for finding a workaround for some of the wifi issues people have reported. For some reason, I rarely if ever run into these issues on my own network so it's really hard to debug. You would think this would be a good thing, but not being able to reproduce (and therefore test potential solutions for) reported bugs is rather frustrating.

I would be curious about the independent effect of the disassoc_low_ack and the distance parameter are. I suspect that the disassoc_low_ack issue is the main culprit here -- if you remove the distance parameter so it goes back to the default but keep the dissassoc_low_ack parameter set to zero, what happens? Do you see a performance drop, or does everything continue to work properly?

I will update Gargoyle so this parameter gets set automatically in future versions of Gargoyle, to at least mitigate this problem, even if it's not a full solution.

Glad to help, you guys do all the real work. I just tinker around the edges. As for the disassoc, that and the distance must be related. If you set the distance too low, then it should not actually connect to devices a long way away because the router will ignore ACKs that take too long. One should set the distance lower because it means that your neighbours devices will be ignored more. Distance = 500 means a radius of 250m from the router, which should be enough unless you've got a very big property!!

The disassoc_low_ack failure means the router is not getting the ACK back or it "thinks" it's not getting it back (due to the bug) and disassociates the client. The client then re-connects automatically which results in the poor bandwidth (it's spending a lot of time disconnecting and reconnecting). At this point, with distance = 500, I am not getting any disassoc in my syslog. This could be explained by a race condition in the firmware that is caused when distance = default (2000) and disassoc_low_ack is enabled. It make sense that a race condition can be fixed by disabling disassoc_low_ack OR reducing the distance which changes the ACK wait time and possibly removes the race condition.

If this is true, the speed of the router's processor can also play a part. I may not see the problem but someone with a 1043nd may because their processor runs at a different clock speed than my 4300, or of course visa-versa. Race conditions like this can be caused by lots of things, usually too many interrupts coming in and sometimes not turning interrupts off in some cases when changing variables in C (i.e., the old problem of referencing a global variable from an interrupt routine and changing the global variable in another interrupt routine). It can get really complicated and a bugger to find.

So far the 5 June release is working fine now for me with distance=500. I will keep a watch on the latest release in Show and Tell to see how it goes and may tinker when I get a chance.

will this work with wr941nd :/


i always have wifi connection problem so i wonder