Re: non-beaconing access points

[Dan Williams <dcbw redhat com>]

On Mon, 2005-08-08 at 10:05 -0400, Bill Moss wrote:
> When you started early versions of NM in a area with no wireless 
> beacons, the detecting icon would spin forever. If you clicked on 
> 'Connect to Other Wireless Network ...', entered ESSID and WEP key, you 
> could make a connection to a non-beaconing AP. Then several people 
> including myself complained and thus was born the no-connection icon and 
> the 'STOP All Wireless Devices' context menu item. With CVS HEAD 1.441, 
> it you boot in an area without wireless beacons, you see the 
> no-connection icon immediately. No attempt at connection is made. This 
> is good. Now if you  click on 'Connect to Other Wireless Network ...', 
> enter ESSID and WEP key, nm-applet hangs in the detecting mode and the 
> only way to stop it is to reboot. The 'STOP All Wireless Devices' 
> doesn't work. You can kill NM but you can't kill nm-applet.

Earlier versions of NM (around 0.3.x days) contained code to do limited
association to the AP just to verify that the AP existed and that you
could connect to it, then would go through the entire association
+connection+DHCP process.  That, however, took around 20s to complete in
the best scenarios, and longer in the worst ones.  So the code got
removed.  That may have helped out here.

The only way to connect to non-broadcasting/non-beaconing access points
is to essentially know all the connection details.  You have to know
ESSID, WEP Key, and possibly channel.  When cards themselves try to
associate with an access point by simply setting ESSID, they scan an
internal list of known access points first to see if they know what
channel the ESSID is present on.  They then set their frequency to that
channel, set their ESSID, then transmit association request packets on
the channel to begin association/authentication.

I'm curious if/how this process is different when the AP isn't
broadcasting /anything/.

> Looking at the debug log, you see that NM hangs in
> 
> NetworkManagerDevices.c: nm_device_activate_schedule_stage1_device_prepare
> 
> at the line
> 
>         g_source_set_callback (source, (GSourceFunc) 
> nm_device_activate_stage1_device_prepare, req, NULL);
> 
> The function  nm_device_activate_stage1_device_prepare never gets called.

This seems to indicate that the device's thread is blocked doing
something else and therefore it never gets around to dispatching the
idle handler for the association request.  That's interesting.

> The simplest approach may be to say that NM doesn't support 
> non-beaconing APs. If you want to duplicate this experiment, turn off 
> your AP, boot, and try to make a connection with the 'Connect to Other 
> Wireless Network ...' dialog.

I'll have to check this out.

Dan