On Mon, 2007-05-07 at 17:48 +0200, Fionn Behrens wrote: > On 06.05.2007, 21:50 -0400 Dan Williams wrote these lines: > > > > The patch allows setting the timeout at runtime via nm-tool. > > > Unfortunately > > > it seems to have gone totally unnoticed by now, despite the fact that the > > > bug appears to be linked to upstream (bugzilla.gnome.org). > > > > It's not unnoticed, it's just the wrong fix for the problem and > > therefore won't get upstream into NetworkManager. > > Your exceptionally kindly phrased refusal is surpassed only by its > wealth of explanation. Thank you! > But with regard to how much time this took, I probably should feel > honored to finally have gotten some feedback at all.
Sorry, I had assumed that people involved in the discussion had read the archives when this topic first came up about a month or two ago. The core of the problem is that this is may be a driver issue. There's no reason why re-association should take more than a 5 - 10 seconds at most. Papering over the issue in NetworkManager without investigating why the driver is dropping association for more than 8 seconds is just the wrong answer. Without a lot more investigation into why the drivers are having problems, and why only _certain_ drivers are having problems, the patch is incorrect. Patches that are not investigated are not going to get applied just like that. I'd like to see driver traces from madwifi and ipw2200 that indicate why the association was dropped, and what the card is doing to achieve re-association during those 10 - 20 seconds. Remember, during the 10 - 20 seconds, the driver should _not_ be able to pass traffic if it's really disassociated from the AP. If the driver is actually associated to the AP, then it needs to report that correctly via WEXT, which is the noticed by wpa_supplicant, which is then noticed by NetworkManager. So we need to verify that the driver is doing the right thing first, before crying wolf and patching NetworkManager for something that in reality may not actually be required. A clear picture of the issue is required. Remember, when you encounter errant behavior, there's a lot more in the stack than just NetworkManager, and that includes both wpa_supplicant and the drivers. Historically, drivers have been quite inconsistent and buggy. That's not to say that NM is bug-free at all, just that many behavioral problems like this can be traced back to drivers behaving badly. Dan > Please share with me your wisdom on what makes the patch not preferable > to the current fixed-value non-solution and how it could be done better > so I might be able to achieve your blessing eventually. > > humbly yours, > Fionn _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
