Eduroam randomly disconnects

I can confirm that the bug is distribution-independent so there's probably a bug somewhere in upstream userland or in incorrect configuration by distributors.

I just downgraded the kernel to 2.6.24 found here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.24/
This kernel (2.6.24-24-generic) is also installed in Hardy and there, as already mentioned, the connection never drops.
But here in 9.10 after boot the connection works, then after some time the connection still drops and its imposible to reconnect.

My disconnection from the network takes place exactly 60 minutes after the connection has been established. I have no timeouts that I'm aware of. The connection doesn't drop but no host on the network is resolvable so the only thing left to do is to reconnect.

I have completely the same problem. After some time connection drops and i have to reconnect and this is becoming really annoying. And there is also another bug with it. After few connections i have to add CA certificate again, even if i showed location of CA hundred of times. Could someone solve this problems ASAP?

I can confirm that the bug also!!!

Since you report that the connection drops after exactly 60 minutes, this could be related to a failure in 802.1x reauthentication request from NAS (access point). I suspect a bug in wpa_supplicatnt.

Could everybody having problems clarify weather this happens on wired or wireless network or both.

The problem occurs when there is a request for re-authentication. The request is sent by switch over 802.1x IEEE Standard. Luka, this every 60min in your case. The same problem is also on Gentoo OS with wpa_supplicant v0.6.9.

Is there a workaround for this bug? Or is it fixed in newer wpa_supplicant releases?

I can confirm the problem on wired network. For wireless I need to do some testing.

My connection is wired. It happens on two computers with PCI or/and motherboard integrated LAN card.

My System log has some of these entries:

2009-11-11 21:32:07 r33d3m33r wpa_supplicant[18448] CTRL-EVENT-EAP-STARTED EAP authentication started
2009-11-11 21:32:07 r33d3m33r wpa_supplicant[18448] CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
2009-11-11 21:32:07 r33d3m33r wpa_supplicant[18448] OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)

I can confirm this on 9.10 for wired. With wireless - I've given up trying to connect at all due to the 802.1x requirements that Ubuntu can't seem to cope with.

Same symptoms as others, not sure exactly when it loses connectivity, but when it happens Ubuntu doesn't seem to realise. Everything shows up as connected but no traffic goes anywhere.

Hope this gets fixed

I can confirm this for 9.10 wireless. Works for a few seconds, then disconnects.

Me too.

I can confirm same problem like Luka Napotnik on Ubuntu 9.10, wpasupplicant (0.6.9-3ubuntu1), every 60 minutes is Eduroam disconnected and then I have to restart NetworkManager:

killall NetworkManager
NetworkManager&

Immediately after that connection is established again for next 60 minutes.

Does anybody know some solution for that problem, for example upgrade to new version of wpasupplicant, where can I get it? Or something else?

I experienced this (as per my earlier comment). It drove me nuts, so I did a little digging.

Wired connections were OK if I used "wpa_supplicant" via the terminal and added "fast_reauth=0" to my configuration file. Wireless worked if I used the Wicd network manager, but Wicd doesn't support WPA over wired connections. So I've arrived at a compromise between setting up my "/etc/network/intefaces" file as follows:
"# Ethernet interface
auto eth0
iface eth0 inet dhcp
wpa-driver wired
wpa-conf /etc/wpa_supplicant/wired.conf"

That handles wired connections. Wicd handles wireless flawlessly. I hope this helps somebody, but of course your mileage may very.

I experienced this (as per my earlier comment). It drove me nuts, so I did a little digging.

Wired connections were OK if I used "wpa_supplicant" via the terminal and added "fast_reauth=0" to my configuration file. Wireless worked if I used the Wicd network manager, but Wicd doesn't support WPA over wired connections. So I've arrived at a compromise between setting up my "/etc/network/intefaces" file as follows:
"# Ethernet interface
auto eth0
iface eth0 inet dhcp
wpa-driver wired
wpa-conf /etc/wpa_supplicant/wired.conf"

That handles wired connections. Wicd handles wireless flawlessly. I hope this helps somebody, but of course your mileage may vary.

I have found that the error (typically occurred in the rekeying process) might be caused by the usage of openSSL libraries to which the ubuntu wpasupplicant package is compiled.
Errors and reconnecting troubles with "eduroam" (WPA-TKIP-based) APs disappared when I have compiled wpasupplicant for usage GNU-TLS libraries (2.8.5 version) instead of openssl.

