I've run into a similar problem on a laptop running Fiesty running
2.6.20-16-generic.
iwconfig --version says it is Wireless-Tools version 28, compatible with v11-v20
and the kernel is compiled with Wireless Extension v21. The machine is using
ndiswrapper / bcmwl5 for device 14E4:4311. lspci claims this is a "Broadcom
Dell
Wireless 1390 WLAN Mini-PCI Card", though that's probably not what Compaq would
like us to call it (since thisis a Presario F500).
The network I've been having trouble getting onto is a WPA enterprise (TKIP,
WPA-EAP, EAP-TLS) network which doesn't broadcast its SSID. In this situation,
I'm familiar with the regular wireless-tools failing to associate with certain
chipsets.
For example the Atheros cards won't associate to a WPA access point (even if
some non-TKIP EAP traffic is necessary before encryption) because it
disqualifies
the base station because its WPA flag doesn't match the interface's WPA
configuration.
I was a little taken aback however with the ndiswrapper behavior of not even
displaying
the requested ESSID while it was scanning. An "iwconfig wlan0 essid foo" then
an
"iwconfig wlan0" right after would give "ESSID:off/any" which had me barking up
the
wrong tree for a while wondering if the hardware was active at all. A "iwlist
wlan0 scan"
would successfully list all broadcasting access points, however, and from notes
in other
fora, I guessed correctly that only when the association succeeds does the
ESSID: line
on ndiswrapper interfaces reflect the requested access point name.
I'm used to working around the "won't assocciate to WPA host" problem on
Atheros-based
machines using "ap_scan = 1" global flag in the wpa_supplicant.conf. This
instructs
WPA-supplicant to not only passively watch the interface for associations, but
to actively
scan and configure the interface to connect to each of the configured networks
in case the
network is hidden. This works successfully on Atheros machines, but does not
on this
Feisty / ndiswrapper machine with wpa_supplicant configured as either "-Dwext"
or
"-Dndiswrapper".
Before resorting to kernel recompilation and the attendant issues with
upgrades, etc, I hit
upon a solution. In Atheros-based machines you can control the WPA
functionality using
an iwpriv call (which I assume is what wpa_supplicant does). Sure enough
ndiswrapper
for this broadcom card also had a promising looking iwpriv named
"set_auth_mode". After
a lot of wrangling and repeated trials I ended up with a working combination:
With wpa_supplicant configured with "ap_scan = 0", and "-Dwext" (_not_
ndiswrapper)
running using /etc/network/interfaces wpa-* calls (i.e., configuring
network-manager not
to configure this interface) wpa_supplicant would configure the right ESSID but
sit around
waiting for association. If while wpa_supplicant is in this state, one issued
the command
"iwpriv wlan0 set_auth_mode 3" (and I did another "iwconfig wlan0 essid <ssid>"
for good
measure) all of a sudden the interface would associate, wpa_supplicant would
notice and
fire off the EAP-TLS process and everything was smooth sailing from there.
The trick was now to find a way to automate this delicate dance in a repeatable
manner.
I ended up with a pre-up script in /etc/network/interfaces that forked off the
iwpriv process.
I've attached it as wireless_ndiswrapper_enable_wpa.sh.
/etc/network/interfaces has the following lines in it:
auto wlan0
iface wlan0 inet dhcp
wireless-essid My SSID
wireless-mode Managed
wireless-key 0000000000
pre-up /usr/bin/wireless_ndiswrapper_enable_wpa
wpa-conf /etc/netsecure/wpa_supplicant.conf
wpa-driver wext
Hope this helps someone.
** Attachment added: "Attempt to work around association issues in ndiswlan"
http://launchpadlibrarian.net/8514980/wireless_ndiswrapper_enable_wpa.sh
--
can't connect to hidden network
https://bugs.launchpad.net/bugs/50214
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
