Opensuse 13.2 64bit KDE vs WPA2 Enterprise PEAP, keeps on disconnecting

Hello,

I have been using different distributions of Linux for the past few months, I have tried:
Ubuntu 14.04
Linux Mint 16/17
OpenSuse 13.1/13.2

I have decided to stay with OpenSuse because I enjoyed my experience with OpenSuse 13.1 much. I did not have any issues with the distributions, no incompatibilities.

My laptop is Lenovo T410S, and there is one issue that I am yet to resolve, which exists in all the distributions I have mentioned above:
Wireless connection to my University Campus wireless system disconnects.
Once I have been disconnected, I cannot connect back to the network without rebooting the system.

Edit: There are times even when I reboot, the network refuses to let me re-connect. My IT help-desk have not been most helpful. Last semester, I was able to contact my Lab technician to allow me wired connection. I am no longer in a laboratory with wired internet connection.

The network is WPA2 Enterprise PEAP encrypted. I use my student account and password to connect to the network. I am clueless what to do other than reboot and hope for the best whenever I get disconnected.

I was wondering if there was a way to fix this issue
Thank you for your time

-SJLPHI

When trying to connect back to the network, run in a terminal; tail -f /var/log/messages and observe for any error messages.

Or you can just check /var/log/messages and /var/log/NetworkManager for hints as to what may be causing the problem.

they both seem to be not there.


sjl@Schlampe:~> cat /var/log/messages
cat: /var/log/messages: No such file or directory
sjl@Schlampe:~> cat /var/log/NetworkManager
cat: /var/log/NetworkManager: No such file or directory
sjl@Schlampe:~> ls /var/log | grep message
sjl@Schlampe:~> ls /var/log | grep Manager

My bad, I always forget 13.2 defaults to systemd’s journal and not the old syslog. So just type; journalctl -f

It’s a “live tail” so if you do something it’ll print it on the screen. CTRL+C to exit it.

To view the log completely (historic events and such), just type; journalctl -l

You can move with home/end/pageup/pagedown. It might be a bit slow if the journal is massive.

Some more information to gather…

Are you using a special wireless client app? – ie Are you using something like a Cisco or Lucent (or whatever) app or are you configuring NM?

Are you being issued a client configuration file and/or certificate or are you simply entering username/password in which case your cert would probably be dynamically downloaded after username/password authentication?

Are you disconnecting immediately or after some time, and if after some time, is the length of time always the same?

You may also want to try running wireshark during one of your sessions (if nothing is found in your syslog) to see if you’re being forcibly disconnected or if perhaps you’re timing out from inactivity.

TSU

Hello,
I am using the default KDE Network Manager that comes with OpenSuse13.2 64bit KDE version.
I am only entering username/password using PEAP protection through it the network manager.

I think disconnection time is arbitrary, sometimes I am fine for hours, sometimes less than ten minutes. It gets very irritating when I am trying to send an e-mail or doing some research. Downloading/saving my my browser content became my second nature.

I’ve never learned how to use wireshark.
Miuku as for “journalctl -l”, it seems like there is a HUGE list of materials. I will run “journalctl -f” next time I am connected to campus wifi-system and upload the log when I get disconnected. I’m uncertain what I’m going to be looking for though.

Thanks
-SJL

Miuku as for “journalctl -l”, it seems like there is a HUGE list of materials. I will run “journalctl -f” next time I am connected to campus wifi-system and upload the log when I get disconnected. I’m uncertain what I’m going to be looking for though.

Thanks
-SJL

You could record the log with something like

journalctl -l|grep Network > nm.log

You’d obviously wait until a disconnect event was observed, then run the command,

or run it live in a terminal with

journalctl -f|grep Network > nm.log

and CTRL-C to stop when event captured.

I think disconnection time is arbitrary, sometimes I am fine for hours, sometimes less than ten minutes. It gets very irritating when I am trying to send an e-mail or doing some research. Downloading/saving my my browser content became my second nature.

