Bug 814914

I just updated NetworkManager to version 0.9.4.0-6 and, so far, the connection issue seems solved.  However, and given that I have seen before NetworkManager performing ok for a couple of days before failing, I will wait for a while and then report back.

No, it didn't took that long to start failing again. After an initially successful login to my home wireless network, half an hour later NetworkManager disconnected and started asking for the password to login again.  It's essentially the same situation.

Please attach /var/log/messages (and indicate at what time the connection was lost if it's not super obvious from the log)

I'm attaching two logs I found in my system. I'm no expert, but from what I saw it appears wlan went down four minutes after launching the whole system.

Created attachment 580956 [details]
Messages log

Created attachment 580957 [details]
Second messages log found

The logs indicate that on "Apr 17 10:46:07" a yum update performed and update of NetworkManager, which due to a bug in the packages acutally restarts NM.  That's been fixed recently as part of bug 812967.

Then at "Apr 17 10:51:17" logs indicate that the laptop's Airplane Mode (rfkill) switch was enabled, which terminated the wifi connection, or else the "Wireless Enabled" option was unchecked in the applet or GNOME shell.  The same thing is indicated at "Apr 17 15:56:31":

Apr 17 15:56:31 Hogar NetworkManager[710]: <info> (wlan0): device state change: activated -> unavailable (reason 'none') [100 20 0]
Apr 17 15:56:31 Hogar NetworkManager[710]: <info> (wlan0): deactivating device (reason 'none') [0]
Apr 17 15:56:31 Hogar NetworkManager[710]: <info> (wlan0): canceled DHCP transaction, DHCP client pid 32547
Apr 17 15:56:31 Hogar NetworkManager[710]: <info> (wlan0): taking down device.
Apr 17 15:56:31 Hogar NetworkManager[710]: <info> WiFi hardware radio set disabled
Apr 17 15:56:31 Hogar NetworkManager[710]: <info> WiFi now disabled by radio killswitch

The killswitch might also be caused by choosing to disable wireless through the UI.  When this happens, can you grab the output of:

nmcli nm
rfkill list

Thanks!

I will try my best.  The problem is that during the last reboots of this system wireless has not being available as an option.  Is as if NM were not detecting the atheros card (in fact, my first suspicion was precisely faulty hardware, but then found out wireless became sometimes available simply by rebooting).  I also just found out kernel 3.3.4-1 became available, so I will try testing after installation.

from boricua second attached log: 

  https://bugzilla.redhat.com/attachment.cgi?id=580957
  >   Apr 18 21:38:21 Hogar kernel: [124719.241304] ath5k phy0: gain calibration timeout (2412MHz)

so maybe related to:

  https://bugzilla.redhat.com/show_bug.cgi?id=638943

ath5k driver is probably misbehaving.

Do you still experience issues with wireless with newest NM and kernel?
If so please attach /var/log/messages again.

(In reply to comment #10)
> ath5k driver is probably misbehaving.
> 
> Do you still experience issues with wireless with newest NM and kernel?
> If so please attach /var/log/messages again.

Yes, same situation still. NM works with wireless after rebooting with new kernel, then around one or two hours later starts loosing signal, after which it states that wireless is unavailable. Cable connection keeps working ok.

Would you please attach output of
$ dmesg
# ethtool -S wlan0

when you have the problems.

Ok. I just restarted the computer and wireless is working again for the time being. As soon as I find the issue again I will post the output requested.

After several hours of use, the problem is back. I'm attaching the outputs I just got.

Created attachment 611561 [details]
Dmesg output

Created attachment 611562 [details]
Ethtool output

Further details. As usual, NM interrupts to ask for wifi password. After providing password, NM starts with wifi again for a few seconds, then asks for password again,... and again. Wireless becomes unavailable.

As a workaround, try disabling powersaving, which could help preventing
random disconnects:
# iwconfig wlan0 power off

Also, it would help us to see detailed logs from wpa_supplicant. Here's how to get them:
https://live.gnome.org/NetworkManager/Debugging#wpa_supplicant07

Reassigning to kernel for now ...

(In reply to comment #18)
> As a workaround, try disabling powersaving, which could help preventing
> random disconnects:
> # iwconfig wlan0 power off
> 
> Also, it would help us to see detailed logs from wpa_supplicant. Here's how
> to get them:
> https://live.gnome.org/NetworkManager/Debugging#wpa_supplicant07
> 
> Reassigning to kernel for now ...

Thanks, I'll try that and report back later. Let me report first that some progress seems to have being achieved. At least NM now reports the wireless option as "available", although no signals are detected.  After several hours of use with wireless option activated, NM detects the wireless signals and tries to connect, without success.

Tried the iwconfig command, but this is what I got:

[root@Hogar ~]# iwconfig wlan0 power off
Error for wireless request "Set Power Management" (8B2C) :
    SET failed on device wlan0 ; Operation not supported.
[root@Hogar ~]#

Created attachment 612569 [details]
wpa_supplicant log

As requested, I ran the commands and got the following log after wireless collapse.  Hope it helps.

Since moving to kernel 3.6 in Fedora 17 and now Fedora 18 alpha, I haven't notice any loss of wifi signal nor further signs of instability from Network Manager. Given that it has been like this for more than two months now, I believe it is safe to close this bug.  Of course, I leave it to you.

Thank you for letting us know.  If you have further troubles with atk5k, please open a new bug report with the relevant details.