Description of problem: ----------------------- I am using a TP-Link TL-WN822N 300Mbps wireless USB adapter. Every 1-3 minutes network is getting disconnected and after some time network indicator on the top menu is changing to question mark icon. Version-Release number of selected component (if applicable): ------------------------------------------------------------- I noticed this on Fedora 23, 24 and 25 beta. I tried different tweaks like disabling IP6 and etc but none was worked. Recently saw Fedora 25 is going to support raspberry pi models as well, so please try to fix this issue in a proper way instead suggesting tweaks for some adapters. How reproducible: ----------------- use a TP-Link (TL-WN822N 300Mbps) wireless USB adapter and try Steps to Reproduce: ------------------- 1. Install Fedora 25 (or 23, 24) on a desktop pc and use a TP-Link (TL-WN822N 300Mbps) wireless USB adapter to connect to the internet. 2. Navigate on random web pages and test Actual results: --------------- Network is getting disconnected after 1-3 min. But when I was inactive, screen is getting off and locked. But in this case network is kept as connected in many cases. Expected results: ----------------- Network should not be disconnected. Additional info: ----------------- [dumindu@localhost ~]$ lsusb Bus 002 Device 003: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 002: ID 09da:000a A4Tech Co., Ltd. Optical Mouse Opto 510D / OP-620D Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub [dumindu@localhost ~]$ ps -ef |grep wrap dumindu 6908 6801 0 00:04 pts/0 00:00:00 grep --color=auto wrap Let me know if you need any help by running some tweaks on my pc. Thanks.
*** Bug 1387866 has been marked as a duplicate of this bug. ***
please reproduce the problem and attach a logfile of NetworkManager with level=TRACE edit /etc/NetworkManager/NetworkManager.conf to have [logging] level=TRACE and `systemctl restart NetworkManager`. Then reproduce the problem and attach the output of `journalctl -u NetworkManager -b 0` Thanks
Created attachment 1213219 [details] logs
in the logfile, - twice the connection is diconnected because something stopped NetworkManager. Possibly you did `systemctl restart NetworkManager`? [1477229425.0881] device (wlp0s29f7u4): state change: activated -> deactivating (reason 'unmanaged') [100 110 3] [1477229555.4077] device (wlp0s29f7u4): state change: activated -> deactivating (reason 'unmanaged') [100 110 3] - once the connection is disconnected, because something externally switched off rfkill. [1477229457.0833] manager: WiFi hardware radio set disabled - another time, activation files with [1477229524.4576] device (wlp0s29f7u4): state change: activated -> failed (reason 'ssid-not-found') None of this seems unexpected bahavior (except it's a bit surprising to restart NetworkManager or turn off Wi-Fi). Can you wait until the disconnect happens, and look at the logfile what's happening at that moment?
Created attachment 1213248 [details] logs 2nd attemp I just changed the configs and restarted network Then waited until the network got disabled and network indicator converted to ?
Created attachment 1213249 [details] logs 2nd attemp, after reconntect manually After 2nd attempt, I reconnect wifi by clicking on the relevant network item on wifi networks list of settings->network. If I manually did this, network is getting reconnected again. Even it getting disconnected for a some reason, it should reconnect again, right?
Also when using Windows 7 on same network, same hardware, This type of issues are not happening.
at the end of log2, the device is connected to connection 'Dialog 4G'. as you would also see with nmcli device show Initially, the connectivity-check determines that you are connected to the internet. (it does so, by trying to fetch http://fedoraproject.org/static/hotspot.txt). Shortly after, that fails with connectivity: check for uri 'http://fedoraproject.org/static/hotspot.txt' failed with 'Error resolving 'fedoraproject.org': Name or service not known' which is why you see a question mark in the GUI. when that happens, are you still able to ping something on the internet? ping 8.8.8.8 are you still able to ping your router? ping 192.168.1.1 are you still able to resolve names? ping www.google.com what is the content of /etc/resolv.conf
Created attachment 1214236 [details] no network, before change indicator no network, before change indicator
Created attachment 1214237 [details] no network, after change indicator no network, after change indicator
Created attachment 1214238 [details] reconnect manually
Created attachment 1214241 [details] Answers for question Answers for question
Any other thing, I need to be done?
I have the same problem on Fedora 25, Lenovo T540P laptop using built-in wifi adapter and LinkSys EA8500 router. Same symptoms and similar logs to those reported above - I can provide more logs or details of my system if that will help. There is no problem if I use a wired connection to the router, but I have yet to get wireless working reliably. I upgraded to F25 and got a new router about the same time so not sure where the issue resides.
I have a theory - my old TP-Link router does not have the problem, and now I have re-configured my new linksys router to use "IPV6 - pass-through" instead of "IPV6 - automatic" The difference is that in the problem case this hangs: wget -6 'http://fedoraproject.org/static/hotspot.txt' but in the working cases it returns "network unreachable" immediately. My theory is that when NetworkManager is checking for liveness at fedoraproject.org, it sometimes tries to use ipv6 which causes something to timeout and NetworkManager to force a reconnect. During the failures I did notice that sometimes plain `ping` (not ping -6) was using ipv6 addresses by default. Possibly there is indeterminism in the resolver that sometimes picks ipv6? Also seems like a router bug that the router tries forever to connect to ipv6 via the "Automatic" method and never admits the network is unreachable but that's another story. Hope this helps.
(In reply to Alan Conway from comment #15) > I have a theory Retract that theory - I'm still having the problem after the config changes to the linksys router - I still have the problem even if I disable IPv6 in the NetworkManager applet settings. So IPv6 may just be a red herring.
Update on this - the problem is definitely router-related. I get disconnected reliably with my linksys EA8500, I never get disconnected with my older TP-link Archer C2 (which is now set up as a wireless bridge to the linksys). Both are on 5Mhz, identical default settings in NetworkManager. There are no intentional differences in configuration between routers, I don't know what internal differences there might be. If anyone has tips on how I could try to track down the difference I'd appreciate it.
WORKAROUND AVAILABLE: The problem occurs when a dual-band network uses the same SSID name on both bands. Same SSID causes the problem on both of my routers. Different SSIDs (e.g. 2.4Ghz="mynet", 5Ghz="mynet5") fixes it on both routers. This does seem to be a fedora bug: no other wireless device in my house had a problem. Using the same SSID is recommended by many sources, because it allows devices to choose the best bandwidth automatically. Workaround: Use different SSID names for each band on a dual band router.
> WORKAROUND AVAILABLE: > > The problem occurs when a dual-band network uses the same SSID name on both > bands. Same SSID causes the problem on both of my routers. Different SSIDs > (e.g. 2.4Ghz="mynet", 5Ghz="mynet5") fixes it on both routers. > > This does seem to be a fedora bug: no other wireless device in my house had > a problem. Using the same SSID is recommended by many sources, because it > allows devices to choose the best bandwidth automatically. > > Workaround: Use different SSID names for each band on a dual band router. This workaround isn't reliable either although it does seem to reduce the incidence. My older tplink router continues not to show the problem, so something else is different but I don't know what. There is an alternate workaround for f26 at https://bugzilla.redhat.com/show_bug.cgi?id=1474308#c7 - I haven't tested it on f25.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.