Bugzilla – Bug 801
Connection breaks down with weak signal, firmware restart
Last modified: 2006-01-11 00:07:29
You need to log in before you can comment on or make changes to this bug.
Bad performance in areas of weak reception, with firmware restarts. From: Rolf Offermanns [rolf@offermanns.de] My system: Maxdata 8100IS Notebook with ipw2200. Ubuntu breezy, kernel 2.6.12-9. Self compiled, since ubuntu has debug disabled for the ipw2200 driver. My network setup: AP = Draytek Vigor 2500We WEP128 ESSID hidden Here is the debug log. Logs were taken while I was almost out of range. At the end of the logs I went nearer to the AP and back again. You will see, that the connection was much better then. The problems don't occur when I am next to the AP. If you need any further information, please say so. I would love to have a working driver. I am a developer myself, so patching, diffing, compiling, etc. are no problem. So if you have any patches I should try, I am more than willing to help. > Does it occur on Windows if installed? No. Everything works fine then. Thanks for your work, Rolf
Created an attachment (id=545) [details] debug log with 0x43fff see above.
Created an attachment (id=546) [details] Patch for ipw2200-1.0.6 The log shows an inadvertant "associate" command when the firmware was already associated. This was caused by a call to ipw_roam() (2nd pass) after a scan was started, then aborted, by ipw_handle_missed_beacon(), and status flags were in an unexpected state due to a new missed beacon response "slipping in" from firmware at an unexpected time. The patch cleans up the behavior of ipw_handle_missed_beacon(), and prevents the call to ipw_roam() after an aborted scan. To make this work better, change IPW_MB_DISASSOCIATE_THRESHOLD_DEFAULT to a higher number, such as 24 (this will be in ipw2200-1.0.7), which will give the scan/roam logic some time to work before giving up. We should also double check to make sure that ipw_roam() *will* be called (again) after a disassociate caused by 1st pass of ipw_roam() ... I haven't seen how that works yet, but sometimes I can't find ketchup in the refrigerator, either. Greg reports: Wow, that's an improvement. It used to be that heavy VNC traffic would cause very frequent firmware restarts. With hwcrypto=0 it was a bit better but this patch so far seems to have really fixed it (with hwcrypto=0 and hwcrypto=1). Thanks! Cheers!greg
Applied for 1.0.7
I tested on ipw2200_1.0.10 with ieee80211_1.1.8. I tried this case with weak reception with WEP128. There is still firmware error on several kernel. The firmware error will be tracked in bug#779 and other related bugs. I didn't find other error except firmware error, so I verify this bug.