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.
Thank you to pmerrill for this suggestion and Eric for this awesome version of OpenWrt! 
