[prism2.5] doesn't associate for network-manager with hostap_cs

Some tests with only wpa_supplicant and the example open_ap config file show that I can at least get it to associate but it thinks, for some reason, that it can't authenticate (which I asked it not to do).

If someone will work with me on this I imagine we can figure out what's going on.

Thanks for taking the time to report this bug. Unfortunately, we are
not able to fix and find the bug because your description of the bug
didn't have enough information in it. You may find it helpful to read
"How to report bugs effectively",
        http://www.chiark.greenend.org.uk/~sgtatham/bugs.html.
We'd be grateful if you would then provide a more complete description
of the problem.

Debugging procedures for certain types of problems can be found at
http://wiki.ubuntu.com/DebuggingProcedures

Reinhard,

What information do you feel is lacking? I've given the use case, the software and hardware involved, examples of where the driver appears to work and appears to not work, evidence that it probably works upstream, pointers to example config files I've used (I could have been more specific on that one I suppose).

What more information do you feel would be helpful in reproducing and / or diagnosing this bug?

- Andrew

In this case, I'd like to know what card are you excatly using. Did you try to run wpa_supplicant by hand? please save the debug log in a file and attach it to this bug when running it manually.

Did you try to run 'ifup --verbose eth1'? please attach your /etc/network/interfaces and your wpa_supplicant.conf.

The card is a BenQ AWL100. It's a perfectly generic prism2.5-based card almost exactly identical to Netgear's prism2.5-based card. I knew that wouldn't help much so I didn't mention it.

"Some tests with only wpa_supplicant" was meant to mean that I ran wpa_supplicant by hand. "The example open_ap config" should have read "/usr/share/doc/wpasupplicant/examples/wpa_connect_open_ap.conf". I won't bother attaching that file since you already have it.

The output of ifup --verbose eth1 with the following in /etc/network/interfaces is attached:

iface eth1 inet dhcp
        wpa-driver hostap
        wpa-ssid onenet
        wpa-key-mgmt NONE

The following /etc/network/interfaces entry works perfectly:

iface eth1 inet dhcp
        wireless-mode Managed
        wireless-essid onenet

Adding wpa-scan-ssid 1 to /etc/network/interfaces appears to work at first but running wpa_cli you can watch the following:

