wicd returns "bad pass"

Bug #594676 reported by Mario natiello
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
wicd
New
Undecided
Unassigned

Bug Description

I attempt to connect to a network using WPA with TTLS/PAP.

This configuration is given to wicd on /etc/wicd/encryption/templates/eduroam-lu

name = EDUROAM-TTLS/PAP
require identity *Identity password *Password
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=0

network={
    ssid="eduroam"
    scan_ssid=1
    proto=WPA
    key_mgmt=WPA-EAP
    eap=TTLS
    <email address hidden>"
    identity="$_IDENTITY"
    password="$_PASSWORD"
    phase2="auth=PAP"
    ca_cert="MY_Certificate"
    ca_path="/etc/ssl/certs/"
    priority=2
}

wicd recognizes this configuration and subsequently it launches wpa_supplicant
wpa does not authenticate
wicd shows "bad password" and exits

Running wpa_supplicant "by hand" with exactly this configuration file (only that Identity, password and certificate are given explicitly)
works successfuly without problems.

Excerpt of wicd's log:

2010/06/15 09:48:53 :: iwconfig wlan0 mode managed
2010/06/15 09:48:53 :: Putting interface up...
2010/06/15 09:48:53 :: ifconfig wlan0 up
2010/06/15 09:48:54 :: iwconfig wlan0
2010/06/15 09:48:55 :: enctype is eduroam-lu
2010/06/15 09:48:55 :: Attempting to authenticate...
2010/06/15 09:48:55 :: ['wpa_supplicant', '-B', '-i', 'wlan0', '-c', '/var/lib/wicd/configurations/000b0e310d0c', '-D', 'wext']
2010/06/15 09:48:55 :: ['iwconfig', 'wlan0', 'essid', 'eduroam']
2010/06/15 09:48:55 :: iwconfig wlan0 channel 1
2010/06/15 09:48:55 :: iwconfig wlan0 ap 00:0B:0E:31:0D:0C
2010/06/15 09:48:55 :: WPA_CLI RESULT IS None
2010/06/15 09:48:55 :: connect result is Failed
2010/06/15 09:48:55 :: exiting connection thread
2010/06/15 09:48:55 :: Sending connection attempt result bad_pass

Something that seems strange is that the configuration file given to wpa_supplicant by wicd has only one line, instead of the
whole network information.

Using wicd 1.7.0 compiled for SUse 11.1 on a x86-64 computer

Thanks for any help,

M. Natiello

Revision history for this message
Mario natiello (mario-natiello) wrote :

I forgot another issue.
When trying to connect as above several times, each attempt generates a
wpa_supplicant process. Processes are not killed after failure and accumulate in the
process-list.

Revision history for this message
jhr (hauke.rahm) wrote :

I can partly confirm the issue here. I wasn't able to connect to eduroam, either, and tried debugging it. Turned out wpa_supplicant spent too much time for authentication. Changing MAX_TIME in wicd/wnettools.py (line 1323) to 70 made it possible to connect. Funnily, after changing it back, I wasn't able to reproduce it again. Maybe it's caching something about old connections, don't know.

Revision history for this message
Mario natiello (mario-natiello) wrote :

Unfortunately, changing MAX_TIME did not make any difference for me.
The problem remains:
wicd launchs wpa_supplicant in such a way that wpa fails to connect to network with "bad_pass"
running wpa_supplicant from the terminal as root with same configuration works smoothly.

Revision history for this message
David Moffatt (david-c-moffatt) wrote :

FYI,

I have been fighting something that sounds a lot like this bug. via google it looks like it is pretty common on ubuntu 9.04 (My rev). The consensus on the web is to downgrade to 1.6

I am able to connect manually (ie run wpa_supplicant with my own config file) and I am able to connect to my open network (which is from the same router). So it sounds like it might be an issue with what command is being fed to wpa_supplicant.

Anyway wanted to give you guys a heads up to see if you can boost the priority on the bug.

