Re: PATCH: prevent repeated reconnections with some chipsets

[Dan Williams <dcbw redhat com>]

On Sun, 2007-04-01 at 05:45 -0400, Mark Stosberg wrote:
> On Sun, 2007-04-01 at 08:30 +0200, Grant Williamson wrote:
> > Seen this issue, reworked the patch last night for 0.6.5. I think its 
> > complete. Will test this week.
> 
> Thanks Grant, 
> 
> This will be an improvement.  
> 
> I'm hoping the patch can be further refined to "just work" for people. 
> 
> As a recap, this patch allows a timeout value of 8 seconds to be changed
> by nm-tool. This means for a change to actually happen, each user has to
> create a simple script in the right location, like this:
> 
> In /etc/NetworkManager/dispatcher.d/set-timeout
> 
> Add:
> 
> exec /home/mark/Desktop/network-manager-0.6.3/test/nm-tool --set-timeout
> 20000
> 
> This increases the timeout value to 20,000. This reveals another
> complication: "nm-tool" is not installed in the Ubuntu package. (That's
> a packaging issue with them, I realize). 
> 
> Still, I just helped a middle aged farmer and college track athlete to
> both get set up with Linux laptops with these wireless cards. I'd like
> to be able to tell them it will "Just Work", not that they need to fuss
> with files in "/etc". 
> 
> I see a few alternatives:
> 
> 1. Change the value from 8 seconds to 20 seconds for everyone. That's
> unattractive if means that a lot of people will be waiting an extra 12
> seconds needlessly. 
> 
> 2. Maintain a list of cards that need this change, and dynamically
> change the value for those cards. That sounds like a big maintenance
> headache, and would be difficult to keep current, I imagine. 
> 
> 3. If there is active, working wireless connection in use, don't keep
> scanning for others, but wait for the user to click the applet to scan
> (This addresses the core issue). 
> 
> 4. Check /why/ we are timing out after 8 seconds. Is it because the card
> is busy scanning still? Then wait for at least 20 seconds before
> starting a reconnect. 

Can we get more test data?  Does this happen when the signal strength is
marginal?  Does the driver send disconnection events?  You might try
re-enabling the detailed debugging output in nm-device-802-11-wireless.c
by adding adding the '-ddd' parameter to the wpa_supplicant command line
in supplicant_exec(), then we'll be able to see from /var/log/messages
if wpa_supplicant is really getting disconnection events from the
driver.

Again; I don't want to do sometihng like increase the timeout if we
don't really know what the cause of the problem is.

Dan

> Thanks again. 
> 
>   Mark
>     
> > > The details are all in this bug report, including a link the Ubuntu bug
> > > report, which has the patch.
> > > http://bugzilla.gnome.org/show_bug.cgi?id=418065
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list