Unable to connect to WPA enterprise wireless

I may have the same issue. I'm on an HP8540w EliteBook.

$ lspci
44:00.0 Network controller: Intel Corporation Centrino Ultimate-N 6300 (rev 35)

I was connecting to my corporate WPA2 network until quite recently (unsure when the issue arose, as I'm typically docked and using ethernet). I first noticed the issue this past Friday, 03/03/2012. I use wicd with the PEAP-GTC encryption setting and have not changed anything about my setup. I'm on Arch Linux, however in using wpa_supplicant manually and googling the ssl error that resulted, I got the same error posted here, so I thought I'd chime in.

Let me know if any additional information would be useful.

Status changed to 'Confirmed' because the bug affects multiple users.

What RADIUS server is used on your network? I am having the problem and we use Steel Belted radius here. The RADIUS server is rejecting the Client Hello message. This comes from openssl.

The problem is in wpasupplicant.

I'm not sure where the problem is. I get an openssl certificate error, which doesn't immediately tell me that it's wpa_supplicant. My primary point of curiosity is that my logs suggest that nothing has changed in my setup whatsoever. I know I connected to the same WPA2 enterprise network on 03.18.2012, yet my wicd wpa_supplicant configs have been the same since the beginning of March.

I did note an Arch Linux update to both dhcpcd and openssl since that date, so I may try to revert and see if I can track down the issue to an updated package. There's not much noise about this issue, though, so if it's upgrade related I'm surprised more people aren't speaking up.

For me everything was fine running Ubuntu 11.10, and upgrading to 12.04rc2 I suddenly see this failure. I suspect openssl, since that is the code wpa_supplicant uses to generate the TLS authentication messages. These messages are going out OK, but the RADIUS server does not like the contents.

Can you capture a packet trace on the wireless interface while wpasupplicant is trying to authenticate? You'll need to run wireshark as root.

I'm seeing the exact same TLS error:

SSL: SSL3 alert: read (remote end reported an error):fatal:bad certificate

Could this be related? I'm going to try rolling back OpenSSL to see what happens...
-- https://bbs.archlinux.org/viewtopic.php?id=138103

Not related for me - the openssl package in Ubuntu 12.04rc2 already has the patches described at that link.

Got a chance to downgrade via the Arch Rollback Machine to openssl-1.0.0.h-1 and I can successfully connect to wireless again. Perhaps not the same issue... but my problem seems directly related to openssl.

Can someone try on Ubuntu just to amuse me? For what it's worth, Arch didn't have any issues downgrading to 1.0.0 from 1.0.1 so hopefully Synaptic or apt-get won't burden anyone with a ton of manual dependency futzing.

I'm experiencing the same problem on Debian (also on a Lenovo X220), but rolling back to openssl-1.0.0.h-1 didn't fix things for me.

Here's a packet trace of the server rejecting the hello.

Apologies for the triple post, but I can confirm that going back to openssl-1.0.0.h-1 fixes the problem. So it does seem to be an openssl bug.

I went looking for alternate versions of libssl 1.0.0 in http://us.archive.ubuntu.com/ubuntu/pool/main/o/openssl/

To have any effect I needed to kill wpa_supplicant after installing the alternate version of libssl.

libssl1.0.0_1.0.0e-2ubuntu4 works for me.

I built a version of wpasupplicant_0.7.3-6ubuntu2 that works for me, by switching from openssl to gnutls.

I think wpasupplicant with openssl was offering 57 ciphers and with gnutls it was around 15. (I didn't write the numbers down and am having trouble getting it to regenerate the client hello message), so am not certain.

If wpa supplicant is building the list of ciphers from openssl for the client hello message, maybe it would also be possible disable some the rare ones? I tried some of the obvious things like -DOPENSSL_NO_RC2 -DOPENSSL_NO_DES, but later realised that was probably if you'd disabled those in openssl itself.

It looks like each cipher offered takes 2 bytes, and the failing openssl packet was 261 bytes, so you just need to get it below 255 bytes -- so remove 3 ciphers?

The patch I used to make it work, given the difficulties in getting acceptance for gnutls, I bet it'd cause other problems.

--- wpasupplicant-0.7.3/debian/config/linux 2012-03-13 16:11:24.000000000 -0700
+++ wpasupplicant-0.7.3.new/debian/config/linux 2012-04-06 13:26:03.230123515 -0700
@@ -33,5 +33,5 @@
 CONFIG_PEERKEY=y
 CONFIG_IEEE80211W=y
-CONFIG_TLS=openssl
+CONFIG_TLS=gnutls
 CONFIG_CTRL_IFACE_DBUS=y
 CONFIG_CTRL_IFACE_DBUS_NEW=y

I can confirm that libssl1.0.0_1.0.0e-2ubuntu4 fixes the problem.

Still broken with wpasupplicant 0.7.3-6ubuntu2 & openssl 1.0.1-2ubuntu4

had the same non-working 261 byte client hello message that doesn't work with wpasupplicant 0.7.3-6ubuntu2 and openssl 1.0.1-4ubuntu1.

Assuming updating, and killing /sbin/wpa_supplicant was enough to get wpa supplicant to use the updated openssl

I also found that openssl 1.0.1-4ubuntu1 did not fix the problem for me. I rebooted after the upgrade to make sure it was installed.

I hope that this bug will be assigned a high priority. Non-working wireless is a real problem, and will potentially result in bad press.

While we're waiting for a fix in openssl, I built a version wpasupplicant linked against gnutls and placed it in a ppa https://launchpad.net/~diane-trout/+archive/wpasupplicant-gnutls

It at least works well enough for me to connect to my companies wpa2-enterprise and my homes wpa2-psk networks.

This is confirmed to be related to openssl rather than wpasupplicant, so I'm setting up the task for it.

Recompiling OpenSSL with these patches from upstream also seems to fix the problem: http://rt.openssl.org/Ticket/Display.html?id=2771

@Raghav K. (comment 23): Really? The current package in Ubuntu 12.04 is built with those patches, as far as I'm aware. See the changelog entry for openssl 1.0.1-2ubuntu3.

If you can point to specific upstream patches that fix this that aren't in 1.0.1-4ubuntu1, I'd love to hear about it.

Could anyone affected by this bug please try openssl 1.0.1-4ubuntu2 in precise-proposed and let me know whether it fixes this?

I am still unable to connect with openssl 1.0.1-4ubuntu2. I . It looks like the same problem as before. Here is a bit of syslog:

Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: SSL: SSL3 alert: read (remote end reported an error):fatal:bad certificate
Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: OpenSSL: openssl_handshake - SSL_connect error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: CTRL-EVENT-EAP-FAILURE EAP authentication failed
Apr 19 08:42:51 fin8344m2 kernel: [ 77.468839] wlan0: deauthenticated from 00:11:92:3e:79:80 (Reason: 23)
Apr 19 08:42:51 fin8344m2 wpa_supplicant[1120]: CTRL-EVENT-DISCONNECTED bssid=00:11:92:3e:79:80 reason=23

I rebooted after installing the new packages. To confirm that I have the correct ssl packages installed, here is an excerpt from dpkg -l:

ii libgnutls-openssl27 2.12.14-5ubuntu3 GNU TLS library - OpenSSL wrapper
ii libio-socket-ssl-perl 1.53-1 Perl module implementing object oriented interface to SSL sockets
ii libnet-ssleay-perl 1.42-1build1 Perl module for Secure Sockets Layer (SSL)
ii libssl1.0.0 1.0.1-4ubuntu2 SSL shared libraries
ii libssl1.0.0:i386 1.0.1-4ubuntu2 SSL shared libraries
ii libwavpack1 4.60.1-2 audio codec (lossy and lossless) - library
ii openssl 1.0.1-4ubuntu2 Secure Socket Layer (SSL) binary and related cryptographic tools
ii python-openssl 0.12-1ubuntu2 Python wrapper around the OpenSSL library
ii ssl-cert 1.0.28 simple debconf wrapper for OpenSSL

Disappointing. Thanks. Somebody should probably report this upstream for further analysis.

Out of my depth here but I did run wireshark and this is what I get at the point of failure.

53 24.094947 IntelCor_e1:28:94 Cisco_49:62:f0 SSL 253 Client Hello
54 24.116714 Cisco_49:62:f0 IntelCor_e1:28:94 TLSv1 60 Alert (Level: Fatal, Description: Bad Certificate)
55 24.117037 IntelCor_e1:28:94 Cisco_49:62:f0 EAP 24 Response, PEAP [Palekar]
56 24.123991 Cisco_49:62:f0 IntelCor_e1:28:94 EAP 60 Failure

I tried today with wpasupplicant 0.7.3-6ubuntu2 and libssl1.0.0 1.0.1-4ubuntu3 and still didn't work.

I just figured out how to export a detailed packet trace with wireshark and am attaching the ClientHello and response messages from the non-working libssl1.0.0_1.01-4ubuntu3, and the working libssl1.0.0-1.0.0e-2ubuntu4 and my wpa supplicant that's using libgnutls26-2.12.14-5ubuntu3.

In preparing the dump I did renumber my mac address to end in 11:22:33 and the mac address of the access point to aa:bb:cc

The working versions seem to report their Client Hello version as ssl 3.0 and the non-working one as TLS 1.0. The SSL versions list 18 ciphers and the TLS version has 51 protocol suites.

I don't know if libssl 1.0.1-4ubuntu5 (in precise-proposed) was possibly supposed to contain a fix, but the error persists with that version.

I've tried using Diane Trout's wpa_supplicant built mentioned above, but that did not fix the problem for me. I've been unable to access University wifi since upgrading from 11.10 to 12.04.

Diane Trout's wpa_supplicant fixed things for me with these wireless settings:

WPA & WPA2 Enterprise
Protected EAP (PEAP)
CA certificate
PEAP version: Automatic
MSCHAPv2
username/password

Did you kill the wpa_supplicant process after installation? (Or reboot?)

If that doesn't work the other choice that worked for me is to install openssl 1.0.0e from 11.10 (and reinstall the default wpa_supplicant). My problem with that solution is the older version of openssl caused library problems with 12.04's curl. But you may not use curl so it might not be an issue in your case.

Diane's wpasupplicant worked for me. Great job Diane, thanks!

I also have a problem connecting to wired networks using peap (at work). Reverting openssl and libssl to 1.0.0e-2ubuntu4 resolved the problem. I suppose this is related to this bug.

I also have this problem--I can't connect to the wireless here at my college. The wifi here uses the same settings as what Scott Salley (ssalley) mentioned above. I first started with Fedora 16--and had this problem. So, I reformatted and installed Ubuntu 11.10; everything worked great. Then I upgraded to Ubuntu 12.04 and now I have the same problem as I had before and what everyone else has.

I am a linux n00b. Could someone please explain to me exactly how to fix this? How do I rollback what changed from 11.10 to 12.04 so I can use my college's wifi again?

I will explain how I did it: revert to openssl and libssl1.0.0 version 1.0.0e-2ubuntu4

Open Terminal: type shell commands without the surrounding ""
"apt-cache showpkg openssl" will show which versions of openssl you have available on your system
If openssl is somewhere in the 'Provides:' list just do
"apt-get install openssl=1.0.0e-2ubuntu4" and "apt-get install libssl1.0.0=1.0.0e-2ubuntu4"

If you do not have the old versions in the apt-cache you can fetch them from
http://mirror01.th.ifl.net/ubuntu/pool/main/o/openssl/ (or another mirror, just an example)
You 'll need to get openssl_1.0.0e-2ubuntu4_i386.deb or the amd64 variant if your machine is 64 bit (you can check that with "uname -p" if it is 'x86_64' you need the amd64 variant)
And you 'll also need libssl1.0.0_1.0.0e-2ubuntu4_i386.deb or the amd64 variant, same rule here.

Get these two files to the affected computer with a flash drive, I got them by booting the install disk and downloading them there, then copy them to my harddisk. So you don't need two PCs but it is easier.

Go to the directory that contain the two deb files you need.
"cd /media" to go to the place where all these things are mounted
"ls" to see a list of flash drives... that are mounted
"cd nameofdrive" to go into that drive
You may need to cd your way through all the subfolders until "ls" gives you the name of the two deb files

Then you install these deb files with
"dpkg -iR ." this means install all debian packages from the folder '.'(and folder '.' is always the current folder you "cd"ed to)

Done, check "apt-cache showpkg openssl" to see the version is added

Now it is easiest to reboot, you could also kill all affected processes and restart them, but it may take you longer than a simple reboot.

This is what I did if I recall correctly.
Another option is given by diane-trout above.

I get the error below after doing $ sudo dpkg -iR .

(Reading database ... 291933 files and directories currently installed.)
Preparing to replace openssl 1.0.0e-2ubuntu4 (using .../openssl_1.0.0e-2ubuntu4_amd64.deb) ...
Unpacking replacement openssl ...
Preparing to replace libssl1.0.0 1.0.0e-2ubuntu4 (using .../libssl1.0.0_1.0.0e-2ubuntu4_amd64.deb) ...
Unpacking replacement libssl1.0.0 ...
dpkg: error processing libssl1.0.0 (--install):
 libssl1.0.0:amd64 1.0.0e-2ubuntu4 cannot be configured because libssl1.0.0:i386 is in a different version (1.0.1-4ubuntu5)
dpkg: dependency problems prevent configuration of openssl:
 openssl depends on libssl1.0.0 (>= 1.0.0); however:
  Package libssl1.0.0 is not configured yet.
dpkg: error processing openssl (--install):
 dependency problems - leaving unconfigured
Processing triggers for man-db ...
Errors were encountered while processing:
 libssl1.0.0
 openssl

Oh I see...this breaks nodejs which requires a higher version of libssl.

Ah, sorry for comment spam--I wish I could edit or append previous comments.

Anyhow, dendaddy's instructions worked and I can connect to the wifi. But problem still remains with other packages that require higher versions ( this leads to the package manager fussing about it in update manager and elsewhere).

Downgrading openssl to 1.0.0e-2ubuntu4 (and not doing anything to wpa_supplicant) correct the issue for me but break work-critical packages that depend on >= openssl 1.0.1 (curl, virtualbox etc). So it's using wifi at work or doing work at work :(

I'm not a wpa_supplicant expert but this may indicate that either wpa_supplicant is not at fault or openssl is not at fault and wpa_supplicant just doesn't work correctly in this corner case with the new version of openssl. Upstream may be able to make that educated determination

I found the right packages to downgrade in order to work around the
problem and still allow curl and virtualbox to work. Drew Snellgrove,
you may be interested in this. I run a 64-bit distribution, and these
packages did it for me:

  libcurl3-nss_7.21.6-3ubuntu3_amd64.deb
  libcurl3_7.21.6-3ubuntu3_amd64.deb
  libcurl3_7.21.6-3ubuntu3_i386.deb
  libssl1.0.0_1.0.0e-2ubuntu4_amd64.deb
  libssl1.0.0_1.0.0e-2ubuntu4_i386.deb
  openssl_1.0.0e-2ubuntu4_amd64.deb

From wpasupplicant upstream:

> This looks like a broken authentication server implementation causing an
> interoperability issue with TLS extensions. My first guess would be the
> SessionTicket extension, but it could be any other extension that seemed to be
> enabled in the new OpenSSL build by default in the builds mentioned in the
> bugs.
>
> The exact trigger for the interop issues should be determined (including
> information on the exact software version used on the authentication server)
> and this could then be worked around by disabling that TLS extension (or
> cipher, etc. that is advertised in ClientHello) either in the OpenSSL build or
> in wpa_supplicant.

Anybody able to hit this in a place where they can determine the authentication-server information requested here?

I think this bug is fixed. At least in Ubuntu 12.04 -- perhaps from the precise-proposed update repository.

I had downgraded openssl and libssl to fix this issue--and it did--but it left me with a heap of issues such as tons of broken packages and thus being unable to install any updates or do any sort of activity with apt.

Here is how I un-did the downgrade and fixed all the issues:
sudo dpkg -r --force-depends "openssl"
sudo dpkg -r --force-depends "libssl1.0.0"
sudo dpkg --configure -a
sudo apt-get install -f

Now, restart. Then run update manager. Then restart again. Now, connecting to your wifi network shouldn't be an issue. I suspect the update I got was from the precise-proposed updates repository. It might be an update of wpasupplicant or libssl or openssl--I don't know. Synaptics Package Manager says I have package "libssl1.0.0" whose installed version is "1.0.1-4ubuntu5.2" which is the same as the latest version. And I have package "openssl" whose installed version is "1.0.1-4ubuntu5.2" which is also the latest version. And wpasupplicant -- of which I have installed version 0.7.3-6ubuntu2, the latest.

Remember, all this was done with the precise-proposed update repository selected.

One thing I still am confused about is why it says I have a package "libssl1.0.0" with version "1.0.1-4ubuntu5.2"....?!?!?

IMPORTANT: It doesn't work anymore--I think I might have read it wrong that I had connected to the right (problematic) network. However, the above method works to undo the downgrade.

@nickurak: Is this what you're asking for? If not, let me know and I'll try to find out more.

Juniper Steel Belted RADIUS version 6.0
WPA2 EAP-PEAP MSCHAPV2 with AES-

@nickurak, Our institution's WPA is marked as ArubaNet. The instructions for configuring it which worked(*) with 11.10 are at http://imss.caltech.edu/content/beavernet-configuration-linux

(*) I don't think dialog boxes were exactly right, but the instructions were close enough.

One thing different is in the extension field wireshark is listing an "Unknown 15" as the last 5 bytes of the Client Hello message.

In a successful connection I ended up with Cipher Suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

A somewhat filtered successful connection attempt.

Here's the WPA-supplicant patch I'm using, based on Jouni's upstream suggestion, which solves the issue for me here:

diff -ru a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
--- a/src/crypto/tls_openssl.c 2012-06-06 18:11:00.976524984 -0600
+++ b/src/crypto/tls_openssl.c 2012-06-06 18:10:58.240540303 -0600
@@ -917,6 +917,7 @@
 #ifdef SSL_OP_NO_COMPRESSION
  options |= SSL_OP_NO_COMPRESSION;
 #endif /* SSL_OP_NO_COMPRESSION */
+ options |= SSL_OP_NO_TICKET;
  SSL_set_options(conn->ssl, options);

  conn->ssl_in = BIO_new(BIO_s_mem());

The SSL_OP_NO_TICKET patch suggested by @nickurak's (#49) worked for me.

Happening after my upgrade to 12.04

I've tried Diane Trout's patched wpa_supplicant and it did not work for me, so this may be a related but non-identical issue

The WAP security is WPA/WPA2 personal (PSK), not enterprise, as the other reports.

Relevant sections of syslog are:
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) starting connection 'Auto XYZ'
Jun 12 14:29:03 mule NetworkManager[938]: <info> (wlan0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jun 12 14:29:03 mule NetworkManager[938]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0/wireless): access point 'Auto XYZ' has security, but secrets are required.
Jun 12 14:29:03 mule NetworkManager[938]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Jun 12 14:29:03 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jun 12 14:29:09 mule NetworkManager[938]: get_secret_flags: assertion `is_secret_prop (setting, secret_name, error)' failed
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jun 12 14:29:09 mule NetworkManager[938]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jun 12 14:29:09 mule NetworkManager[938]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0/wireless): connection 'Auto XYZ' has security, and secrets exist. No new secrets needed.
Jun 12 14:29:09 mule NetworkManager[938]: <info> Config: added 'ssid' value 'XYZ'
Jun 12 14:29:09 mule NetworkManager[938]: <info> Config: added 'scan_ssid' value '1'
Jun 12 14:29:09 mule NetworkManager[938]: <info> Config: added 'key_mgmt' value 'WPA-PSK'
Jun 12 14:29:09 mule NetworkManager[938]: <info> Config: added 'auth_alg' value 'OPEN'
Jun 12 14:29:09 mule NetworkManager[938]: <info> Config: added 'psk' value '<omitted>'
Jun 12 14:29:09 mule NetworkManager[938]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jun 12 14:29:09...

@joshua-willowisp can you see what's going on the access point? I've got my home router syslogging to a server which makes watching authentication failures a bit easier.

Other than that you might want to install wireshark and packet sniff your wireless interface. I feel pretty safe in saying if you're affected by this bug during the 802.1x exchange you should see a "bad certificate" error.

Could you connect to the access point before 12.04? Can other people connect to the AP? There are some possible settings with allowed encryption algorithms to try fiddling with as well.

@Joshua: try to verify that the pre-shared key is correctly entered. Try to reboot the access-point, or verify that the pre-shared key is also what it should be on there. This is a different issue though; it may well be worth filing a separate bug about it.

Diane: thanks for testing the SSL_OP_NO_TICKET patch; that's already a great help and possible fix.

I noticed issues connecting to a local university network recently as well; I'll try to reproduce it this week, see if I'm able to connect, and if not apply the patch and check how much it helps. Then we can provide that patch as SRU.

Hmm, the addition of options |= SSL_OP_NO_TICKET; changes behavior somewhat drastically for connection resumption, which is expected to work by upstream. I'll see how that works out with my tests, but I'd much rather such a patch be applied upstream before applying it to Ubuntu, since I'm no SSL wizard.

Jeremy, please let us know where you've seen this suggested by Jouni, if it's the case. Links to mailing lists are nice to understand what might be happening and how decisions are being made.

Nevermind me, it's on the wpa bug.

At two months old... has this been reported upstream to OpenSSL? I only find one probably similar report on OpenSSL:
--- http://rt.openssl.org/Ticket/Display.html?id=2825&user=guest&pass=guest

It doesn't seem like Ubuntu (or Arch, which is where I reported this) should be trying to fix this. The issue pretty clearly seems related to OpenSSL and certain ciphers. Is this moving toward a true fix (finding the root of the problem) or more of a workaround (using gnutls instead of openssl)? Despite several openssl releases since this all started, I still don't have working wpa-enterprise at work and have to manually downgrade every time I update. Just wondering if the efforts here are going to be fruitful?

Yes, I filed that bug, which is why it is referenced at the top of this bug, and why that bug references this one.

For #21, I tried the PPA version of wpa_supplicant, but not working for me. ppa https://launchpad.net/~diane-trout/+archive/wpasupplicant-gnutls

So when can we expect to solve this problem?

For #21, and #58

I used those packages, they work (for me)

I am seeing this issue on my Dell XPS 13 as well. Everything works fine with WPA & WPA2 personal at home. I just can't connect to WPA2-Enterprise at work.

I have tried this "https://launchpad.net/~diane-trout/+archive/wpasupplicant-gnutls" PPA, but it doesn't help. Also I have disabled the IPv6 to "ignore".

02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6230 (rev 34)

And I keep getting this from my syslog file:

Jun 22 17:50:43 cjia-xps NetworkManager[730]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Jun 22 17:50:43 cjia-xps kernel: [ 823.475824] wlan0: direct probe to d8:c7:c8:a4:ac:80 (try 2/3)
Jun 22 17:50:43 cjia-xps kernel: [ 823.675679] wlan0: direct probe to d8:c7:c8:a4:ac:80 (try 3/3)
Jun 22 17:50:43 cjia-xps kernel: [ 823.875433] wlan0: direct probe to d8:c7:c8:a4:ac:80 timed out

Please let me know if you need any other logs to help you debug

Neo: what you're seeing is a different issue -- please file a new bug report for it.

It's indeed not likely that switching wpasupplicant to use gnutls instead of OpenSSL will actually fix the bug (or it will, but introduce others). In any case, it's not the kind of change I'm prepared to do as a SRU. I'm sure there's a way to fix this, I just have a hard time reproducing the bug and figuring out what exactly is wrong.

In the meantime I'll get a package with wpasupplicant disabling just the Session Ticket extension for testing by the people here, before sending it to -proposed. I'm (sorry) not convinced yet that it will solve the issue for everyone ;)

I'm pretty sure the problem I had with connecting to my 802.1x network had something to do with one of the new TLS extensions that was enabled. It was pretty clear gnutls's TLS support isn't as complete as openssl's (fewer extensions, fewer supported ciphers). My packet inspections showed the version of openssl that shipped with 12.04 enabled several new extensions when compared to the 11.10 version of openssl or gnutls.

It'd be useful if there was a version wpasupplicant that would allows easily changing which extensions are enabled so we can see which access points support which extensions.

Would it be too obnoxious to add a configuration option to wpa supplicant that allows manually twiddling flags on the SSL_set_options(conn->ssl, options); call? Or would it be better to come up some test tool that can test the various combinations of extensions with 802.1x authentication?

On Thu, Jun 28, 2012 at 1:51 PM, Diane Trout <email address hidden> wrote:
[...]
> Would it be too obnoxious to add a configuration option to wpa
> supplicant that allows manually twiddling flags on the
> SSL_set_options(conn->ssl, options); call? Or would it be better to come
> up some test tool that can test the various combinations of extensions
> with 802.1x authentication?

Patches are welcome ;)

However, that's only something I'd change in development release, not
in a stable release.

Setting the options as a parameter seems rather complex though, since
you'd probably have to do that as a value that would then get
bit-shifted to set the appropriate options, and perhaps ORed with the
other options that should be set automatically by the wpasupplicant
code. A big can of worms ;)

As for testing the extensions with 802.1x; the issue you're most
likely to get into is that different vendors support different
extensions with different levels of success, so you're still bound to
run into things that break horribly every once in a while.

Mathieu Trudel-Lapierre <email address hidden>
Freenode: cyphermox, Jabber: <email address hidden>
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93

Hello All,

  The PPA in #21 worked for me. Thanks Diane!

- Andor

Just filed bug 1019081 to track the Dell XPS 13 WPA2 connection issues.

Does this lastest openssl fix this bug: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1020621

@cement_head: If you're asking whether 1.0.1-4ubuntu5.3 (from precise-proposed) fixes the WPA Enterprise problem, the answer is no, at least for me. I replaced Diane Trout's wpasupplicant with wpasupplicant_0.7.3-6ubuntu2_amd64.deb and remained unable to connect. Once I put her version back, connection was immediate.

If there's another version of libssl I should be trying, please let me know.

Tested this last night and seeing exactly the same issues on a machine with a very similar Centrino WIFI adapter as the original poster.
Test with these versions Openssl 1.0.1-4ubuntu5 and wpasupplicant_0.7.3 on Ubuntu 12.04 - fully patched as of 10/07/2012 with proposed sources selected.

I Created a new partition on the same box, installed a fresh version of 11.10, and all works fine.

The bug listed against openssl seems to have seen no movement since the 8th June.

A serious issue has been identified , but is anyone actively working on getting a resolution? Just asking.

More than happy to help with diagnosis and testing if asked.

I tried the version of openssl lp:ubuntu/openssl revno: 80 tags: 1.0.1-4ubuntu4 but that version's changelog didn't seem to refer to Bug #1020621, so I tried debian's 1.0.1c-3 which did refer to including a fix for their version of the Bug #1020621 bug debbugs #675990.

Unfortunately neither worked as I was still getting the BAD CERTIFICATE error from my schools access point.

Testing protocol was reinstall the default precise
  * wpasupplicant 0.7.3-6ubuntu2,
  * kill wpasupplicant
  * start wireshark
  * watch ssl messages

After I saw that it was failing again, I tried each of the openssl builds listed above in turn.

One thing my wireshark captures were showing me, is that the more recent versions of openssl were adding an "extension 15". I tracked that down as the tls "heartbeat" extension. Using debian's 1.0.1c package I prevented openssl from adding the Heartbeat extension to the client hello message, and reinstalled the official ubuntu precise wpasupplicant_0.7.3-6ubuntu2_amd64.deb and shocking was able to connect.

The attached patch is more to show where in the code the problem I'm having is located.

I also tried "s->tlsext_heartbeat &= SSL_TLSEXT_HB_DONT_RECV_REQUESTS;" which also seemed to suppress the heartbeat message.

Any suggestions for how we should see if this works for other people?

The attachment "disable heartbeat." of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

Disabling the TLS heartbeat in openssl does *not* work for me. However, disabling TLS session tickets in wpa_supplicant does. See the wpa bug report for a patch. http://w1.fi/bugz/show_bug.cgi?id=447

Diane Trout's wpa-supplicant gnutls patch has stopped working. My institution has made some changes in their wireless configuration. I haven't been able to find out what they did, and it's possible that some other software upgrade on my system caused the problem instead.

In any event I am now again unable to connect wirelessly with 12.04.

I also tested last night with the latest libssl installed on 12.04 libssl-1.0.1-4Ubuntu5.3, and the wireless connection disconnected after about 5 minutes of usage as before. This is a major issue, and means I have had to move back to 11.10 just to connect wirelessly.

As 12.04 is an LTS, it does seemed very odd that their appears to be no urgency to fix this problem, the problem was identified in March.

Well tested this evening with 12.10 Alpha three , which has the following versions intalled , and it works fine

ubuntu@ubuntu:~$ uname -a
Linux ubuntu 3.5.0-6-generic #6-Ubuntu SMP Mon Jul 23 19:52:14 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
ubuntu@ubuntu:~$ dpkg -l | grep libssl
ii libssl1.0.0:amd64 1.0.1c-3ubuntu1 amd64 SSL shared libraries
ubuntu@ubuntu:~$ dpkg -l | grep wpa
ii wpasupplicant 1.0-2ubuntu2 amd64 client support for WPA and WPA2 (IEEE 802.11i)

So this is fixed in 12.10, but it's not being fixed in 12.04 LTS ? What is going on here , surely this is all wrong?

Can others test this and see if they seem the same results. I know it's an Alpha 3, but if it works for you, then it is a potential short term solution.

I just tested xubuntu 12.10 Alpha three and it did *not* connect. I get the same "sslv3 alert bad certificate" error.

Here is what I was told about our recent networking change: "we were using Cisco WAPs, whereas now we're using Aruba. In both cases, we used WPA2 Enterprise MSCHAPv2 PEAP for the authentication."

The failure of Diane Trout's gnutls fix roughly coincides with this changeover, although the tech folks here say the timing is not exact (i.e., I was able to connect at least once after they say they made the changeover).

I tested the patch in the wpa supplicant ticket, but while it allows me to actually connect does not provide for a stable connection. I've reverted back to the official package for now, but the inability to join my work wireless is becoming more painful.

Just like the original poster, I have an X220 with the Centrino Advanced-N 6205.

The wireless infrastructure is Aruba with Microsoft RADIUS and MSCHAPv2 PEAP.

@rcmd Could you try running a packet sniffer (like wireshark)?

For me this bug shows up when my client hello message includes an "Unknown 15" extension. One of the other patches that worked for some people disabled the SessionTicket extension. The upstream bug report was wondering if it was all unknown SSL extensions that was causing the bad certificate error, or just some of them.

(In wireshark you can find what extensions are included in the by looking in the Info column for "Client Hello", and then expanding 802.1x Authentication -> Extensible Authentication Protocol -> Secure Sockets Layer -> SSL or TLS(*) Record Layer: Handshake Protocol -> Handshake Protocol: Client Hello and look at the bottom of the drop down.

(*) for a working capture it was listed as TLS Record Layer, for a non working capture it was listed as SSL Record Layer.

For me I can connect when the extension list is: ec_point_formats, elliptic_curves, and SessionTicket TLS. But when "Unknown 15" (AKA the Heartbeat extension) is present I can't. The above comments seem to imply that for others it doesn't work if there's the Session Ticket.

Not being able to keep a stable connection is a different issue than not being able to connect at all -- please file your own separate bug report if you're running into such issues.

As far as I could tell, in most cases disabling the Session Ticket extension allowed wpasupplicant to auth to the networks successfully, so I'd like to get more testing on that.

Could people please start testing the wpasupplicant package in my PPA https://launchpad.net/~mathieu-tl/+archive/sru-staging ?

Thanks!

Swapped to the packages from Mathieu's PPA. Connects like a charm where the stock packages fail. Long term connection stability not tested.

Mathieu's ppa did not work for me. (To be clear, I only installed the package wpasupplicant_0.7.3-6ubuntu2.1~mtrudel1.) I get a long string of these:

[ 25.748578] wlan0: authenticate with d8:c7:c8:71:xx:yy (try 1)
[ 25.946467] wlan0: authenticate with d8:c7:c8:71:xx:yy (try 2)
[ 25.947192] wlan0: d8:c7:c8:71:xx:yy denied authentication (status 17)
[ 144.484429] wlan0: authenticate with d8:c7:c8:71:xx:yy (try 1)
[ 144.680999] wlan0: authenticate with d8:c7:c8:71:xx:yy (try 2)
[ 144.681881] wlan0: d8:c7:c8:71:xx:yy denied authentication (status 17)

What other information would be helpful? (I was attempting to try a wireshark capture with the help of Diane Trout but was unsuccessful when trying to capture packets for this specific connection. If it would help, tips on how to do it would be appreciated.)

Mathieu's PPA wpasupplicant does allow for a successful authentication. Unfortunately, as soon as I roam to a different AP the connection dies and won't join again until I turn wifi off and back on. See attachment for the log during roam.

Like rmcd1024 the patched wpasupplicant from Mathieu did not help me. The behavior is
still the same.

@DianeTrout: I was finally able to get a wireshark capture of an unsuccessful connection attempt (thanks for your help Diane!), and I can confirm that "unknown 15" is present in the Client Hello handshake protocol.

I appear to have the same issue. Connecting to WPA2-enterprise network fails on ubuntu 12.04 but succeeds on 11.10 using identical settings.
System:

Dell Latitutude E5500
Internal Wireless card
Settings:
WPA2-enterprise
PEAP
no certificate (ignored certificate warning)
DHCP assigned address and DNS servers
IPV4 system

Connection works in Windows 7 and Ubuntu 11.10; fails in ubuntu 12.04 64 bit.

I can confirm that the patch mentioned in #72 works for me on Arch Linux (patch here: http://w1.fi/bugz/show_bug.cgi?id=447).

rcmd: the issues you're seeing are related to roaming, and not that patch (or at least, not "without any doubt"). What reason 17 means is that the AP can't handle new stations; which probably means it's overloaded.

FWIW, I can always add the extra other setting (SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION) from the patch on the bug, but I'm still not sure this will cover all the issues, and it's still not really confirmed by the wpa developers. I'll prepare a new package in my PPA soon and give it a test myself next week just to make sure it doesn't break connections that I know work properly.

@mathieu-tl: I think you're correct. As a test, I rebooted into ubunutu 11.10. In the past, I have always been able to connect with 11.10, this time I again got connection denied with "reason 17". However, my Android phone connects immediately to the same AP, so I don't think the AP is overloaded. Moreover, I can't connect anywhere on campus that I've tried. (There would be lots of complaints from others if this were due to overloading.) As I mentioned, there was a networking infrastructure upgrade this summer. This could account for a different experience now with 11.10

So you're probably right that this is a different issue. It does seem widespread where there is aruba networking infrastructure (for example, see this: http://ubuntuforums.org/showthread.php?t=1889157 .)

The version in http://ppa.launchpad.net/mathieu-tl/sru-staging/ubuntu worked for me.

Just to clarify, I'm using (and unable to connect with 0.7.3-6ubuntu2.1~mtrudel1, which I believe is the version Diane Trout is referring to.

Good point @rmcd1024, I too am using 0.7.3-6ubuntu2.1~mtrudel1

One of my campus network support staff contacted me hoping that this bug had a general solution released.

So what kind of additional testing do we need to do before this patch can be moved out of a PPA and into the main distribution?

(I suggested the network support staff try the above PPA on a 32-bit system since they'd thought they'd seen some wireless connectivity differences between 32 and 64 bit.)

No additional testing to go through the SRU process (which means another package, in precise-proposed, and a testing period of at least 7 days). I'll get to this in a few hours :)

Preparing the upload for Quantal now...

The fix is now in Quantal:

wpa (1.0-2ubuntu5) quantal; urgency=low

  * debian/patches/session-ticket.patch: disable the TLS Session Ticket
    extension to fix auth with 802.1x PEAP on some hardware. (LP: #969343)

I also updated the tasks to note that the fix in quantal is on the 'wpa' source package, rather than 'wpasupplicant', though both are in fact the same software.

Hi,

Am I correct in assuming that this'll show up in Precise, too?

Thanks!

Uploaded wpasupplicant 0.7.3-6ubuntu2.1 to precise-proposed; waiting to be reviewed by the SRU team.

Note: this fix is already in Quantal, but the source package is now called "wpa" rather than "wpasupplicant".

No longer needs to be tracked by the release team for Q (since it's Fix Released via the upload of wpa above); so I'm removing the rls-q-incoming tag.

Also unassigning Colin and marking the openssl tasks Incomplete; so far there isn't any indication that it needs extra work for openssl, and according to the reports here the wpa package patch was sufficient to fix issues.

Sadly, I still seem to be hitting this issue under quantal. Downgrading openssl libraries to 1.0.0e-2 (as in an earlier comment) resolved the problem. So I think marking this "Fix Released" for wpa may be premature.

Oh, and a co-worker is still hitting the problem with the version recently released to precise-proposed.

I'm wondering if, as rmcd suggests, we're dealing with two separate "bugs" (buggy implementations of WPA access points) here. On one hand, the patch du jour that disables TLS session tickets seems to fix the problem I've been having authenticating to certain Aruba access points. On the other hand, I'm wondering if Diane Trout's patch for disabling the TLS hearbeat extension is necessary for some other access points. Can anyone with access to an Aruba network who is actually using precise or quantal confirm that the packages currently in the repos fix the former case?

I have a question

This is not a forum for Android but i have android 4.1 and i cannot connect to wpa either. It could be the same problem?

Yes the same problem exists on android and it is basiclly the same bug. Here is the tracking for that

http://code.google.com/p/android/issues/detail?id=34212

Keep in mind that even once a fix is released in android it will still be necessary for your device maker to make their own patch.

Hi Benjamin,

I am using dell xps 13 with precise and my company is using Aruba AP, which I am not able to connect to it through WPA2 enterprise.

And I don't see libssl1.0.0_1.0.0e-2ubuntu4 in "synaptic package manager" anymore. So I am running libssl1.0.0_1.0.1-4ubuntu5.5.

I am using wpagui and wpasupplicant "0.7.3-6ubuntu3.gnutls1".

Please let me know if there is anything I can try to test.

Thanks,
Neo

This issue has gotten the attention of our network folks because of the similar Android Jelly Bean problem. Would it help for affected folks to provide more details about their network configurations? In addition to using Aruba networks, we have a "steel-belted Radius" authentication server. That vendor is apparently patching to address the Jelly Bean issue, but it's not clear that the Jelly Bean patch solves the connection problem for Android in our environment.

I had a mixed experience testing Ubuntu connections (with m-trudel's wpa-supplicant) against the patched radius server.

I verified Mathieu's SRU is working very well with a clean precise installation.
I could connect to WPA/WPA2 enterprise network, with a TPLink TL-WR941ND access point.

It's quite possible that there are still existing issues and that the fix in -proposed does not fix the problem for everone. However, due to the nature of the problem, we will be pushing out the fix in -proposed anyway, since it fixes the problem for a good number of users. In fact, it fixes the problem for the only setup that we were able to reproduce with here in Canonical. Because of the way launchpad works, we unfortunatly have a 1:1 mapping of bugs to problems and there is no way to have this existing bug represent anything other than fixing it by disabling session ticket.

If you are still experiencing problems. Please open a new bug _and_ include a packet dump. Also, be aware that our fix only disables session tickets. Another new feature worth disabling is renegotation as show in the following patch. Also of interest is a packet dump with a downgraded and working openssl. Currently the upstream wpa has not addressed this issue, they have explicitly stated the fix we use can not be applied to their hostap.git repository.

Because downgrading openssl seems to fix the problem, this is evidence that this is an openssl problem and not a wpasupplicant problem. Additionally, it is may be caused by misbehaving or non-compliant eap servers, since many eap servers work with the new wpasupplicant/openssl combo.

http://w1.fi/bugz/attachment.cgi?id=235&action=diff

Err, this is *not* in precise-proposed yet as far as I can tell. Shouldn't be marked as Fix Committed until then.

Jeremy, what kind of settings in wpa, if any, make the connection successful for you?

Hello rmcd, or anyone else affected,

Accepted into precise-proposed. The package will build now and be available in a few hours in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Unfortunately, the fix does not work for me. First, to be sure I'm using the correct version, 'dpkg -l | grep wpa' gives this:

ii wpagui 0.7.3-6ubuntu2.1 graphical user interface for wpa_supplicant
ii wpasupplicant 0.7.3-6ubuntu2.1 client support for WPA and WPA2 (IEEE 802.11i)

The first time I rebooted after installing from proposed, connection was successful. Every subsequent attempt failed, whether after resuming from a suspend or after a reboot. I get into an endless loop of password requests. Here is a log extract for the last attempt:

Oct 8 09:49:32 foo NetworkManager[987]: get_secret_flags: assertion `is_secret_prop (setting, secret_name, error)' failed
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Oct 8 09:49:32 foo NetworkManager[987]: <info> (wlan0): device state change: need-auth -> prepare (reason 'none') [60 40 0]
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Oct 8 09:49:32 foo NetworkManager[987]: <info> (wlan0): device state change: prepare -> config (reason 'none') [40 50 0]
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0/wireless): connection 'Northwestern' has security, and secrets exist. No new secrets needed.
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'ssid' value 'Northwestern'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'scan_ssid' value '1'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'key_mgmt' value 'WPA-EAP'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'password' value '<omitted>'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'eap' value 'PEAP'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'fragment_size' value '1300'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'phase2' value 'auth=MSCHAPV2'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'identity' value 'xyz'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: added 'bgscan' value 'simple:30:-45:300'
Oct 8 09:49:32 foo NetworkManager[987]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Oct 8 09:49:32 foo NetworkManager[987]: <info> Config: set interface ap_scan to 1
Oct 8 09:49:32 foo NetworkManager[987]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Oct 8 09:49:35 foo wpa_supplicant[1252]: Trying to authenticate with d8:c7:aa:bb:cc:dd (SSID='Northwestern' freq=2412 MHz)
Oct 8 09:49:35 foo kernel: [ 81.192887] wlan0: direct probe to d8:c7:aa:bb:cc:dd (try 1/3)
Oct 8 09:49:35 foo NetworkManager[987]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Oct 8 09:49:35 foo ker...

