Re: Pruning the active AP

[Dan Williams <dcbw redhat com>]

On Wed, 2008-07-09 at 10:59 +0200, Markus Becker wrote:
> On Thu, 3 Jul 2008, Dan Williams wrote:
> 
> > On Thu, 2008-07-03 at 17:28 +0200, Markus Becker wrote:
> >> Hello,
> >>
> >> I was checking how NM reacts, when an AP, that we are connected to,
> >> dies or is getting out of range. I was expecting NM to notice that and
> >> remove the current AP from the list of available APs. However, NM keeps
> >> the AP in its list. I think this is because of this in nm-device-wifi.c:
> >
> > Have you tried it with the patch from Adel Gallah for the scan timeout
> > stuff from last week?  That patch specifically fixed the issue of never
> > noticing that the AP was out of range even after the supplicant had sent
> > the disconnection status.
> 
> No, I was trying without it (with Michael Biebl's packages). With r3811 
> NM seems to notice that an AP is gone, after about 30 sec. And it takes 
> about 50s to figure out that an AP has come back (Including the booting 
> time of the AP.)

Ok, that seems to be about the expected behavior.

> But what I was looking for, but didn't see, is link_timeout_cb().

Odd; it should get called after the 30 seconds that the AP has been
down.  That's what Adel's patch did.

> >
> >> /* Don't ever prune the AP we're currently associated with */
> >> if (cur_ap_path && !strcmp (cur_ap_path, nm_ap_get_dbus_path (ap)))
> >>    keep = TRUE;
> >>
> >> What was the reasoning behind keeping the AP we're connected to, when it
> >> is not in the scanning list anymore? Are some cards not reporting the AP
> >> we are connected to in the scanning list or why?
> >
> > Yes, even though they technically should, drivers and cards don't
> > necessarily do this.  Since wireless is a fairly unreliable medium, it's
> > not always the case that the connected AP's beacons will show up in a
> > given scan.  We simply cannot rely on that unless drivers are mandated
> > to include that upstream in the kernel.
> 
> Well, it works with the ndiswrapper for the Marvell card (sorry, 
> currently no time for the mrv8k driver).

mrv8k doesn't work well enough yet anyway.  I try to spend time on it
now and then but don't have a lot for it.  Johannes has a
"marvell.tar.gz" that is actually a vendor driver for mrv8k pre-N
hardware, but it was based on net80211 and I can't even get it to
compile with a recent net80211 so I can analyze the behavior.

Dan