Re: dropping WLan connection wioth NM 0.6.2

["Robert G. Brown" <rgb phy duke edu>]

On Mon, 11 Sep 2006, Dieter Steiner wrote:

> It only happens if the line is in "strong" use. Activities that won't
> use much bandwith (like ssh) don't show that behavior.
>
> Card is an ipw2200, for testing the access point was about 50 cm distant
> to the laptop, no other wireless users.

This sort of behavior has been observed and reported several times for
this card -- I see it as well, although maybe not as reproducibly as you
seem to.  Which is a good thing -- maybe at last you'll be able to
provide the data to help the bug be truly squashed;-)

In my case it usually happens when I've suspended/resumed operations
several times.  The first 1-3 times it works fine, but somewhere in the
2+ range it gets to where NM searches for networks, finds e.g. my home
LAN, connects to it, gets an IP number and displays four bars all happy,
and then drops.  Four bars all full turn empty, and a few seconds later
the connection disappears.  Others have reported similar but not quite
identical behavior, so there appears to be some occult state and
configuration dependence of the sort that makes it really hard to debug.
The problem appears to be in the ipw2200 itself, not necessarily NM per
se.

When this happens the empirical solution for me at least is to cycle
something like:

/etc/init.d/NetworkManager stop
rmmod ipw2200
modprobe ipw2200
/etc/init.d/NetworkManager start

However, this doesn't generally WORK the first time.  Looking at the
logs, it appears that the problem may be that dhpc clients may not be
aware that the entire network in question has gone away and somehow grab
the device and block anything else from being able to use it or break
the usage they attempt to establish as it happens.  Each attempt as
often as not spawns a new DHPC attempt that fails, and one has to catch
the sequence of events "just right" to get a cleanly initialized
ipw2200, no hung or pending tasks trying to use the ipw2200 device, and
NM coming up clean on top of this and hence GETTING the device in the
state it expects it to be in.  Then everything works just fine until the
next time the ipw2200 gets in a "strange state" from power management.

Some recent posts on the list have suggested sleep 10 insertions and/or
certain options for the /etc/modprobe.conf lines for the ipw2200 that
might make this work more reproducibly, e.g.

alias eth1 ipw2200
options ipw2200 hwcrypto=0 associate=0

but for me the modprobe lines do not prevent the problem from occurring.
The delay might, as empirically just waiting (or trying several times
with various lags) seems to help.  I suspect that the real problem is
deeper, though -- possibly a firmware bug in the ipw2200 itself,
possibly a bug in the linux implementation of the driver that fails to
implement power management properly so that the driver, instead of
resetting to a clean state, retains state information that may be broken
or incorrect for the new wireless environment where the laptop is
resumed, possibly in client software that is similarly unaware of power
management state changes AND which fails to check for a device reset and
die gracefully -- hard to say.

Lots of moving parts, metaphorically, that all have to fit together
"just right" to work.  When they are all in a clean, reproducible state
(e.g. post boot) they generally do, and they OFTEN do even in extended
operation along standard pathaways.  When you reach the territory where
several things are all interacting at once with an uneven or
inconsistent picture of state, though, some problems emerge.  Murphy
(and ergodicity theory:-) says that if there is a finite probability
that a system can enter a "broken" state under some stochastic pattern
of usage, sooner or later it will do so.  When the failure is rare, it
is actually really hard to debug.  When it happens every time, though,
one can usually figure out just what is going wrong and THEN one can
actually hope to fix it.  Good luck.

   rgb

> Dieter Steiner
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFFBdTl5ZAuXoeyYKMRAjePAJ0XmHMYvaTUGR+B0WZ+7iyAD/qJYwCgkb7I
> GeYXiSgv73e5nBsFZ4p7dGM=
> =ifsg
> -----END PGP SIGNATURE-----
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

--
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb phy duke edu