rmcd,

Are you sure that the configuration is correct in NetworkManager, and that the device is actually allowed to connect?

This works properly for other people, it would be nice to know exactly what is missing here if anything.

This is all the more important since "status 17" is "WLAN_STATUS_AP_UNABLE_TO_HANDLE_NEW_STA" which can mean a number of things, including "you seem to still be connected because your original session didn't time out yet, so I can't let you in twice", etc. This absolutely needs more testing before marking as failed.

Actually, 802.11-2007 defines status 17 as "Association denied because AP is unable to handle additional associated STAs" -- The API might be overloaded.

I tried the updated wpa program and I still can't access my work wireless network.

I am using Dell XPS 13 and my company is using Aruba AP.

I saw this in the dmesg:

2985 [130380.278223] wlan0: Wrong control channel in association response: configured center-freq: 5200 hti-cfreq: 5805 hti->control_chan: 161 band: 1. Disabling HT.
2986 [130381.803188] cfg80211: All devices are disconnected, going to restore regulatory settings
2987 [130381.803203] cfg80211: Restoring regulatory settings
2988 [130381.803213] cfg80211: Calling CRDA to update world regulatory domain
2989 [130381.812512] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
2990 [130381.812525] cfg80211: World regulatory domain updated:
2991 [130381.812530] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
2992 [130381.812540] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2993 [130381.812549] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
2994 [130381.812556] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
2995 [130381.812564] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2996 [130381.812571] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
2997 [130392.758524] wlan0: authenticate with d8:c7:c8:a4:ab:58 (try 1)
2998 [130392.759447] wlan0: authenticated
2999 [130392.759814] wlan0: associate with d8:c7:c8:a4:ab:58 (try 1)
3000 [130392.763081] wlan0: RX ReassocResp from d8:c7:c8:a4:ab:58 (capab=0x411 status=0 aid=12)
3001 [130392.763087] wlan0: associated
3002 [130392.763926] wlan0: Wrong control channel in association response: configured center-freq: 5200 hti-cfreq: 5805 hti->control_chan: 161 band: 1. Disabling HT.
3003 [130393.811006] cfg80211: All devices are disconnected, going to restore regulatory settings
3004 [130393.811022] cfg80211: Restoring regulatory settings
3005 [130393.811031] cfg80211: Calling CRDA to update world regulatory domain
3006 [130393.818827] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
3007 [130393.818840] cfg80211: World regulatory domain updated:

