intermittent WPA connection

[Manuel López-Ibáñez]

Binary package hint: knetworkmanager

Knetworkmanager loses connectivity to a WPA wireless network intermittently. If run on console, every time there is a disconnection, the following message is printed:

** (process:4858): CRITICAL **: nmu_security_deserialize_wpa_psk: assertion `dbus_message_iter_get_arg_type (iter) == DBUS_TYPE_STRING' failed
knetworkmanager: WARNING: [static void NetworkManagerInfoDBus::updateNetworkInfo(DBusMessage*)] Failed to deserialize security. Probably we_ciphers are different.

Also, in dmesg, the following messages are printed:

[17240903.476000] ADDRCONF(NETDEV_UP): eth1: link is not ready
[17240906.116000] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[17240911.264000] TKIP: replay detected: STA=00:14:7c:b1:e5:9c previous TSC 000000000000 received TSC 000000000000
[17240916.616000] eth1: no IPv6 routers present
[17240930.076000] eth1: no IPv6 routers present

[sk0rp10 (matteo-andreozzi)]

I found the problem : Knetwork managers stores in Kwallet the WPA password with the character : " at the beginning and at the end of the Key .

If u remove the "s in Kwallet all works well.

I think that patching this bug won't be so difficult... :-)

[Manuel López-Ibáñez (manuellopezibanez)]

Humm, I don't think that has anything to do with my problem. I could provide the output of Knetworkmanager and wpa_supplicant in /var/log/daemon.log. Is there any confidential information printed on that log?

Anyway, every time the link drops I see this in daemon.log:

eth1: link timed out.
SWITCH: found better connection 'eth1/3Com' than current connection 'eth1/3Com'. same_ssid=1, have_link=0
Will activate connection 'eth1/3Com'.
Device eth1 activation scheduled...
Deactivating device eth1.
 localhost dhclient: There is already a pid file /var/run/dhclient.eth1.pid with pid 22001
 localhost dhclient: killed old client process, removed PID file
 localhost dhclient: DHCPRELEASE on eth1 to 192.168.1.1 port 67
Activation (eth1) started...
Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Activation (eth1) Stage 1 of 5 (Device Prepare) complete.
Activation (eth1) Stage 2 of 5 (Device Configure) starting...
Activation (eth1/wireless): access point '3Com' is encrypted, but NO valid key exists. New key needed.
Activation (eth1) New wireless user key requested for network '3Com'.
Activation (eth1) Stage 2 of 5 (Device Configure) complete.
DHCP daemon state is now 14 (normal exit) for interface eth1
DHCP daemon state is now 11 (unknown) for interface eth1
DHCP daemon state is now 14 (normal exit) for interface eth1
Activation (eth1) New wireless user key for network '3Com' received.
Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled...
Activation (eth1) Stage 1 of 5 (Device Prepare) started...
Activation (eth1) Stage 2 of 5 (Device Configure) scheduled...
Activation (eth1) Stage 1 of 5 (Device Prepare) complete.

It continues for a while connecting until it finally connects. But there is only one access point, it should not switch to a better connection. Everybody else is running Windows and they don't get disconnected.

[Fionn (fbe)]

This is most probably a bug in network-manager itself. Please see Bug #64173 and complain there to get it fixed!

Thank you!

[Rich Johnson (nixternal)]

Confirming. I noticed this issue as well recently while connected to a WPA network. Plus you have an upstream bug that confirms this.

[Christopher B. Wright (wrightc)]

I didn't experience this problem until this morning, after an update. Now I have wireless access for a brief period of time after initial boot and login, but after it times out I can't re-establish the connection. Knetworkmanager can see the wireless connection, but it times out when trying to connect, eventually asking for my password, which it then rejects. (Gutsy Tribe 5)

[Manuel López-Ibáñez (manuellopezibanez)]

This still happens in Feisty with a different network and a different wireless card. The most annoying is that sometimes NM gives up and asks for the password, so if I am not in front of the computer, all connections (and downloads) are stopped indefinitely.

[Manuel López-Ibáñez (manuellopezibanez)]

New strange messages are:

Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: Found user 'avahi-autoipd' (UID 103) and group 'avahi-autoipd' (GID 109).
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: Successfully called chroot().
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: Successfully dropped root privileges.
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: fopen() failed: Permission denied
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: State transition START-0 -> START-0
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: Starting with address 169.*.*.*
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: State transition START-0 -> WAITING_PROBE-0
Nov 21 02:21:10 localhost avahi-autoipd(eth1)[9772]: sleeping 472ms
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: State transition WAITING_PROBE-0 -> PROBING-0
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: sending...
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: sleeping 1528ms
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: sleeping 1059ms
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: sleeping 1045ms
Nov 21 02:21:11 localhost avahi-autoipd(eth1)[9772]: SIOCSIFFLAGS failed: Permission denied

[Manuel López-Ibáñez (manuellopezibanez)]

Still happens with a different wireless network. A difference is that now there is a continuous output in /var/log/daemon.log, so it is even harder to understand what is going on. Another difference is that reconnection happens every 10 seconds or so.

[Manuel López-Ibáñez (manuellopezibanez)]

I finally found out how to use wpa_supplicant by itself and disable NetworkManager.

In /etc/network/interfaces:

iface eth1 inet dhcp
wpa-driver wext
wpa-conf /etc/wpa_supplicant.conf

In /etc/wpa_supplicant.conf

ctrl_interface=/var/run/wpa_supplicant
ap_scan=2
# Only WPA-PSK is used. Any valid cipher combination is accepted.
network={
 ssid="myred"
 proto=WPA
 key_mgmt=WPA-PSK
 pairwise=TKIP
 group=TKIP WEP104 WEP40
 psk="mypassword"
 priority=2
}

Si añado CCMP como en el ejemplo en README.wpa_supplicant.conf.gz , entonces no funciona.

Now I don't get disconnections, so this is an issue in NetworkManager/Knetworkmanager.

[Manuel López-Ibáñez (manuellopezibanez)]

"Si añado CCMP como en el ejemplo en README.wpa_supplicant.conf.gz , entonces no funciona."

means

"If I add CCMP (to pairwise and group) like in the example found in README.wpa_supplicant.conf.gz, then it doesn't work."

[Yuriy Kozlov (yuriy-kozlov)]

manu,
Are you still experiencing this problem in Gutsy or Hardy?
What wireless card and driver are you using?
Have you tried with an unencrypted connection?
Have you tried disabling ipv6?
Have you looked at bug 64173 to see if you are experiencing the same behavior?

[Loye Young (loyeyoung)]

I have the same problem, and I work around it in a similar manner.

avahi-autoipd, dhcdbd, and network-manager don't play well with wpa_supplicant. If I uninstall avahi-autoipd, dhcdbd, and network-manager and use instead network-config and wlassistant, I don't have problems.

The basic problem is that wpa_supplicant's architechture expects to works with ifupdown and dhclient, not dhcdbd and avahi. (See the first sentence of /usr/share/doc/wpasupplicant/README.Debian. ) The default install seems to work fine as long as you aren't using WPA encryption and you don't use static IP addresses.

Yet another reason for Bug 192258 to be fixed.