wireless LAN doesn't start at graphical login screen

[geofft]

Ubuntu doesn't start the wireless network until a user has logged in, ostensibly so that it can pick up the list of preferred networks, and if they need encryption, grab the password out of the login keyring.

This interacts poorly with debathena-login-graphical. In particular, you need the wireless LAN to be working before a user logs in, so you can authenticate their network login. If you have no local users, the machine is basically useless. This mostly affects laptops, although desktops with wireless-only connections are common in places like dorm rooms that don't have many Ethernet drops.

When I heard about this problem last fall, I wrote  http://geofft.mit.edu/p/start-network.py , a simple Python script to ask NetworkManager over D-Bus to enumerate all wireless networks on all interfaces and connect to the first one named "MIT". I haven't tested it with Ubuntu 8.10 or 9.04 -- the interfaces may well have changed. It also needs to be packaged better; two options are to run this out of an initscript at boot time, and to make this a "custom command" in the GDM greeter that you can choose from the login screen.

It would be nice if you could also specify what network to connect to. To be useful, though, this functionality probably depends on running GUI applications at the login screen, which we haven't yet figured out how to do. Maybe we can use the same setup as the Firefox kiosk mode will, and create a special local user that can only choose a wireless network to log in to (via the built-in GUI applet to do this).

Ticket #208 is also relevant for this configuration, since the wireless connection is prone to disconnecting.

[andersk]

In Jaunty at least, if you right-click on the NetworkManager applet, go to Edit Connections… → Wireless → Auto MIT → Edit…, and check “Available to all users”, then NetworkManager will connect to it at boot. I don’t know whether you can do this in Intrepid, but we may not have to care for much longer.

[xavid]

I'm just going to point out again that this would be useful for the live cd as well.

[geofft]

Do we want to package the NetworkManager configuration to create an "Auto MIT" (and "Auto MIT N"?) network and enable it at boot?

Or do we just want to document how to make this work, and hack it in the live CD?

[broder]

I'd very much be in favor of pre-packaging the NetworkManager config. I think I'd probably drop it in for -workstation users, but I'm not sure.

[jdreed]

We do not want or need "MIT N". 802.11n devices will successfully connect to the SSID "MIT" at 802.11n speeds. The "MIT N" SSID merely prevents a/b/g devices from associating with it. Additionally, the new Cisco APs are not everywhere on campus yet. The SSID "MIT" is guaranteed to work everywhere on campus.

Wireless is fragile, and NetworkManager is even more fragile. This seems like it's asking for breakage, and as such it wants *A LOT* of testing before deployment. For example:

a) What happens if a machine is connected to both wireless and wired? Does it deal seamlessly with switching between interfaces (as OS X does)?
b) If there are wireless issues (the new Cisco APs interact poorly with some Broadcom chipsets, resulting in random timeouts or disconnects), will it fall back to wired without user intervention? Will it reconnect if the network barfs?

If we do this, it would be awesome if we also dropped in some sort of script that runs on ifup events that attempts to see if you got a real DHCP address or a registration one. I don't have a good way for it to notify the user, but it could at least spew to syslog or something. I'm envisioning having a stock answer that says something like "Q: Why can't I log in? A: Go look at the file /var/log/whatever and see if it says "WARNING: Your machine may not be registered for MIT DHCP".

[jdreed]

To clarify:

We do not want or need "MIT N".
802.11n devices will successfully connect to the SSID "MIT" at 802.11n speeds.

802.11n devices will successfully connect to "MIT" using 802.11n where the AP supports it (the new Cisco APs). In buildings with the older Enterasys APs, the device will use 802.11b/g.

Or, more succinctly, "the 'MIT N' SSID is not required in order to get a device to connect at 802.11n speeds"

[geofft]

I've packaged the configuration file as debathena-network-manager-config in r23974 (apologies for the empty commit message; I thought the hook would figure it out) and uploaded it to -proposed. Nothing depends on it yet; we should include it in the live CD and probably in -workstation assuming it works.

[geofft]

I've been reasonably happy with how this works on campus. You do need to click the NetworkManager panel icon and tell it to re-associate to get a new IP when moving between subnets; I'm not sure if there's a way around that, or that's worth caring about for the case where nobody is log in.

I do want to do more testing with this setting off campus, or in locations with weak/unusable MIT essids and stronger non-MIT essids, though.

[jdreed]

You do need to click the NetworkManager panel icon and tell it to re-associate to get a new IP when moving between subnets

What buildings was this tested in? You shouldn't (in theory) need a new IP on the 18.111 wireless network when moving between buildings. We should test this in main group or N42, or somewhere with the new wireless APs.

[andersk]

Karmic’s GDM is totally awesome (#369):

ln -s /etc/xdg/autostart/nm-applet.desktop /usr/share/gdm/autostart/LoginWindow/

will give you a NetworkManager applet at the login window.