On 11/6/06, Dan Williams <[EMAIL PROTECTED]> wrote: > 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.
Yes, I agree. But using nm I get connection some times (after lot of tries) and after this the connection is stable. The problem is getting connection and not keep connected... So I guess that the problem is not only the signal quality, but the set: low quality + lot os APs + hidden SSID. > 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. I'm using CVS version, it's already using DBus, right? Aloisio > Dan > > > Thanks > > Aloisio > > _______________________________________________ > > NetworkManager-list mailing list > > [email protected] > > http://mail.gnome.org/mailman/listinfo/networkmanager-list > > _______________________________________________ NetworkManager-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/networkmanager-list