https://bugs.launchpad.net/ubuntu/+source/wicd/+bug/540070

http://ubuntuforums.org/showthread.php?t=1560502

Revision history for this message
Paul Abrahams (abrahams) wrote :

I too have encountered the "Bad Password" problem, which apparently was introduced in the transition from wicd 1.6 to wicd 1.7. I got around it by going back to networkmanager. There are a great many threads around on this subject and the bug has struck many people. It's particularly nasty because of the implication that the failure is the user's fault and the fact that every other aspect of the connection succeeds.

This bug badly needs to be fixed.

Revision history for this message
goink (dchomyn) wrote :

I have the same "bad passwwrd" reply using WPA with a preshared key on 1.7.0, as part of Ubuntu 10.10

I believe this may be a problem interaction between wicd and the way wpa_supllicant is passing the (preshared) key to the network authority (your router).

In my case, I have a Linksys WRT54GL running DD-WRT v24-sp2 (10/10/09) std - build 13064 OpenSource firmware, configured as an Access Point in Mixed mode (b/g)

I have no problem authinticating WPA Personal TKIP or AES from Windows or Mac OS X clients with a variety of wireless adapters (Linksys, D-Link, Lucent, Airport (Mac)).

Wth wicd 1.7.0 and wpasupplicant 0.6.10-2 (wext as wpa_supplicant driver selected in wicd by default) on Linux 2.6.35.-24-generic (Ubuntu) and a Lucent Orinoco Gold 802.11b wireless adapter I am able to connect initialy (one time) without the "bad password" error.

After the initial successful connection, reconnection is not possible (again, the "bad password" error) ***unless the wireless security settings on the router are re-applied. Once reapplied, a subsequent attempt to create a wireless connection from the Linux client will succeed without any changes having been mad on the client side.

The psk data being sent to the router (with respect to the Wireless security settings) is being cached in such a way the connection is initially possible but defeats subsequent attempts at connection when the same psk data is sent again? Or, perhaps, the passkey is cached/stored on the client side (after it is used to make the first connection) in such a way that it will be sent incorrectly upon subequent attempts at connection? Of course, I'm simply guessing, here ... it is by luck that I found the workaround to establish this connection.

BTW, FYI, I am unable to use the Gnome Network-Manager to establish any wireless connections at all.

Revision history for this message
Abdusamed Ahmed (sir508) wrote :

Facing the exactly the same issue, nm-applet works but wicd doesn't. The weird thing it was working fine a few hours ago but now it won't connect. It keeps on displaying the same message repetitively 'bad password' when the password is fine

on ubuntu 10.04.2 wicd latest ?

Revision history for this message
Thomas Menzel (brot-bernd) wrote :

Uninstall _all_ other network managers, e.g.
connman (Intel connection manager daemon)
network-manager

Revision history for this message
Some Dude (somedude88) wrote :

I got the bad_pass error on wicd 1.7.4 (bzr-r961) on Void Linux after I changed my wifi password.

It was working fine before. It couldn't connect yesterday after I changed my wifi password. It was giving me this below on terminal for wicd-gtk when connecting failed:

/usr/share/wicd/gtk/gui.py:583: Warning: Source ID 12039 was not found when attempting to remove it
  gobject.source_remove(self.update_cb)
ERROR:dbus.connection:Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/dbus/connection.py", line 232, in maybe_handle_message
    self._handler(*args, **kwargs)
  File "/usr/share/wicd/gtk/gui.py", line 281, in handle_connection_results
    error(self.window, language[results], block=False)
KeyError: dbus.String(u'bad_pass')

I tried wicd-curses, but still no luck. Tried forgetting ssid and entering password again in as many ways I can, but failed. With a lot of despair I went to sleep.

Today, kind of like 24 hours later it started working again. I haven't changed the config. It was like the same yesterday. But somehow it started connecting. I think I agree with @goink (dchomyn) here. Something is being cached and it was stopping me from connecting.

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.