Re: Connecton on APs with weak signal quality

[Dan Williams <dcbw redhat com>]

On Mon, 2006-11-06 at 17:23 -0200, Aloisio wrote:
> On 11/6/06, Darren Albers <dalbers gmail com> wrote:
> > On 11/6/06, Aloisio <aloisiojr gmail com> wrote:
> > > Oooww
> > >
> > > Anybody know answers to some of these questions ??? I use nm is these
> > > conditions in most part of time...
> > >
> >
> > Network Manager attempts to associate and if it fails to do so in the
> > timeout period it does not try again.  If the signal is so weak that
> > connecting is tough then it is doubtful that NM could keep the
> > connection up.   It might be an interesting feature request to create
> > a "Keep trying" option but I can't imagine it being of much use, if
> > you have such a problem connecting you will probably have a hard time
> > maintaining a connection.
> 
> OK, this "keep trying" would simulate what wpasupplicant do... I think
> that maybe this could be a behaviour instead of a option. If it's not
> connect in anywhere and there are known SSID (and hidden SSID) in scan
> list, nm could keep trying to connect to preferred network... just a
> suggestion... Maybe not useful to most people, but...
> 
> > If the issue is that NM is just timing out before the connection is
> > made then we can help you increase that timeout in the source by
> > yourself.
> >
> 
> Yes, could solve my problem. I will increase this timeout and include
> the "keep try" option. Any directions?

However, this is never going to be a solution because what's the upper
bound?  If you're at the margins of the network, maybe 1/2 your packets
get lost during the handshakes and assoc/auth, and the association takes
a really long time.  The delay is already something like 40 seconds, and
that's _waaay_ too long already.  If you cannot associate to your
network within 20 seconds, you either need to be closer to your AP or
you need to get your network admin to fix stuff.

At the same time, moving NM to talking to wpa_supplicant over DBus will
eliminate a lot of the overhead of the current socket-based method, and
also remove the lag when spawning a copy of wpa_supplicant.  So there's
definitely room to take the latency of the connection down in
NetworkManager itself.  But perpetually increasing the connection
timeout because "it's just not long enough for my situation" isn't the
right answer in the medium or long run.

Dan

> Thanks
> Aloisio
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list