802.1x security in 13.04 not working

Bug #1173152 reported by Marko Hrastovec
126
This bug affects 24 people
Affects Status Importance Assigned to Milestone
network-manager (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I installed a fresh 13.04 Ubuntu 64bit today and 802.1x security is not working any more. Yesterday I had 12.10 and it worked on the same computer.

My settings are:
Authentication: Protected EAP (PEAP)
Anonymous identity:
Certificate: none
PEAP version: Automatic
Inner authentication: MSCHAPv2

Tags: bot-comment
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1173152/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
affects: ubuntu → network-manager (Ubuntu)
Revision history for this message
Fernando (fcuencamargalef) wrote :

Me too. Yesterday I upgraded from 12.10 to 13.04, and my Ethernet connection with 802.1x fails to connect. It always asks for the user and password, even the user and password is setted in the configuration.

Thanks for all.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Zisu Andrei (matzipan) wrote :

Can we help in any way to debug this?

Revision history for this message
Marko Hrastovec (marko-hrastovec) wrote :

Yes, you can help. I don't know what to do get some debugging info.

Revision history for this message
Fernando (fcuencamargalef) wrote :

Yes, If I can help to provide debugging info, I will be pleased to do it.

For me is very important this bug. The corporative network in our company needs 802.1x ethernet to work, so I have no network at work with my new Ubuntu.

Revision history for this message
Daniel Ferradal (dferradal) wrote :

yesterday I had recently upgraded 12.10 to 13.04 32 bit and I had it working. Although I decided to move to a fresh 64bit install of 13.04.

After the fresh install of 13.04 64 bit and I am suffering the same problem and network manager indicator ends up crashing when it tries to connect.

Revision history for this message
Daniel Ferradal (dferradal) wrote :

Only possible workaround. Configure wpa_supplicant manually.

For those who need:

/etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=2
ap_scan=0

network={
       key_mgmt=IEEE8021X
       eap=PEAP
       phase2="auth=MSCHAPV2"
       identity="YOURUSER"
       password="YOURPASSWORD"
}

###########

/etc/network/interfaces

# LO
auto lo
iface lo inet loopback

# ETH0
auto eth0
iface eth0 inet dhcp
wpa-driver wired
wpa-conf /etc/wpa_supplicant.conf

##############

Revision history for this message
Fernando (fcuencamargalef) wrote :

I can't get working this workaround, but I'm not very familiar with this kind of configuration, and it may be my fault.

Revision history for this message
Andre (avdschyff) wrote :

I am experiencing the same issue after installing 13.04, and also could not get the workaround working. I continually get prompted for the password, and can confirm this was working in 12.10. Unsure what debug logging would be useful, but here is the error in my syslog:

May 15 10:04:29 andre-pc NetworkManager[1044]: <info> (eth1): supplicant interface state: associated -> disconnected
May 15 10:04:29 andre-pc NetworkManager[1044]: <info> (eth1): supplicant interface state: disconnected -> scanning
May 15 10:04:31 andre-pc wpa_supplicant[1065]: eth1: Trying to associate with 00:1a:30:2f:28:d0 (SSID='wmobilea' freq=2412 MHz)
May 15 10:04:31 andre-pc NetworkManager[1044]: <info> (eth1): supplicant interface state: scanning -> associating
May 15 10:04:31 andre-pc wpa_supplicant[1065]: eth1: CTRL-EVENT-ASSOC-REJECT status_code=16
May 15 10:04:32 andre-pc NetworkManager[1044]: <warn> Activation (eth1/wireless): association took too long.
May 15 10:04:32 andre-pc NetworkManager[1044]: <info> (eth1): device state change: config -> need-auth (reason 'none') [50 60 0]
May 15 10:04:32 andre-pc NetworkManager[1044]: <warn> Activation (eth1/wireless): asking for new secrets
May 15 10:04:32 andre-pc NetworkManager[1044]: <info> (eth1): supplicant interface state: associating -> disconnected
May 15 10:04:32 andre-pc NetworkManager[1044]: <warn> Couldn't disconnect supplicant interface: This interface is not connected.
May 15 10:04:36 andre-pc NetworkManager[1044]: <warn> No agents were available for this request.
May 15 10:04:36 andre-pc NetworkManager[1044]: <info> (eth1): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
May 15 10:04:36 andre-pc NetworkManager[1044]: <info> Marking connection 'wmobilea' invalid.
May 15 10:04:36 andre-pc NetworkManager[1044]: <warn> Activation (eth1) failed for connection 'wmobilea'
May 15 10:04:36 andre-pc NetworkManager[1044]: <info> (eth1): device state change: failed -> disconnected (reason 'none') [120 30 0]
May 15 10:04:36 andre-pc NetworkManager[1044]: <info> (eth1): deactivating device (reason 'none') [0]

Revision history for this message
Lorenzo M (lorenzom) wrote :

I've got this problem too and the workaround didn't work for me

Revision history for this message
Sébastien Cevey (p-seb) wrote :

It turns out removing the line "system-ca-certs=true" from the /etc/NetworkManager/system-connections/<network id> file seems to have allowed me to connect to the network. The nm-applet stills asks me for my password a few times, I don't know if it is related, but at least it does eventually connect.

Revision history for this message
Marko Hrastovec (marko-hrastovec) wrote :

Sebastien, great!!! This workaround works for me.

Revision history for this message
Fernando (fcuencamargalef) wrote :

Thanks a lot Sébatien!!!

This workaround also worked for me. Now I can use wired network at work.

Revision history for this message
Fernando (fcuencamargalef) wrote :

One more thing, I also have the same problem for Wifi connections. And the same workaround solved the issue.

Revision history for this message
Motoshi Hara (h-motoshi) wrote :

Excellent! Sébatien!!
This workaround also worked in my environment(ethernet and wifi).
I hope that this bug is revised as soon as possible.

Revision history for this message
Felix Haller (felixhaller) wrote :

Workarround worked for me too:

on WIFI with TTLS/PAP

thanks!

Revision history for this message
Lorenzo M (lorenzom) wrote :

Workaround work very well!! Thanks a lot!!!

Revision history for this message
Niraj Bhawnani (niraj-f) wrote :

This is a really embarassing bug especially for us enterprise users.

Sébatien's workaround works but you're then required to enter your password each time you connect to the network.

Adding this line to etc/NetworkManager/system-connections/<network id> fixed that for me:
password=<password>

So the workaround is to remove this line:
system-ca-certs=true
and add this line in its place:
password=<password>

Though storing your password in plain text like that is not great :(

Revision history for this message
Niraj Bhawnani (niraj-f) wrote :

I should also point out that I needed to restart for the changes to take effect.

Revision history for this message
Guilherme Peraçoli (guilherme-peracoli) wrote :

Thank's Sébastien! It worked also here!

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.