Mathieu,

First, sorry if I was premature in changing the tag, I thought I was acting as instructed.

I definitely do have permission to access the resource, and my android phone has no problem connecting. My computer did connect when I first rebooted, so I presume that serves as a test about settings. I didn't change the settings afterwards and it never connected again. I am in touch with our networking people. They are aware of the issue, but there are not many linux users and I am not knowledgeable about networking so I need assistance in asking them for help. Anything you can suggest?

What I plan to do when I have time is to install the proposed software on my bootable USB version of 12.04 and try that. I am open to other suggestions.

Hi,

I saw a lot of people still having the connection issues after applying this updates. I don't know if this is caused by a combination of using Dell XPS 13 + Aruba AP.

I have filed a bug 1019081 to track this issue, so please speak up there if you are seeing the same problem. I assume this is causing the failed connection:

"wlan0: Wrong control channel in association response: configured center-freq: 5200 hti-cfreq: 5805 hti->control_chan: 161 band: 1. Disabling HT."

Updating to mainline kernel "http://kernel.ubuntu.com/~kernel-ppa/mainline/daily/current/linux-headers-3.6.0-999-generic_3.6.0-999.201210080405_amd64.deb", I am able to connect to my AP through WPA2 Enterprise.

Thanks,
Neo

rmcd: the tag change was fine, but this bug is special in that it affects others (people using Aruba) and seems to fix the issue properly.

