Hello.
I'm facing quite an interesting issue here.
Hotel wifi, with psk auth. All devices works fine, including
various models of cell phones, various laptops. But one laptop
does not work, the network refuses to authenticate, NetworkManager
re-asks for the password. The same laptop, when rebooted into
windows, with the same password, connects to wifi network instantly.
Reboot into linux - and NetworkManager asks for the password again
(psk stored in /etc/NetworkManager/system-connections/<Netname> is
the right one).
Reboot the access point, and linux also assotiates instantly. Now
everything works.
But after some time (within one day so far), after next attempt to
use this wifi network, linux again asks for a password endlessly.
Rebooting AP helps, as is rebooting this laptop into windows. But
rebooting into linux does not help, the AP refuses to authenticate
linux.
There's another hotel nearby, they run another wifi network. I
tried to use their network (our hotel staff know their password).
And the behavour is exactly the same -- only this my laptop, when
booted into linux, is not authenticated by the AP, this laptop
when booted into windows connects instantly, as are other devices
like cell phones or laptops.
So the thing is definitely this laptop. However, I never had any
probs with its wifi support so far, it always worked fine before
this story.
So I really wonder what the problem is, what's the difference
between linux and windows for a "non-fresh" AP, why it refuses
to auth linux, and finally fix the problem so it wont appear
again... ;)
I'm running linux kernel 3.16 on debian jessie. The NIC is this
one:
03:00.0 Network controller:
Intel Corporation Centrino Advanced-N 6235 (rev 24)
Here's how a typical auth attempt looks like:
Aug 21 11:31:49 x200la wpa_supplicant[1546]: wlan0: SME: Trying to authenticate with c0:4a:00:49:1b:f2 (SSID='Prada' freq=2437 MHz)
Aug 21 11:31:49 x200la kernel: wlan0: authenticate with c0:4a:00:49:1b:f2
Aug 21 11:31:49 x200la kernel: wlan0: send auth to c0:4a:00:49:1b:f2 (try 1/3)
Aug 21 11:31:49 x200la wpa_supplicant[1546]: wlan0: Trying to associate with c0:4a:00:49:1b:f2 (SSID='Prada' freq=2437 MHz)
Aug 21 11:31:49 x200la kernel: wlan0: authenticated
Aug 21 11:31:49 x200la kernel: wlan0: waiting for beacon from c0:4a:00:49:1b:f2
Aug 21 11:31:49 x200la NetworkManager[1337]: <info> (wlan0): supplicant interface state: scanning -> authenticating
Aug 21 11:31:49 x200la NetworkManager[1337]: <info> (wlan0): supplicant interface state: authenticating -> associating
Aug 21 11:31:49 x200la wpa_supplicant[1546]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="Prada" auth_failures=1 duration=10 reason=CONN_FAILED
Aug 21 11:31:49 x200la NetworkManager[1337]: <info> (wlan0): supplicant interface state: associating -> disconnected
Aug 21 11:31:54 x200la NetworkManager[1337]: <info> (wlan0): supplicant interface state: disconnected -> scanning
Any hints please? :)
Thank you!
/mjt
On 21 August 2015 at 11:35, Michael Tokarev <[email protected]> wrote:
> Any hints please? :)
Disable NetworkManager (or make it ignore WiFi interface) and
temporary use wpa_supplicant. Get a log with debugging enables when it
fails and when it success. Look for errors in fail log, compare it
with success one.
--
Rafał
On Fri, 2015-08-21 at 12:35 +0300, Michael Tokarev wrote:
>
> Aug 21 11:31:49 x200la kernel: wlan0: authenticated
> Aug 21 11:31:49 x200la kernel: wlan0: waiting for beacon from c0:4a:00:49:1b:f2
Do you see any *kernel* messages after this? I'm half expecting to see
that the beacon never arrives, or something like that?
Are the hotels running similar equipment perhaps? If rebooting the AP
helps then perhaps the APs aren't actually beaconing quite properly -
maybe you could put the card into sniffer mode (monitor mode) and
capture what's going on over the air for a bit after this happened?
johannes
21.08.2015 13:16, Johannes Berg wrote:
> On Fri, 2015-08-21 at 12:35 +0300, Michael Tokarev wrote:
>>
>> Aug 21 11:31:49 x200la kernel: wlan0: authenticated
>> Aug 21 11:31:49 x200la kernel: wlan0: waiting for beacon from c0:4a:00:49:1b:f2
>
> Do you see any *kernel* messages after this? I'm half expecting to see
> that the beacon never arrives, or something like that?
The kernel log is repeated. The next log line is again scanning start,
since NetworkManager (or wpa_supplicant, I'm not familiar with the machinery
involved) request scan again.
> Are the hotels running similar equipment perhaps? If rebooting the AP
> helps then perhaps the APs aren't actually beaconing quite properly -
> maybe you could put the card into sniffer mode (monitor mode) and
> capture what's going on over the air for a bit after this happened?
Can you give some more specific comments please? We just rebooted the
AP the next time, it all started working again, and I need to install
all the necessary tools while it is working ;) Since I'm not familiar
with wifi machinery, maybe you can give me specific command lines to
run? :)
Thank you!
/mjt
> > Do you see any *kernel* messages after this? I'm half expecting to see
> > that the beacon never arrives, or something like that?
>
> The kernel log is repeated. The next log line is again scanning start,
> since NetworkManager (or wpa_supplicant, I'm not familiar with the machinery
> involved) request scan again.
Ok, that's interesting.
> > Are the hotels running similar equipment perhaps? If rebooting the AP
> > helps then perhaps the APs aren't actually beaconing quite properly -
> > maybe you could put the card into sniffer mode (monitor mode) and
> > capture what's going on over the air for a bit after this happened?
>
> Can you give some more specific comments please? We just rebooted the
> AP the next time, it all started working again, and I need to install
> all the necessary tools while it is working ;) Since I'm not familiar
> with wifi machinery, maybe you can give me specific command lines to
> run? :)
Oh, well, there's some information here:
https://wireless.wiki.kernel.org/en/users/documentation/iw
iw wlan0 set type monitor
iw wlan0 set channel X
ip link set wlan0 up
tcpdump -i wlan0 -s0 -w /tmp/dump
could capture this on another machine.
johannes
21.08.2015 12:53, Rafał Miłecki wrote:
> On 21 August 2015 at 11:35, Michael Tokarev <[email protected]> wrote:
>> Any hints please? :)
>
> Disable NetworkManager (or make it ignore WiFi interface) and
> temporary use wpa_supplicant. Get a log with debugging enables when it
> fails and when it success. Look for errors in fail log, compare it
> with success one.
That's good hint. Thank you very much!
I tried what you suggested. Unfortunately the difference does not tell
me much, or actually, does not tell me the _why_, it looks like the AP
misbehaves somehow.
Here are the main difference (- for bad, + for good):
nl80211: Association request send successfully
-nl80211: Drv Event 20 (NL80211_CMD_DEL_STATION) received for wlan0
-nl80211: Delete station c0:4a:00:49:1b:f2
nl80211: Drv Event 38 (NL80211_CMD_ASSOCIATE) received for wlan0
-nl80211: MLME event 38; timeout with c0:4a:00:49:1b:f2
-wlan0: Event ASSOC_TIMED_OUT (15) received
-wlan0: SME: Association timed out
-wlan0: Radio work 'sme-connect'@0x7fbf84e5a700 done in 0.137132 seconds
...
So in "good" case, there's one event, CMD_DEL_STATION, received
right before the CMD_ASSOTIATE. The rest look similar besides a
few probably irrelevant details (timings, frequency, etc).
I'm attaching the diff between the two attempts, and 2 complete logs
(gzipped). The "bad" log is larger since it contain several attempts
to connect, while the good one is just one successful attempt.
Can something be said about the problem based on these logs?
Thank you very much!
/mjt