<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:1f:09:54 (SSID='onenet' freq=2412 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:1f:09:4c (SSID='onenet' freq=2462 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:1f:09:4c (SSID='onenet' freq=2462 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:1f:19:62 (SSID='onenet' freq=2432 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:1f:19:62 (SSID='onenet' freq=2432 MHz)
<2>Authentication with 00:00:00:00:00:00 timed out.
<2>Trying to associate with 00:60:1d:23:92:3f (SSID='onenet' freq=2437 MHz)

The network here has multiple AP's. NetworkManager fails to even appear to work because it (unlike ifup) waits for wpasupplicant to tell it that it has authenticated properly before attempting dhcp.

It looks like this may not be specific only to hostap. A co-worker mentioned he had the same problem with an atheros card and there are reports upstream of the same problem with intel and with ndiswrapper.

See http://hostap.epitest.fi/bugz/show_bug.cgi?id=62

This may also be a duplicate of Bug #42504.

I don't think so. The problems you experience are pretty depending on the implementation of the chipset driver. All references to other bugs are referring to either madwifi, ndiswrapper or bcm43xx, which have nothing to do with the problem you describe.

I rather suspect the firmware you are using being problematic. Are you able to associate without wpa_supplicant using iwconfig only? Do you have network connectivity?

oh, I see above that plain iwconfig tools do work. Could you please retry with the driver backend 'wext' instead of 'hostap'?

Which kernel version are you using? which version of hostap is this?

I get similar results with wext except that I think it's actually not associating when that driver is used.

Kernel is 2.6.17-6-386 (Edgy). The module says it's 0.4.4-kernel.

I had updated the card to the latest firmware a long while back but I don't recall how to ask the card what firmware version that is.

Ah, this is how you ask about firmware versions:

# hostap_diag eth1
Host AP driver diagnostics information for 'eth1'

NICID: id=0x800c v1.0.0 (PRISM II (2.5) PCMCIA (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.8.0 (station firmware)

Just to be sure, can you please boot a dapper desktop (live) cd and
retry from that live session? I want to be sure that this isn't a
regression in the kernel, (which I could imagine)

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Interesting. Using the dapper desktop CD ifup works fine with:

iface eth1 inet dhcp
        wpa-driver hostap
        wpa-ssid onenet
        wpa-scan-ssid 1
        wpa-key-mgmt NONE

NetworkManager also appears to work fine.

Just as I thought. This means to me that this is a regression in the kernel. Reassigning to linux-source-2.6.17 as discussed on IRC with zul.

Is there any way I can help get this bug fixed? It's still broken from what I can tell and I don't want to have to wait till edgy+1 for it to get fixed. I'm willing to help if someone wants to tell me what to do.

Also, the description isn't very accurate as is. It associates just fine with ifup, what it doesn't do is authenticate and wpa-supplicant / network-manager seem to think it needs to authenticate (or something) before they will try to get an address.

'Me too' with a bcm43xx and a linksys in open mode.

Flagging as a regression

Someone please confirm if latest edgy is fixed for prism2 chipsets. They should be using hostap (except for prism2_usb).

My card is getting orinoco_cs by default still and hostap_cs still doesn't associate when used through network-manager.

PCMCIA cards do not use prism2.5.

prism2.5 in this case refers to the Intersil Prism 2.5 chipset which is actually very common in PCMCIA cards. This bug has nothing at all to do with prism2_* (linux-wlan-ng) and everything to do with network-manager not being able to cause a prism 2.5 chipset using the hostap drivers to associate properly even though it worked when dapper was released and doesn't work on edgy now. hostap and wpa-supplicant are also written by the same folks. hostap was the default driver for wpa-supplicant for a long long time.

I have another bug open which has a lot to do with prism2_cs (linux-wlan-ng). You also commented on that bug so I imagine the 3 bugs I'm subscribed to relating to prism2.5 chipsets and their drivers are just getting totally mixed up in everyone's heads. This is completely understandable. I have to be careful to make sure I'm commenting on the right bug myself. No biggie.

I am perplexed though that you say that linux-wlan-ng doesn't support pcmcia cards. You can do a search on packages.ubuntu.com for prism2_cs.ko to see that it did exist in dapper.

Removing milestone; even if this is a regression and doesn't work, it's too late to fix at this point.

It's probably not too late to fix this for Feisty.

At the moment the wireless- options in /etc/network/interfaces works fine, as do the wpa- options, but network-manager doesn't work.

Andrew, did you actually try 2.6.20 from feisty? any progess there?

Yes, I tried it with 2.6.20-5. There seems to be some progress as the wpa- options in /etc/network/interfaces works now (as they did in the dapper live-cd but not in edgy) but network-manager still isn't working.

That might make that a new bug. I'll let you decide that and I'll be happy to help debug the issue in either case.

err, I'm not sure if I have understood you correctly. Can associate/connect using the wpa- stanzas with 2.6.20? If it doesn't work with NM, it might be that the driver backend algorithm is borked in network manager. In order to fix that, please attach a working /etc/network/interfaces to this bug. Please also say with what kernel version this works for you. This way we can check the driver detection algorithm in network-manager.

Reinhard, you're probably right that it's just not using the right driver backend. My /etc/network/interfaces specifies the hostap driver backend. Changing this to the wext driver backend causes it to exhibit the same behavior as nm.

Using kernel package 2.6.20.5.1 (x86) on a Dell Latitude C600.

I don't recall what version the kernel was when this last worked properly. It's an old bug. Is there any other information I can get you that might help?

Bug 78037 may be informative. The workaround is:

sudo ifconfig [interface] down
sudo iwconfig [interface] essid [essid] key [key]
sudo ifconfig [interface] up
sudo dhclient3 [interface]

This just worked for me using WEP through both rt2500 and prism54 cards in Feisty (bug 82711). Something like it may help with WPA.

What happens if you try setting the essid when the card is up? I haven't had any problems with hostap_cs and my prism 2 using network-manager, but I'm not using WEP or WPA.

I've tried that I think, and it didn't help. I thought we had already determined that the problem was that network-manager / wpa-supplicant was choosing the wrong back-end driver.

Does network-manager make the decision about which wpa-supplicant backend to use?

I believe I've found the reason that this bug still exists in gutsy: The driver is version 0.4.4 (an unstable version released 2005-08-21) while wpa-supplicant is version 0.6.0 (latest devel release). Wireless-extensions support was added to the hostap driver in version 0.4.5 (2005-09-25). Updating to the current stable release of the hostap driver will very likely fix this issue.

See hostap driver changelog here: http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/*checkout*/hostap/ChangeLog?rev=stable&content-type=text/plain

I also want to add that this bug will be much more serious if the orinoco_cs is not added back into the kernel package. Fixing this, on the other hand, will make prism 2.5 chipsets work perfectly for most people, including with network-manager.

Ugh, my bad - hostap was integrated into the main kernel a while back and the version numbers don't line up. I don't know what's causing this stupid bug then. If one of the Ubuntu kernel devs wants me to mail them a prism 2.5 pcmcia card I'd be happy to.

This is also problematic on my Thinkpad T30's internal miniPCI wireless card. Orinoco_pci worked like a charm... it would be nice if orinoco_* were included, even if those drivers were blacklisted by default.

Here's what happens when I load the hostap_pci driver with network-manager loaded:

And, BTW, when I manually configure eth1 with the network-admin adminstrative dialog, the connection works, and sudo ifup eth1 and sudo ifdown eth1 do work fine:

Aug 2 13:03:10 localhost dhclient: There is already a pid file /var/run/dhclient.eth1.pid with pid 134812041
Aug 2 13:03:10 localhost dhclient: Internet Systems Consortium DHCP Client V3.0.5
Aug 2 13:03:10 localhost dhclient: Copyright 2004-2006 Internet Systems Consortium.
Aug 2 13:03:10 localhost dhclient: All rights reserved.
Aug 2 13:03:10 localhost dhclient: For info, please visit http://www.isc.org/sw/dhcp/
Aug 2 13:03:10 localhost dhclient:
Aug 2 13:03:10 localhost dhclient: wifi0: unknown hardware address type 801
Aug 2 13:03:11 localhost avahi-daemon[4975]: Registering new address record for fe80::205:3cff:fe04:51e6 on eth1.*.
Aug 2 13:03:11 localhost dhclient: wifi0: unknown hardware address type 801
Aug 2 13:03:11 localhost dhclient: Listening on LPF/eth1/00:05:3c:04:51:e6
Aug 2 13:03:11 localhost dhclient: Sending on LPF/eth1/00:05:3c:04:51:e6
Aug 2 13:03:11 localhost dhclient: Sending on Socket/fallback
Aug 2 13:03:14 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7
Aug 2 13:03:19 localhost kernel: [ 780.632000] wifi0: LinkStatus=2 (Disconnected)
Aug 2 13:03:19 localhost kernel: [ 780.632000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Aug 2 13:03:19 localhost kernel: [ 780.640000] wifi0: CMD=0x0121 => res=0x7f, resp0=0x0004
Aug 2 13:03:19 localhost kernel: [ 780.640000] wifi0: hfa384x_set_rid: CMDCODE_ACCESS_WRITE failed (res=127, rid=fc48, len=2)
Aug 2 13:03:19 localhost kernel: [ 780.644000] wifi0: LinkStatus=2 (Disconnected)
Aug 2 13:03:19 localhost kernel: [ 780.644000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Aug 2 13:03:19 localhost kernel: [ 780.652000] wifi0: LinkStatus=2 (Disconnected)
Aug 2 13:03:19 localhost kernel: [ 780.652000] wifi0: LinkStatus: BSSID=44:44:44:44:44:44
Aug 2 13:03:19 localhost kernel: [ 780.664000] eth1: Trying to join BSSID 00:09:5b:38:87:c0
Aug 2 13:03:19 localhost kernel: [ 780.680000] wifi0: LinkStatus=1 (Connected)
Aug 2 13:03:19 localhost kernel: [ 780.680000] wifi0: LinkStatus: BSSID=00:09:5b:38:87:c0
Aug 2 13:03:20 localhost kernel: [ 781.620000] eth1: no IPv6 routers present
Aug 2 13:03:21 localhost dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 15
Aug 2 13:03:21 localhost dhclient: DHCPOFFER from 192.168.2.1
Aug 2 13:03:21 localhost dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Aug 2 13:03:21 localhost dhclient: DHCPACK from 192.168.2.1
Aug 2 13:03:21 localhost avahi-daemon[4975]: Joining mDNS multicast group on interface eth1.IPv4 with address 192.168.2.212.
Aug 2 13:03:21 localhost avahi-daemon[4975]: New relevant interface eth1.IPv4 for mDNS.
Aug 2 13:03:21 localhost avahi-daemon[4975]: Registering new address record for 192.168.2.212 on eth1.IPv4.
Aug 2 13:03:21 localhost dhclient: bound to 192.168.2.212 -- renewal in 2939 seconds.

On Tue, Jul 31, 2007 at 02:16:50PM -0000, Andrew Jorgensen wrote:
> Does network-manager make the decision about which wpa-supplicant
> backend to use?
>

Yes it does ... what driver should be used ?

currently we have a few special cases. maybe we need another special
case ... or just use default wext for some?

here what we have:

       if (!strcmp (kernel_driver, "ath_pci"))
               wpa_driver = "madwifi";
        else if (!strcmp (kernel_driver, "hostap_pci") || !strcmp
 (kernel_driver, "hostap_cs") || !strcmp (kernel_driver,
 "hostap_plx"))
               wpa_driver = "hostap";
        else wpa_driver = "wext";

 - Alexander

ok ... currently investigating.

Hmm, unfortunately at the moment neither works (gutsy, updated today) , although using the wext driver it times out faster.

can you try with latest gutsy network-manager please?

I'm not having any better luck with the latest network-manager ( 0.6.5-0ubuntu9 ). It doesn't seem to respect roaming/non-roaming mode.

Is there any particular additional information I can provide that will be of help?

On one of my systems I am enjoying a fully working network-manager system now! Even WPA2 is working perfectly. Oddly, though, on the other system I tested on I, like Michael, had no luck at all. I will test again on that system and will try upgrading the card's firmware as well since I know that the working one has a more recent firmware.

From the working system:
# hostap_diag wlan0
Host AP driver diagnostics information for 'wlan0'

NICID: id=0x800c v1.0.0 (PRISM II (2.5) PCMCIA (SST parallel flash))
PRIID: id=0x0015 v1.1.1
STAID: id=0x001f v1.8.0 (station firmware)

Will look at the other system in the morning if possible.

How does one go about updating the firmware on the hostap device?

Here's the info from my non-working system:
burner@phoenix:~$ sudo hostap_diag eth1
Host AP driver diagnostics information for 'eth1'

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.0
STAID: id=0x001f v1.4.9 (station firmware)

It's rather involved but described well here (requires the hostap-utils package):
http://linux.junsun.net/intersil-prism/

Hm... anyone have step-by-step instructions that work on gutsy? The instructions there don't seem to work (prism2_srec claims that it wants the PRISM2_NON_VOLATILE_DOWNLOAD and PRISM2_DOWNLOAD_SUPPORT to be enabled, which do appear to be set in the gutsy kernel driver. Also, the standalone hostap-driver package don't compile either.

OK, I found out that part of my problem was due to some udev rules that had been generated back when the orinoco_pci driver was default. When the hostap_pci driver loaded, udev forced the card to be named eth*, rather than wlan*, which confuses the hostap_* and prism2_* programs.

I still have some more things to investigate, but I had to edit /etc/udev/rules.d/70-persistent-named-net.rules and change an "eth1" to "wlan0"

Ugh... hosed my card when I bungled the firmware upgrade :-(

BTW: anyone know how to reflash the card if you flashed only the primary firmware without the secondary?

You should be able to just flash it again with the correct firmware in most cases.

I guess others will take that as a warning not to try flashing the firmware. I'm very sorry to hear that it didn't go well for you.

Incidentally - I did retest my other card - it's an older hardware version and has the latest firmware available for it and it does not work. The hostap driver developers may know more about if these older cards are simply a loss or if the driver should be working.

still present in 0.6.5-0ubuntu9 ?

sorry that irepeated my question ... just ignore that post:

... can someone confirm for now that the udev rule is wrong?

No, my laptop's hardware's apparently hosed. The flasher program can't communicate with it anymore.

I also have a PCMCIA card that has the prism2 hardware. I successfully updated that card's firmware to 1.7.4 and it does seem to work fairly well with network manager now (previously it had a really old 1.3.6 firmware).

BTW: I found a debian bug report re: the udev rule, too: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=365777

Of course this is related to how prism2_srec works, but it may be confusing wpa_supplicant or something else, too.

On Wed, Aug 08, 2007 at 04:00:56AM -0000, Andrew Jorgensen wrote:
> On one of my systems I am enjoying a fully working network-manager
> system now! Even WPA2 is working perfectly. Oddly, though, on the
> other system I tested on I, like Michael, had no luck at all. I will
> test again on that system and will try upgrading the card's firmware as
> well since I know that the working one has a more recent firmware.

Maybe it works on a not-hidden network, but doesn't when ssid's are
not broadcasted (aka hidden)?

 - Alexander

Unfortunately I've tried the other card in the same machine against the same networks. It does appear to be an issue between the driver and the firmware. It would probably

 . . . be good to contact the hostap devs and see if they think it should be working. Or at what firmware revision it should work. They may have a workaround or a clue about where the bug may be in the driver.

On Sat, Aug 11, 2007 at 10:41:35PM -0000, Andrew Jorgensen wrote:
> . . . be good to contact the hostap devs and see if they think it
> should be working. Or at what firmware revision it should work. They
> may have a workaround or a clue about where the bug may be in the
> driver.
>

Would you do that and report there answers?

Thanks for your contribution,

 - Alexander

Thread begins here: http://lists.shmoo.com/pipermail/hostap/2007-August/015927.html

Andrew,

the link is broken now ...

anyway, what was the outcome of this? Should NM use wext driver?

 - Alexander

The wext driver should be used with current versions of hostap but that doesn't appear to be the problem. There is some interaction between the driver and the firmware that is failing in some cases now. Probably the next step would be to go back to versions of the kernel that worked and compare them with versions that don't work.

16:10:15.022391 wifi0 Scan request completed
16:10:17.431952 wifi0 New Access Point/Cell address:Not-Associated
16:10:17.476782 wlan2 Set Mode:Managed
16:10:17.486940 wlan2 Set Frequency:2.427 GHz (Channel 4)
16:10:17.498810 wlan2 Set ESSID:"6bFair"
16:10:17.513736 wifi0 New Access Point/Cell address:00:16:B6:1E:C7:2B

and n-m never sees the association. I suspect that this is due to the event coming from wifi0 rather than wlan2. I'll take a quick look at this, but right now I lean towards blaming the kernel.

On Tue, 2007-09-25 at 15:18 +0000, Matthew Garrett wrote:
> and n-m never sees the association. I suspect that this is due to the
> event coming from wifi0 rather than wlan2. I'll take a quick look at
> this, but right now I lean towards blaming the kernel.

Does it behave any differently for you if you remove the udev iface
renaming rule so that it's wifi0 and wlan0? The hostap utils have
problems when those numbers don't match. Internally the driver seems to
keep track of just the number and assumes that wifi and wlan will match.

Ensuring that the kernel sends events on both the wifi and wlan interface seems to make network-manager happy. I'll submit a patch.

Looks pretty solidly like a kernel issue

Gutsy commit 8dedc62d72d630b6278420dad36652bfc7fd99b1.

linux-source-2.6.22 (2.6.22-13.40) gutsy; urgency=low

  [Amit Kucheria]

  * Enable CONFIG_VM86 for LPIA
    - LP: #146311
  * Update configuration files
  * Disable MSI by default
  * Add mmconf documentation
  * Update configuration files

  [Bartlomiej Zolnierkiewicz]

  * ide-disk: workaround for buggy HPA support on ST340823A (take 3)
    - LP: #26119

  [Ben Collins]

  * ubuntu/cell: Fixup ps3 related modules for d-i, enable RTAS console
  * ubuntu/cell: Enable CELLEB and related modules (pata_scc)
  * ubuntu/cell: Move ps3rom to storage-core. Also use spidernet, not
    spider_net.
  * ubuntu/cell: Set PS3_MANAGER=y
  * ubuntu: Set NR_CPUS=256 for sparc64-smp

  [Chuck Short]

  * [USB] USB] Support for MediaTek MT6227 in cdc-acm.
    - LP: #134123
  * [XEN] Fix xen vif create with more than 14 guests.
    - LP: #14486

  [Jorge Juan Chico]

  * ide: ST320413A has the same problem as ST340823A
    - LP: #26119

  [Kyle McMartin]

  * fix -rt build
  * fix ia32entry-xen.S for CVE-2007-4573
  * fix build when CONFIG_PCI_MSI is not set

  [Matthew Garrett]

  * hostap: send events on data interface as well as master interface
    - LP: #57146
  * A malformed _GTF object should not prevent ATA device recovery
    - LP: #139079
  * hostap: send events on data interface as well as master interface
    - LP: #57146
  * A malformed _GTF object should not prevent ATA device recovery
    - LP: #139079
  * Don't lose appletouch button release events
  * Fix build with appletouch change
  * Disable Thinkpad backlight support on machines with ACPI video
    - LP: #148055
  * Don't attempt to register a callback if there is no CMOS object
    - LP: #145857
  * Update ACPI bay hotswap code to support locking
    - LP: #148219
  * Update ACPI bay hotswap code to support locking
    - LP: #148219
  * Don't attempt to register a callback if there is no CMOS object
    - LP: #145857
  * Disable Thinkpad backlight support on machines with ACPI video
    - LP: #148055

  [Steffen Klassert]

  * 3c59x: fix duplex configuration
    - LP: #94186

  [Thomas Gleixner]

  * clockevents: remove the suspend/resume workaround^Wthinko

  [Tim Gardner]

  * orinoco_cs.ko missing
    - LP: #125832
  * Marvell Technology ethernet card not recognized and not operational
    - LP: #135316
  * Marvell Technology ethernet card not recognized and not operational
    - LP: #135316
  * acpi_scan_rsdp() breaks some PCs by not honouring ACPI specification
    - LP: #144336
  * VIA southbridge Intel id missing
    - LP: #128289
  * Add T-Sinus 111card to hostap_cs driver to be able to upload firmware
    - LP: #132466
  * RTL8111 PCI Express Gigabit driver r8169 big files produce slow file
    transfer
    - LP: #114171
  * Guest OS does not recognize a lun with non zero target id on Vmware ESX
    Server
    - LP: #140761
  * Modualrize vesafb
    - LP: #139505
  * Nikon cameras need support in unusual_devs.h
    - LP: #134477
  * agp for i830m broken in gutsy
    - LP: #139767
  * hdaps: Added support for Thinkpad T61
    - LP: #147383
  * xen: Update config for i386
    - LP: #139047
  * xen: resync for amd64
    - LP: #139047
  * ide-disk: workaround for buggy HPA support ...