I suggest asking them to check authentication logs to see what the AP or authentication server wrote when you tried to connect and did you first successful connection, then what it wrote for the following unsuccessful conenctions. It's going to be a huge hint towards what is broken there.

Neo; indeed, the "Wrong control channel" error message is a kernel issue.

The bug is not fixed on my network (KULeuven/Eduroam)
Dmesg log: (grepped for wlan0)

[ 37.885705] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 103.898976] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 182.706388] wlan0: authenticate with 00:26:99:99:93:cd (try 1)
[ 182.709876] wlan0: authenticated
[ 182.710586] wlan0: associate with 00:26:99:99:93:cd (try 1)
[ 182.718540] wlan0: RX AssocResp from 00:26:99:99:93:cd (capab=0x11 status=0 aid=8)
[ 182.718549] wlan0: associated
[ 182.724260] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 236.004976] wlan0: deauthenticating from 00:26:99:99:93:cd by local choice (reason=3)
[ 5155.412467] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 5162.798052] wlan0: authenticate with 00:3a:98:c1:28:c2 (try 1)
[ 5162.800314] wlan0: authenticated
[ 5163.016468] wlan0: associate with 00:3a:98:c1:28:c2 (try 1)
[ 5163.021561] wlan0: RX AssocResp from 00:3a:98:c1:28:c2 (capab=0x411 status=0 aid=71)
[ 5163.021567] wlan0: associated
[ 5163.025957] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 5177.196392] wlan0: disassociating from 00:3a:98:c1:28:c2 by local choice (reason=3)
[ 5177.214274] wlan0: deauthenticating from 00:3a:98:c1:28:c2 by local choice (reason=3)
[ 5180.487626] wlan0: authenticate with 00:3a:98:c1:28:c2 (try 1)
[ 5180.492060] wlan0: authenticated
[ 5180.492382] wlan0: associate with 00:3a:98:c1:28:c2 (try 1)
[ 5180.497998] wlan0: RX ReassocResp from 00:3a:98:c1:28:c2 (capab=0x11 status=0 aid=71)
[ 5180.498004] wlan0: associated
[ 5182.724740] wlan0: disassociating from 00:3a:98:c1:28:c2 by local choice (reason=3)
[ 5182.749047] wlan0: deauthenticating from 00:3a:98:c1:28:c2 by local choice (reason=3)
[ 5186.024820] wlan0: authenticate with 00:26:99:99:93:c2 (try 1)
[ 5186.027693] wlan0: authenticated
[ 5186.048651] wlan0: associate with 00:26:99:99:93:c2 (try 1)
[ 5186.052456] wlan0: RX ReassocResp from 00:26:99:99:93:c2 (capab=0x411 status=0 aid=154)
[ 5186.052462] wlan0: associated
[ 5188.215355] wlan0: disassociating from 00:26:99:99:93:c2 by local choice (reason=3)
[ 5188.252204] wlan0: deauthenticating from 00:26:99:99:93:c2 by local choice (reason=3)
[ 5191.520497] wlan0: authenticate with 00:26:99:99:93:c2 (try 1)
[ 5191.525983] wlan0: authenticated
[ 5191.526382] wlan0: associate with 00:26:99:99:93:c2 (try 1)
[ 5191.533362] wlan0: RX ReassocResp from 00:26:99:99:93:c2 (capab=0x411 status=0 aid=154)
[ 5191.533368] wlan0: associated
[ 5193.732081] wlan0: disassociating from 00:26:99:99:93:c2 by local choice (reason=3)
[ 5193.750543] wlan0: deauthenticating from 00:26:99:99:93:c2 by local choice (reason=3)
[ 5197.021400] wlan0: direct probe to 00:3a:98:d5:ac:62 (try 1/3)
[ 5197.220048] wlan0: direct probe to 00:3a:98:d5:ac:62 (try 2/3)
[ 5197.420047] wlan0: direct probe to 00:3a:98:d5:ac:62 (try 3/3)
[ 5197.620040] wlan0: direct probe to 00:3a:98:d5:ac:62 timed out
[ 5205.856240] wlan0: direct probe to 00:3a:98:c1:28:cd (try 1/3)
[ 5205.857324] wlan0: direct probe responded
[ 5205.872054] wlan0: authenticate with 00:3a:98:c1:28:cd (try 1)
[ 5205.873432] wlan0: authenticated
[ 5205.873714] wlan0: associate with 00:3a:98:c1:28:cd (try 1)
[ 5205.878299] wlan0: RX Reasso...

