Williams: That's when I reach for my revolver...

Depending on the card, it usually takes a udev rule to prod the card/dongle to switch from USB mass storage to usb modem mode (for USB dongle devices that need this prodding), then a ppp peer config and a chatscript to tell the card to initialize and connect to the network, then "dial" the magic number to get a data connection.

Was having that discussion the other day with somebody too... With Mac OS X for example, you might actually be able to create new software that doesn't need to go through a few iterations before it's actually useful to most people, becuase there isn't as much variation in hardware or OS.

But with Linux, so many people use it in so many configurations, and with so much hardware (and so many drivers of differing quality), that if you don't release stuff early and get people testing it, you'll just go through the same pain whenever you release it later.

My first clash with NM was when someone complained to me they were not getting a DHCP lease. At the time I didn't even know what NM was, or that it was running, but soon found out when I used my the normal tools to debug the problem (ip, ping, dhclient, etc), and then something was undoing my changes. Things obviously changed, but the configuration files for those tools were untouched. Weird, it was like there was a ghost in the machine. Sniffing around I noticed some of the daemons had connections to dbus, which was a new development. I dumped the dbus messages, and eventually the path lead to NM. So it appeared someone had decided to redesign the entire configuration system for networking, moving away from configuration files I could look at in conjunction with man pages and make some sense of. Instead I was confronted with undocumented babble flying across a software bus. You can probably tell how impressed I was with that development.

Still, the solution was simple enough. Disable NM manager, debug the problem as I would normally, then re-enable NM. The problem was unrelated to NM - it was a bug the in firmware of a wireless router. The only issue NM caused was one of visibility - while NM was running it was impossible to tell at what point things were going wrong.

My second clash with NM was on a machine that has a broken wireless switch. Ie it had an internal wireless card that was fully functional, but because of the broken switch you could not turn it on. The owner plugged in a second wireless card, which worked perfectly when I configured it manually. Network manager refused to do anything with the second wireless card. I considered finding the bug in NM, but then visions of all those dbus interconnections rose up and I thought better of it. Any event driven daemon with its fingers in that many pies was probably a nightmare inside. So I just blacklisted the first wireless card, and NM was happy.

There were other clashes whose details escape me now, but suffices to say I have never had a machine which NM "just worked" on. There was always some situation in which it bugged out. Admittedly I tend to work on problems which have defeated others, so the machines tend to have some kink. But not the final one, which occured last weekend. It was a newly installed Ubuntu 8.10 machine. The owner wanted to use one of those 3G USB dongles described the article. To NM's credit the dongle just worked. Having proved the dongle worked we disconnected it, and asked NM to reconnect to 802.11. Do you think it would do that? Nope. Again I had not trouble doing it manually, NM wouldn't. In the end I just told the guy to reboot his machine if he wanted to change from 3G to 802.11.

So now we come to this 3G modem thing. It is great you NM guys are working on it. But what have you produced? I haven't looked, but is it a generic tool we can all use to probe these things, or some code deep within the guts of NM that only NM can use? It is not just an NM problem. Servers and openwrt boxes also have this problem, and they don't run NM.

NetworkManager is both the carrot and the stick. If NM just worked around broken stuff and proprietary drivers, it would be a hacktower of doom and we may still be stuck largely in 2006-wireless land.

Examples of driver/stack fixes due to NetworkManager:

- mac80211 adhoc mode association event and ibss merging timeout fixes
- fix wpa_supplicant adhoc/infra mode switching
- driver scan capabilty advertisement (automatically handle ap_scan=1/2)
- always respect specific SSID probe scans
- always return scan success/fail information instead of dropping it on the floor leading to userspace timeouts
- age scan results on resume so userspace doesn't get stale AP lists
- driver conformance to WEXT APIs, especially for WPA support around 2006/2007
- D-Bus control interface for wpa_supplicant
- Huge input to next-generation kernel wireless APIs so we don't repeat the mistakes of WEXT (especially with feedback from kernel->userspace, a large weakness of WEXT)
- improved ethernet driver support for carrier detection