Hide Forgot
Description of problem: Lenovo ThinkPad T500 with Intel Pro/Wireless 5000 A/G/N Chipset. After a fresh install of Fedora 15 the wireless network, (using WPA2 Personal), connects and works for a few minutes, (< 5), and then it stops working. The only way to reconnect is to start and stop wireless, and again, it will run only fora few minutes. Version-Release number of selected component (if applicable): >> iwl5000-firmware-8.83.5.1_1-1.fc15.noarch iwl3945-firmware-15.32.2.9-5.fc15.noarch python-iwlib-0.1-6.fc15.x86_64 iwl6000g2a-firmware-17.168.5.1-2.fc15.noarch iwl5150-firmware-8.24.2.2-2.fc15.noarch iwl1000-firmware-39.31.5.1-1.fc15.noarch iwl6000-firmware-9.221.4.1-2.fc15.noarch iwl6050-firmware-41.28.5.1-3.fc15.noarch iwl100-firmware-39.31.5.1-2.fc15.noarch iwl4965-firmware-228.61.2.24-3.fc15.noarch << How reproducible: Steps to Reproduce: 1. Connect Wirelessly to a network and verify connection. 2. Wait a few minutes. 3. Attempt to verify connections again; it will fail. Actual results: Wireless connection dies, with no error, after a few minutes. Expected results: Once Connected Wirelss should remain connected. Additional info: I apologize if this is a duplicate... I've read through most of the bugs with "wireless" as a keyword, and couldn't find this issue. I don't know that it is related to the Intel Chipset, but that's what I have. There was no similar problem in Fedora 12, (the previous release running on this piece of hardware. I am not having this problem with other devices on my wireless network.
Created attachment 501815 [details] Relevant section of /var/log/messages Attached is a section of /var/log/messages... I disconnected the wired LAN. Connected the wireless, verified that I could access the web, and then waited a few minutes. I could no longer reach the web. If there's any additional data that would be useful I'd be pleased to try to get it to you. Karl
No idea so far what could be wrong. Please provide dmesg, and "rfkill list" output.
(In reply to comment #2) > Please provide dmesg Or better /var/log/messages but configured as described here: https://fedoraproject.org/wiki/DebugWireless in "Configure syslog to debug kernel and wpa_supplicant"
I'm not ignoring your request, but I can't get to the machine until later today... Thanks!
Created attachment 502410 [details] Relevant section of /var/log/messages
(Failed to add comments with attachment.. sorry for the endless stream of e-mails) I made the requested changes to /etc/rsyslog.conf and /etc/sysconfig/wpa_supplicant. Then I rebooted the machine. The attached log shows everythig from the reboot on, Networking worked, as usual for a few minutes and then quit again. (The section of log covers the whole range of events.) But, I have determined that networking still works, that is, I can ssh to otehr systems in my local network by IP Address, so the problem seems to be with name resolution. This only a problem on the Fedora 15 PC, and only a problem while using wireless networking. I am willing to accept that somehow this is an EYE-DEE-TEN-TEE error, but I don't see what I'm doing wrong. Karl
So this is not wireless driver problem. This could be problem of NetworkManager, glibc, or kernel tcp stack or even your router. There is one is suspicious thing in your log: > [ 342.978057] TCP lp registered This mean that LP (low priority) congestion control algorithm start to used (why? NetworkManager do this?). You can check which algorithm is used by: cat /proc/sys/net/ipv4/tcp_congestion_control Does change to some different algorithm, i.e: echo "cubic" > /proc/sys/net/ipv4/tcp_congestion_control fix the problem?
Changing the congestion control algorithm did not appear to have any effect. Over the weekend I ran an update on the system, and I noted that a new copy of NetworManager aws installed... disappointingly, that had no effect, either. I set teh logging level of NetworkManager to "DEBUG" and let that log to var/log/messages while I ran through a session of networking works... then stops, then I restarted the wireless connection and again, it worked for a bit. I will attach the log. I am not an expert in NetworkManager, but there are a few lines that seem suspicious; perhaps they will be meaningful to someone who does understand how NM works. Thanks, Karl
Created attachment 503260 [details] /var/log/messages - DEBUG log level on NetworkManager /var/log/messages with NetworkManager set to "DEBUG" logging. Karl
I'm not seeing anything suspicious in the logs, but I'm not familiar with NetworkManager (CCing Dan). Could you provide output of following commands (as root) cat /etc/resolf.conf ifconfig -a route when network works, and when stop to work. Is there any difference?
Created attachment 504248 [details] resolv.conf, route, and ifconfig -a This output was produced while the network was not working, though the output when it was working is more-or-less identical. (I will attach that, too.) Further, I have connected a computer running a toy operating system to my wireless network, and it work with no problems. (That computer had never before been on this network.) I've also rebooted all the network devices, firewall, router, hubs, everything, and it has made no difference. Inexplicably, if I run `dig google.com` while the network is not working... it resolves, but wget, at the same time fails. And, while wired, everything works flawlessly. I guess the next thing to try is another wireless network, to see if the behavior is peculiar to this network. Karl
Created attachment 504249 [details] resolv.conf, ifconfig -a and route while *working*
Connected to an "open" public WiFi Network seems to work perfectly well. I think this rules out a hardware problem on the computer. So: The secure wireless network works with other computers without troubles. This Fedora 15 computer can use wireless on unsecured wireless networks. On the other hand, if this were a problem connecting Fedora to secured (WPA2, personal) networks I'd expect that *everyone* would be complaining. I remain willing to test and provide output and such, but I'm at a loss. Karl
I'm running into this same issue. I keep getting "supplicant failed" messages in my /var/log/messages when it happens. My wireless will keep connecting and disconnecting, but it only seems to happen on encrypted connections. Open connections work fine.
Does changing to in kernel mac80211 layer cryptography helps? modprobe -r iwlagn modprobe iwlagn swcrypto=1 swcrypto50=1
I will test tonight. Karl
To add additional information, not that either of these pieces of software are maintained here, the problem seems to go away when I switch my wireless driver from ndiswrapper to broadcom's wl. Relevant line from lspci: 0c:00.0 Network controller: Broadcom Corporation BCM4311 802.11b/g WLAN (rev 01) I don't know if anyone else can confirm this behavior, but this is what I'm experiencing.
From: >> --- Comment #15 from Stanislaw Gruszka <sgruszka > 2011-06-13 07:15:43 EDT --- Does changing to in kernel mac80211 layer cryptography helps? modprobe -r iwlagn modprobe iwlagn swcrypto=1 swcrypto50=1 << Yes. That helps, some. It ran wirelessly on my secured home network for about 10 minutes before the connection died, again. (Disappointing.. it lasted so much longer, I thought it was not going to fail.) Karl
So this is wireless driver or common mac80211 layer problem. Please try compat-wireless-next from http://people.redhat.com/sgruszka/compat_wireless.html. It contains some new fixes, that could eventually helps. If it does not, please provide verbose iwlwifi debug logs. modprobe -r iwlagn modprobe iwlagn debug=0x47ffffff Even if this is mac80211 problem, logs should give some clue where the issue is. Logs should contains massages between module load and network stops work. Note, that you probably will need to configure syslog as described in "Configure syslog to log kernel debug messages" in https://fedoraproject.org/wiki/DebugWireless .
Sorry. It has taken me a while to test this. I loaded compat-wireless-next. I installed: kmod-compat-wireless-next-2011_06_14-0.fc15.2.x86_64.rpm If I run: modprobe -r iwlagn ; modprobe iwlagn debug=0x47ffffff Wireless runs for a long time without failing. (It does, however, fill /var/log/messages with gigabytes of messages. ) If I try to start iwlagn without the debug= parameter, however, wireless reverts to failing after a few minutes. So, it seems if I am willing to deal with huge logs, I can get wireless to work. (Perhaps there's some other parameter that I need to give iwlagn to make it work properly if I don't give it the debug flag. ?? ) Karl
(In reply to comment #20) > If I try to start iwlagn without the debug= parameter, however, wireless > reverts to failing after a few minutes. That would make issue even more hard to solve, seems there are some race conditions, that are not reproducible with debug messages, which slow down execution of the driver. Perhaps with less verbose debug problem will be reproducible, let say debug=0x5fff or debug=0x0803. > with huge logs, I can get wireless to work. (Perhaps there's some other > parameter that I need to give iwlagn to make it work properly if I don't give > it the debug flag. ?? ) It's worth to try 11n_disable=1, plpc_check=0, bt_coex_active=0 (on older kernel this is iwlcore module parameter)
Been busy.... before I got a chance to test this latest idea.. the problem seems to have gone away. I haven't looked through the yum log to see what got updated, but some thing, or combination of things, has made the problem vanish a couple of days ago. Karl
Karl, can you use "yum history list" which will show you transactions, and then "yum history info $TRANSACTION_ID" to see what update get things fixed. Tristan, does update help for you too?
Ok, I assume there is nothing to do here any longer.
Can I request this bug to be re-opened and moved accordingly? It is exactly what is happening with my RedHat 6.1 install. I will attempt the debug level log output for the wireless driver to work around the race condition issue, as having to restart the wifi every few minutes is annoying to say the least. I can provide more information and logging if required.
RHEL bugs need to be filed separately, as they are handled by entirely different teams.