At another location Eduroam works just fine. (BTW: I rebooted my laptop)

I m also at Northwestern like rmcd but the package in precise-proposed works fine for me. The proble was first resolved for me in the package in PPA https://launchpad.net/~mathieu-tl/+archive/sru-staging ?

But I switched to the one in proposed to see if there was an issue and I can't find one. Maybe rmcd's problem is something different?

When switching versions, are you guys making sure to reboot, or at
least kill the wpa_supplicant process?

If you're not, you're still testing the version from before you
upgraded, not the new one.

I rebooted after installing the package from proposed and after that I tried disconnecting and reconnecting a few times to test things and it all worked.

@nickurak: Yes, I reboot when I switch versions.

I can confirm the proposed fix works for me accessing Wifi with Enterprise security and TTL/PAP authentication.

@gllyons the proposed fix also worked for me at Northwestern.

The precise-proposed fix worked for me today at Durham University, UK. The uni uses WPA2 Enterprise with AES. Thanks to everyone who worked on the fix.

Here in UCSD. No success. Can anyone tell me what versions of stuff you are using? I am using:
wpasupplicant : 0.7.3-6ubuntu2.1
libssl1.0.0 : 1.0.1-4ubuntu5.5
openssl : 1.0.1-4ubuntu5.5

my kernel is 3.2.0-31-generic
Thanks!

