Ubuntu
network-manager package

Does not work with hostap driver

Bug #6369 reported by Rui Matos on 2006-01-02

This bug report is a duplicate of: Bug #32213: Doesn't handle devices with unusual names. Edit Remove

Affects		Status	Importance	Assigned to	Milestone
	network-manager (Ubuntu)	New	Medium	Unassigned

Bug Description

Using current dapper:

linux-image-2.6.15-10-686 2.6.15-10.15
network-manager 0.5.1-0ubuntu6

when I insert my pcmcia card I get this on syslog:

Jan 2 17:35:14 localhost kernel: [4370368.913000] pccard: PCMCIA card inserted into slot 0
Jan 2 17:35:14 localhost kernel: [4370368.913000] cs: memory probe 0xa0000000-0xa0ffffff: clean.
Jan 2 17:35:14 localhost kernel: [4370368.921000] pcmcia: registering new device pcmcia0.0
Jan 2 17:35:14 localhost NetworkManager: <debug info>^I[1136223314.828061] (): New device added (hal udi is '/org/freedesktop/Hal/devices/pcmcia__1__1').
Jan 2 17:35:15 localhost kernel: [4370369.543000] ieee80211_crypt: registered algorithm 'NULL'
Jan 2 17:35:15 localhost kernel: [4370369.613000] hostap_cs: 0.4.4-kernel (Jouni Malinen <email address hidden>)
Jan 2 17:35:15 localhost kernel: [4370369.615000] hostap_cs: setting Vcc=33 (constant)
Jan 2 17:35:15 localhost kernel: [4370369.615000] hostap_cs: CS_EVENT_CARD_INSERTION
Jan 2 17:35:15 localhost kernel: [4370369.615000] hostap_cs: setting Vcc=33 (from config)
Jan 2 17:35:15 localhost kernel: [4370369.616000] Checking CFTABLE_ENTRY 0x01 (default 0x01)
Jan 2 17:35:15 localhost kernel: [4370369.616000] IO window settings: cfg->io.nwin=1 dflt.io.nwin=1
Jan 2 17:35:15 localhost kernel: [4370369.616000] io->flags = 0x0046, io.base=0x0000, len=64
Jan 2 17:35:15 localhost kernel: [4370369.617000] hostap_cs: Registered netdevice wifi0
Jan 2 17:35:15 localhost kernel: [4370369.658000] hostap_cs: index 0x01: Vcc 3.3, irq 3, io 0x0100-0x013f
Jan 2 17:35:15 localhost kernel: [4370369.852000] prism2_hw_init: initialized in 194 ms
Jan 2 17:35:15 localhost kernel: [4370369.853000] wifi0: NIC: id=0x800c v1.0.0
Jan 2 17:35:15 localhost kernel: [4370369.854000] wifi0: PRI: id=0x15 v1.1.1
Jan 2 17:35:15 localhost kernel: [4370369.854000] wifi0: STA: id=0x1f v1.8.0
Jan 2 17:35:15 localhost kernel: [4370369.858000] wifi0: registered netdevice wlan0
Jan 2 17:35:15 localhost kernel: [4370369.908000] orinoco 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
Jan 2 17:35:15 localhost kernel: [4370369.912000] orinoco_cs 0.15rc3 (David Gibson <email address hidden>, Pavel Roskin <email address hidden>, et al)
Jan 2 17:35:15 localhost NetworkManager: <debug info>^I[1136223315.835834] (): New device added (hal udi is '/org/freedesktop/Hal/devices/net_00_02_6f_06_a2_ea').
Jan 2 17:35:15 localhost NetworkManager: <debug info>^I[1136223315.852677] (): New device added (hal udi is '/org/freedesktop/Hal/devices/net_00_02_6f_06_a2_ea_0').
Jan 2 17:35:15 localhost NetworkManager: nm_is_driver_supported: assertion `dev->driver != NULL' failed
Jan 2 17:35:15 localhost NetworkManager: <information>^Iwlan0: Driver support level for '(null)' is unsupported
Jan 2 17:35:15 localhost NetworkManager: <information>^Inm_device_new(): waiting for device's worker thread to start
Jan 2 17:35:15 localhost NetworkManager: <information>^Inm_device_new(): device's worker thread started, continuing.
Jan 2 17:35:15 localhost NetworkManager: <information>^INow managing wireless device 'wlan0'.
Jan 2 17:35:15 localhost NetworkManager: <information>^IDeactivating device wlan0.
Jan 2 17:35:19 localhost NetworkManager: nm_try_acquire_mutex: assertion `mutex != NULL' failed
Jan 2 17:35:24 localhost last message repeated 3 times
Jan 2 17:35:25 localhost kernel: [4370380.085000] wlan0: no IPv6 routers present
Jan 2 17:35:29 localhost NetworkManager: nm_try_acquire_mutex: assertion `mutex != NULL' failed
Jan 2 17:36:04 localhost last message repeated 14 times

And so on...

The orinoco driver is also loaded but it doesn't create a network device and even after a modprobe -r orinoco-cs NM won't work.

Revision history for this message

Rui Matos (tiagomatos) wrote on 2006-01-03:

It seems to work great if the card is in the slot during boot. I'll do some more tests.

Revision history for this message

Sami Haahtinen (ressu) wrote on 2006-01-16:

The same problem occurs with ndiswrapper.

Revision history for this message

Sami Haahtinen (ressu) wrote on 2006-01-22:

Does this bug still occur with the hostap driver? One of the recent upgrades (on other packages) fixed the issue with ndiswrapper.

Revision history for this message

mpvano (mvano) wrote on 2006-02-12:

I've not had any problem getting hostap to load after blacklisting all the other drivers (orinoco..., prism2..., etc.) in all the places searched for a (pci) driver. Specifically /etc/hotplug/blacklist.d. Other user's may need to kill loading in the pcmcia tables or in /etc/discover/hostap.d/...

However, I've found another problem with hostap.

After endless screwing around, I have found that the reason hostap drivers for prism cards act strangely under ubuntu breezy on my system is that the "ifrename" program incorrectly grabs and renames the "wifi0" control device created by hostap as the primary network interface - SOMETIMES. It does this seemingly randomly, and when it does, the real network interface (the only one you're supposed to ifup and ifdown in hostap) gets an unpredictable name.

This is particularly a problem on systems that sleep because when they wake up the resulting network names seem to be allocated in a different way then they are at boot.

Disabling the /etc/iftab entry for the interface in question (by MAC address) completely, seems to eliminate all problems. The interface is now named what the documentation says it should be and is always correctly named regardless of whether the card comes up at boot or after resume.

In the case of hostap, the card is named wlan0, which seems to be the traditional name expected by most interfaces.

I think the problem is that hostap creates an interface with a weird MAC address that looks like the actual mac address but with many more digits. It appears that ifremap only looks at the first few digits and then sometimes grabs the hostap control interface.