see config file:

# Select TLS implementation
# openssl = OpenSSL (default)
# gnutls = GnuTLS (needed for TLS/IA, see also CONFIG_GNUTLS_EXTRA)
# internal = Internal TLSv1 implementation (experimental)
# none = Empty template
CONFIG_TLS=gnutls
CONFIG_GNUTLS_EXTRA=y

Can you provide exact compile instructions so we can try this for our self?

I have tried rebuilding of the source package of wpasupplicant in ubuntu 8.10 interpid according this procedure:

As root (sudo su):

1. Prepare building environment for packages:
apt-get install devscripts
2. Cd into /usr/src
3. obtain source package of wpasupplicant:
apt-get source wpasupplicant
4. obtain building dependecies for wpasupplicant
apt-get build-dep wpasupplicant
5. install development files and libraries for GNU-TLS
apt-get install libgnutls-dev
6. cd cd /usr/src/wpasupplicant-0.6.4/
7. modify config file in ./debian/config/linux in the TLS section, it should be as follows:

# Select TLS implementation
# gnutls = GnuTLS (needed for TLS/IA, see also CONFIG_GNUTLS_EXTRA)
# internal = Internal TLSv1 implementation (experimental)
CONFIG_TLS=gnutls
CONFIG_GNUTLS_EXTRA=y

8. execute command "dch -i" and put some comments into the changelog
9. build the package:
dpkg-buildpackage -rfakeroot -uc -b
10. install packages via:
dpkg -i wpasupplicant_0.6.4-2ubuntu1_i386.deb wpagui_0.6.4-2ubuntu1_i386.deb

After restart of network-manager service, the nm-applet can connect to an eduroam AP and this error from /var/log/wpa_supplicant.log:

OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)

has disappeared and connection was stable for at least 4 h.

The bug affects me too, on EEE PC 1000HE running ubuntu karmic, on university of amsterdam's eduroam.

I tried following KILinux's instructions for compiling wpasupplicant (version 0.6.9 is included with karmic) against the GnuTLS library. Build & install succeeded. However, after a restart, the system fails to connect at all.

Now, after compiling against openssl and install, same behaviour as before.

Attached is the possibly relevant part of /var/log/syslog.

Timo

I also compiled wpa_supplicant following KILinux's instructions on Jaunty 8.10. Compile and install was succesful, I can see my recompiled version successfully installed in Synaptic, but connection doesn't work anymore when manually run:

$ sudo /sbin/wpa_supplicant -dd -f/home/user/log.txt -Dwired -ieth0 -c/etc/wpa_supplicant.conf

In log i get:

The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

and then this message repeats:

EAPOL: startWhen --> 0
EAPOL: heldWhile --> 0
EAPOL: disable timer tick
EAPOL: SUPP_PAE entering state CONNECTING
EAPOL: enable timer tick
EAPOL: SUPP_PAE entering state AUTHENTICATING
EAPOL: SUPP_BE entering state FAIL
EAPOL: SUPP_PAE entering state HELD
EAPOL: SUPP_BE entering state IDLE
EAPOL authentication completed unsuccessfully

Nothing is available, not even the default (how to correctly configure your network) Eduroam info page.

When run with sudo ifdown -a and sudo ifup -a it connects, but still doesn't have assigned correct IP address and Internet is unavailable - just the default (how to correctly configure your network) Eduroam info page comes up.

#22 - According attached log-file, it could be problem of certificate (invalid form or missing completely).
#23 - What is your eduroam security? I have tried my wpa_supplicant against eduroam with WPA1-enterprise, TKIP and PEAP-MSCHAPv2 autorization.