marking verification-done based on comment #125

For people still having problems (that had problems prior to this version), please file a new bug referencing this one. Regressions from the released version with this update should be reported here.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package wpasupplicant - 0.7.3-6ubuntu2.1

---------------
wpasupplicant (0.7.3-6ubuntu2.1) precise-proposed; urgency=low

  * debian/patches/session-ticket.patch: disable the TLS Session Ticket
    extension to fix auth with 802.1x PEAP on some hardware. (LP: #969343)
 -- Mathieu Trudel-Lapierre <email address hidden> Mon, 17 Sep 2012 17:08:22 -0400

Fix only alleviated the situation for me. Went from no connectivity to frequent disconnects. Upgrading to kernel 3.5.0-030500-generic finally ended months of misery :-)

My enthusiasm for reporting the problem fixed (#125) was premature: the connection only worked twice, it is now only able to connect approximately once in every five attempts. The problem only persists with the network using WPA Enterprise with AES encryption, a separate network that uses WPA Enterprise with TKIP encryption works perfectly (so far). I shall look at raising another bug specifically on the AES encryption issue.

I have an ignorant question: There is no AES choice in the configuration dialog for WPA2, so which of the encryption methods are AES? (Is PEAP the same as AES?)

Another question: My android (ICS) phone connects successfully to our wpa2 network using peap, but it automatically configured "none" for phase 2 authentication. None is not an option for 12.04 and I am selecting MSChap2. Should there be a "none" option?

I wonder this isn't fixed yet. There are many users waitin for a fix, especially students and profs, because many of them are using the "eduroam" network (mentioned some times before).

When using eduroam wifi after a while my notebook stops working like expected: I'm unable to suspend (kernel panic) and the network connection is getting slower and slower till it stops working. The whole system crashes, so it's very dangerous to connect to such a network.

I attached a config screenshot....maybe it helps...

Felix, this bug *has* been fixed in Ubuntu 12.04 (Precise Pangolin) and later. From your comment, it sounds like you are describing an unrelated wifi bug. This bug prevented users from connecting to certain WPA2 Enterprise networks. The bug in your comment allows you to connect to a WPA2 Enterprise network but, some time later, causes a kernel panic. This is almost certainly a kernel/driver issue and *not* a bug in wpasupplicant or openssl. If your bug hasn't already been reported, I suggest opening a new bug and providing the brand/model of your wifi card, a kernel stack trace, and the output of dmesg, if possible.

@felixhaller: I share your frustration. I have what seems to be yet a different version of the bug, where in 12.04 I remain unable to connect to WPA2 Enterprise networks.

The fix for me was upgrading to 12.10. Now I can connect reliably and maintain the connection. I realize this may not be feasible for you. However, you may want to try a live CD and see if you can connect with 12.10. If 12.10 works for you and 12.04 does not, that should narrow down the possible causes of the problem.

I already use 12.10. I can connect to all wifi networks, there are only problems when connecting to eduroam network (wpa2 enterprise). My notebook is working just fine with the other networks (eg. my private one --> WPA2 personal).

I think I will open a new bug...thanks for all the information.

The user todaioan seems to be vandalizing a lot of bugs. I'm reverting his change.

I am experiencing this issue on ubuntu 12.10. I am connecting to a an eduroam wireless network with WPA2 enterprise encryption and the connection fails after a few minutes. Sometimes it does not connect at all. Most of the times one of the following work arounds works but the effect is only temporary until the connection is lost again:

 * Toggle the RF Killswitch
 * Suspend and wake up again
 * killall nm-applet && nm-applet

If I can contribute anything that would help to fix this issue, please let me know.

For what it's worth, I'm having this in an up-to-date 12.04 too. Wireless works flawlessly, except when connecting to an eduroam network, in which case it times out with this repeated in the syslog:

Apr 17 12:10:49 X kernel: [ 1987.661492] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin
Apr 17 12:10:50 X wpa_supplicant[1652]: Trying to authenticate with [AP:MAC:ADDR] (SSID='eduroam' freq=2412 MHz)
Apr 17 12:10:50 X kernel: [ 1988.874687] wlan0: direct probe to [AP:MAC:ADDR] (try 1/3)
Apr 17 12:10:50 X kernel: [ 1989.074082] wlan0: direct probe to [AP:MAC:ADDR] (try 2/3)
Apr 17 12:10:51 X kernel: [ 1989.274142] wlan0: direct probe to [AP:MAC:ADDR] (try 3/3)
Apr 17 12:10:51 X kernel: [ 1989.474110] wlan0: direct probe to [AP:MAC:ADDR] timed out
Apr 17 12:10:51 X kernel: [ 1989.577031] rtl8192c_common: Loading firmware file rtlwifi/rtl8192cfw.bin

I'm not sure how to interpret the history/status of this bug - is it still alive? Please let me know if I this belongs somewhere else, or if there's any more info I can provide.

We just implemented a lot Aruba (ap-105) access points and I (we) also experience this problem (as described @Impact) . While searching the www I couldn't really pinpoint what I could do as a work-around. I myself use 12.04, but the problem also exists on 13.04. I have a Thinkpad T410s. With the stock kernel (and up-to-date system) I wasn't able to connect to our wireless network, so I decided to do an install of a mainline kernel (v3.4-precise). After rebooting I was able to connect without any troubles.

Do not know if it's (still) relevant but if it is I want to provide you with any information possible to help with a solution

I'm still having this problem. I've had it now on several different computers, including now my Lenovo X121e.

For a while, I could login to WPA2-Enterprise wifi, but now I can't: not eduroam, or any other.

I should add, I'm using Xubuntu 12.10

While using ubuntu 12.10 (wpasupplicant 1.0-2ubuntu5 and openssl 1.0.1c-3ubuntu2) I can login to my company's wireless lan.

But which packages for 13.04 will have that fix which came with 1.0-2ubuntu5.

Finaly found that deleting the WLANs file in /etc/NetworkManager/system-connections/ solved the problem. Also http://askubuntu.com/questions/285234/cannot-connect-to-wpa2-wpa-enterprise-peap-and-mschap?answertab=votes#tab-top gave the right hint.