This behaviour can be caused by some routers. I connect to a number of different AP’s (work, home, public, family etc), and one particular Vodafone unit at my parent’s place can knock me off randomly, even when IP traffic flowing. Thankfully, they’ve just changed providers and upgraded to new a new wireless router, so that annoyance has now gone. :slight_smile:

Thank you for the reply, I have logged my “disconnection” from this morning to reboot and successful connection.


Jan 05 09:25:13 Schlampe.Concubine5 NetworkManager[826]: <warn> Connection disconnected (reason -4)
Jan 05 09:25:13 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: completed -> disconnected
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: disconnected -> scanning
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: scanning -> authenticating
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: authenticating -> associating
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: associating -> 4-way handshake
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: 4-way handshake -> completed
Jan 05 09:25:14 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): roamed from BSSID 00:23:EB:08:5D:20 (CU-Wireless) to 64:D8:14:B1:65:40 (CU-Wireless)
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): roamed from BSSID 64:D8:14:B1:65:40 (CU-Wireless) to (none) ((none))
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: completed -> authenticating
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: authenticating -> associating
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: associating -> 4-way handshake
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: 4-way handshake -> completed
Jan 05 09:25:24 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): roamed from BSSID (none) ((none)) to 34:BD:C8:BE:6C:C0 (CU-Wireless)
Jan 05 09:26:58 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): roamed from BSSID 34:BD:C8:BE:6C:C0 (CU-Wireless) to (none) ((none))
Jan 05 09:26:58 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: completed -> authenticating
Jan 05 09:27:01 Schlampe.Concubine5 NetworkManager[826]: <info> (wlp3s0): supplicant interface state: authenticating -> disconnected

I have shortened the log to satisfy 15000 character limit.

I’ve seen these roaming errors reported previously in various bug threads.

Examples:
https://bugzilla.redhat.com/show_bug.cgi?id=864906
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732391

I wonder if upgrading wpa_supplicant might help here (openSUSE 13.2 uses version 2.2)

https://software.opensuse.org/package/wpa_supplicant

*The hardware repo offers version 2.3

If not, consider filing a bug report I guess.

You can give the full log using http://paste.opensuse.org/
Just upload the file there and share the link here in your post.

I am getting this error:
http://paste.opensuse.org/17127555.

I have logged my “Jan 05” showing the behaviour of my entire day on campus regarding Network Manager. To my understanding, there is a non-stop roaming.
It roams from Router to Router then ends up to (none) and cannot connect to anything until reboot.

If you believe roaming is your problem, a suggested solution is to “lock in” the AP and prevent roaming by specifying the BSSID in your NM connection as described in this thread
https://mail.gnome.org/archives/networkmanager-list/2011-February/msg00045.html

If you’re stationary and not moving, there is probably little reason to be “roaming.”

TSU

Thank you, I briefly read the thread and unfortunately I am using a laptop in a campus wireless network. I will be moving constantly throughout the day. I don’t think it’ll be realistic for me to manually lock in to a location.

Well, if you need to connect at specific locations within the campus, maybe it would be practical to define connections to associate with specific AP’s (pertaining to those locations).

The real question and issue is whether you’re mobile <while> you’re connected, eg using your laptop constantly as you’re moving from kiosk to kiosk in a large auditorium.

If instead you sit down while you’re computing, then move to another location, then you can create multiple NM connections, each with a different BSSID for each stationary location you move to.

TSU

Exactly, which is what I was trying to clarify as well.

It seems as if when I am stationary, if there are many students surrounding me who are moving around, the disconnections are VERY frequent. I have had to reboot my laptop 5 times to be able to post in the past hour.

I have tried logging the journalctl -l from the time period from the past hour but it seems that the journal clock is either running at a different calender or there is no log containing the word “Network” from today. The latest log is from Jan 20th.

Another pattern that I’ve recently noticed is that the connection gets worst in my laboratory. I would like to learn how to “lock-in” to a specific router but again, I don’t have a specific location where I do most of my work.

Also, from previous suggestions, it sounds like if this is a roaming issue, it sounds like it’s a reported bug. Has there been a fix in the later kernels?

That’s why I suggested defining a number of connections pertaining to several key locations around the campus you might freqent.