Nevertheless, you can try another my wpa_supplicant, which is newer version 0.7.1 with gnuTLS (link at rapidshare: http://rapidshare.com/files/363264216/wpa_supplicant.tar.bz2.html).

#23

<i>The Diffie-Hellman prime sent by the server is not acceptable (not long enough).</i>

This maybe a bug (or a high-security feature) of gnu-tls library, for details see:
http://lists.shmoo.com/pipermail/hostap/2008-November/018701.html,

and for a workaround you can try newer version of gnu-tls (in this location are packages for ubuntu-ftp.ubuntu.com/ubuntu/pool/main/g/gnutls26/) or manual hack of the source according this: http://lists.gnupg.org/pipermail/gnutls-dev/2003-September/000517.html.

I tried two methods of KILinux way. At first I compiled wpasupplicant from source code myself and then copy all mentioned files to proper location. The second method: download and exchange precompiled files by KILinux to my system. But in both cases without success, after reboot of my computer, nm-applet indicate the wireless device is not ready.

Probably it is not so easy, just to change old files with the new files. At least on my Ubuntu 9.10.

In this situation I even reinstall Ubuntu to new version 10.04 alpha 3, but the problem presists. Eduroam disconnects every 60 minutes.

I hope someone will find solution, because eduroam is quite important wireless network in our school.

For me, the bug was fixed by installing the drivers from ralink, available at:

http://www.ralinktech.com/support.php?s=2

(mine are RT2860PCI/mPCI/CB/PCIe(RT2760/RT2790/RT2860/RT2890, version 2.3.0.0 of 01/29/2010)

Install instructions for who needs them, for the rt2860:

 * unpack the files, say in ~/ralinktech
 * edit the file ~/ralinktech/Makefile, so that shortly after "ifeq ($(PLATFORM),PC)", it reads:

LINUX_SRC_MODULE = /lib/modules/$(shell uname -r)/kernel/drivers/staging/rt2860

 * open a terminal, and enter:

cd ~/ralinktech
make
sudo make install

* restart your computer

Before you start, make a backup of the file

/lib/modules/$(shell uname -r)/kernel/drivers/staging/rt2860/rt2860sta.ko

as it gets overwritten by make install.

You have to redo this everytime the kernel gets updated.

I will inspect the situation in the official stable release of ubuntu LTS (lucid) and I will inform about possible solution. Regardless your unsuccessful result, my self-compile instalation of wpa_supplicant 0.7.1 is working problemless. The problems may arise if you use private certificate to autentize in eduroam network, my situation is the usage of secured password-only autentization. Moreover the ubuntu distribution is going to the hell...

Ah, same problem here. With Lucid final and up to date. I don't usually connect to my Uni network, but I seem to remember this happening since at least Jaunty.

I found same problem with unexpected disconnect with EduRoam Univeristy of Opole in Poland. After several fails to get stable connection found solution that set fast_reauth=0 can solve problem.

I`m work on Slackware 2.6.28 with:
wpa_supplicant-0.6.10-i486-1
openssl-0.9.8n-i486-1
gnutls-2.8.6-i486-1

my wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=0

network={
ssid="eduroam"
bssid=[their currently working AccessPoint MAC address]
proto=WPA
key_mgmt=WPA-EAP
eap=PEAP
identity=[assigned login]
password=[assigned pass]
phase2="auth=MSCHAPV2"
}

When I`ve compiled wpa_supplicant 0.6.10 with TLS support like KILinux wrote in #19 and #21 reply during authentication process got error that:

tls_connection_handshake - gnutls_handshake failed -> The Diffie-Hellman prime sent by the server is not acceptable (not long enough).
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL

greetings for all Ubuntu users from Slackware user :)

dupe or related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/291760 ?

The fast_reauth=0 fixed the bug for me. I still get this in the logs:

wpa_supplicant[5631] OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)

But the connection doesn't drop anymore.

This above is true for one of the computers. The other can't even connect (look at comment #23) with anything above Ubuntu 8.04, but for this I blame badly configured network system in my dorm.

I have seen a problem which is very similar to this on an 802.11x wired network - the initial connection is made successfully but after some amount of time the machine is disconnected from the network and will fail to automatically reconnect. As the network is at a University which also runs Eduroam for its wireless connections it may be a similar issue to this. In my case, disabling fast_reauth appeared to sometimes help but did not solve the problem in all cases (it would still sometimes lose a connection and never establish it until manually restarted). Recompiling the wpa_supplicant package against GNUTLS (as suggested by KILinux) seems to solve the issue (at a minimum reconnection seem to be successful). This issue was seen and workaround successful in Ubuntu 10.04, Ubuntu 10.10 and Fedora 13 on multiple machines and laptops.

I had some problems building wpa_supplicant.
When the following command gets executed a segmentation fault occurs:

sed 's/^\([^#]\+=.*\|}\)/#\1/' < wpa_supplicant/wpa_supplicant.conf

To get rid of the segmentation fault I changed every occurrence of ssid="example" in wpa_supplicant/wpa_supplicant.conf to ssid="eksample"

Is this bug still happening in Natty?

Yes I have some disconnects on Natty and eduroam (without certificate).
I've not been paying close attention to the frequency of disconnects though. They are about once an hour..
(wpasupplicant version 0.7.3-0ubuntu1)

cheers.

also still having this problem in natty
i am connected for like 20 seconds after connected to eduroam in one of the major buildings of fu berlin, then it'll disconnnect.

wpa&wpa2 enterprise, saved eap (peap) and a .pem certificate (peap version: version 0, inner authentification: mschapv2) if that matters

no idea how to fix it.. im just without internet in the uni

My laptop (msi wind cx-600) is suffering from the same problem, running Ubuntu Natty 11.04 on the UvA (Universiteit van Amsterdam) eduroam network.
Any help would be greatly appreciated! Thanks.

Hi,

many of you above have mentioned disabling fast reauthentication in wpa_supplicant.conf as one possible / promising work-around solution. May I kindly ask you (above) to please post more verbose step-by-step instructions on how to disable fast reauth? Please post either here or here:

http://askubuntu.com/questions/47494/need-instructions-how-to-create-wpa-supplicant-conf-and-add-fast-reauth-0-to-it

Many thanks!

?

This isn't a hotline. Please allow more time for people to answer your question.

ok, I guess the problem is that no-one who mentioned fast reauth above is no longer subscribing to this bug report... tough luck !

The workaround proposed in #21 (switching to GnuTLS) works for me. I've had no more disconnections during over 6 hours of connection to the wireless "eduroam" network at TU Darmstadt.

Before switching from OpenSSL to GnuTLS, I was disconnected from eduroam after 10 to 20 minutes and could not reconnect until restarting network-manager.

(I'm using maverick on x86_64 with Intel WiFi Link 5100 handled by iwlagn)

Same problem here on lucid LTS. The workaround #21 does not work for me.

After a brief* test of Oneiric (and back again) I am wondering:

has anyone observed this annoying behaviour in Oneiric?

tp.

* I didn't get around to testing it at Uni / a enterprise WLAN ...

Hi,

Problem solved for me in Oneiric.

Regards

On 25-10-2011 10:47, thinkpad wrote:
> After a brief* test of Oneiric (and back again) I am wondering:
>
> has anyone observed this annoying behaviour in Oneiric?
>
> tp.
>
> * I didn't get around to testing it at Uni / a enterprise WLAN ...
>

I have seen this behaviour in Oneiric on an 802.11 wired network.

On Windows, the network connectivity instructions explicitly tell us to disable "Enable Fast Reconnect". The wpa_supplicant in Oneiric will not read a configuration file by default added using just -c. Further, it will not read a configuration file set on the command line using -c unless an interface is also set using -i. Even after all this was done, it went on to use fast_reauth anyway because it was a wired interface and it tried to communicate to the interface using wireless extensions. In the end the wpa_supplicant DBus service needed to be started with -ieth0 -Dwired -c <pathtoconf> and the configuration file specified fast_reauth=0. This really DID disable fast_reauth, working around whatever problem this particular network has...

I have the same problem. It connects and then after a while it disconnects.

In order to have it running again I have to turn off the wifi (kill switch)

Using 12.04 and kernel 3.4

Does anyone know if the tric mentioned in #21 helps for connections using PEAP too or only TLS? Another user from Berlin with connection stability problems.

I find that connecting only works if I set the network authentication to PEAP. Trying to connect with TTLS will consistently fail. In XUbuntu 12.10, I had to do nothing else to make it work other than using PEAP.

If it matters or helps at all, my eduroam network is the one at Hogeschool Utrecht in the Netherlands.

I have the same problem in 12.10 and I've had the problem since my university switched to this "marvelous" eduroam.

Although this bug hasn't seen much activity, I still experience it on 12.04 LTS.

- It first connects fine
- after 5min I loose internet connection
- then wifi drops
- reconnect is ony possible when I switch off/on wifi by hardware key

I think it is a global problem, but for what it's worth, lately it happened to me at:
Juridicum Wien, Law Faculty of Vienna University, Austria

This bug has been fixed in the 3.4 kernel (IIRC). So what I've done to fix the problem is compile the appropriate kernel module into my running kernel.

Download the latest stable snp release of compat wireless, extract and run
$ ./scripts/driver-select
Select the corresponding driver and run
$ make
$ sudo make install
$ sudo make wlunload
$ sudo modprobe <yourdrivername>

Your milage may vary, but this worked for me. Not sure if it's needed, but I repeat these steps each time I get a kernel update.
Hope this helps.

Thanks Janis, I'll try your workaround as soon as i get to a non-eduroam network.

This bug should therefore be fixed in the current development branch 13.04 (Raring). Can anyone confirm this, then the bug could finally be closed for all 3.4+ ubuntu releases.

Hi,
I havent tried the work around yet but I tried the Eduroam with Ubuntu 13.04 on two different laptops and also get at lot of randomly disconnects :/

In 12.04.x proposed there is patched wpasupplicant package, which solves the problem to 90 percent. Give it a try!

There are random disconnects, but it is stable most of the time. From my experience the 5 GHz channel are more stable than the 2 GHz ones.

Furthermore there are different kernel patches since 3.9.5 to get a faster authentication during direct probing => see text;

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

  * Multiple patches to reduce the number of disconnections for WPA Enterprise
    roaming and Opportunistic Key Caching. (LP: #1187524)
  * In debian/patches:
    0001-sme-fix-retry-after-auth-assoc-timeout-failure.patch,
    0002-sme-optimize-recovery-from-common-load-balancing-mechanisms.patch,
    0003-sme-blacklist-bss-on-first-failure-if-only-a-*.patch,
    0004-sme-extend-load-balancing-optimization-in-bss-blacklisting.patch,
    0005-sme-optimize-recovery-from-association-command-failures.patch,
    0006-sme-add-timers-for-authentication-and-association.patch,
    0007-sme-nl80211-set-cipher-suites.patch:
    Cherry-pick patches fixing SME (Session Management Entity) for the nl80211
    driver, which works as a basis for the OKC patches.
  * In debian/patches:
    0001-pmkokc-Set-portValid-TRUE-on-association-for-driver-based-4.patch,
    0002-pmkokc-Clear-WPA-and-EAPOL-state-machine-config-pointer-on-.patch,
    0003-pmkokc-Clear-driver-PMKSA-cache-entry-on-PMKSA-cache-expira.patch,
    0004-pmkokc-Flush-PMKSA-cache-entries-and-invalidate-EAP-state-o.patch,
    0005-pmkokc-Fix-proactive_key_caching-configuration-to-WPA-code.patch,
    0006-pmkokc-RSN-Add-a-debug-message-when-considing-addition-of-O.patch,
    0007-pmkokc-Clear-OKC-based-PMKSA-caching-entries-if-PMK-is-chan.patch,
    0008-pmkokc-Move-wpa_sm_remove_pmkid-call-to-PMKSA-cache-entry-f.patch,
    0009-pmkokc-Use-PMKSA-cache-entries-with-only-a-single-network-c.patch,
    0010-pmkokc-PMKSA-Do-not-evict-active-cache-entry-when-adding-ne.patch,
    0011-pmkokc-PMKSA-Set-cur_pmksa-pointer-during-initial-associati.patch,
    0012-pmkokc-PMKSA-make-deauthentication-due-to-cache-entry-remov.patch,
    0013-pmkokc-PMKSA-update-current-cache-entry-due-to-association-.patch:
    Cherry-pick patches to properly do OKC (Opportunistic Key Caching) which
    helps maintaining connectivity on networks secured with WPA Enterprise,
    especially on nl80211-based drivers -- these patches require SME, and add
    or fix key caching and handling of the cache entries.
  * debian/patches/force-enable-okc.patch: force Opportunistic Key Caching to
    be enabled.
  * debian/patches/less-aggressive-roaming.patch: use less aggressive roaming
    settings to avoid switching to another AP unnecessarily, when the actual
    signal level difference is small.
  * debian/patches/wpa_supplicant-dbus-null-error.patch: Don't send NULL to
    dbus_message_new_error().
  * debian/patches/0001-nl80211-Fix-UNSPEC-signal-quality-reporting.patch: fix
    marking qual as invalid rather than signal level.
  * debian/patches/wpa_supplicant-squelch-driver-disconnect-spam.patch: recover
    cleanly from streams of disconnect messages (like on iwl3945).
  * debian/patches/wpa_sup...