bullfrogreal
commented
7 years ago A little unimpressed with the (lack of) replies here but meh... best effort is best effort so can't complain.
Anyway, decided to dig deeper, installed other drivers, enabled debug info and found the culprit.
Apparently either the chip, the device itself or the base rtl driver (or a mix of those) are not able to get through band scanning fast enough so the gaps I saw were caused by NetworkManager doing the usual regular iw scan.
If you find yourself in the same situation, one of the ways to fix it is to force NetworkManager to join a specific BSSID (may be not great if you are on a laptop and moving a lot around, though). That way the scans will not happen anymore at regular intervals. Another more effective solution would be to move away from NetworkManager completely and handle your connectivity in other ways.
Hope this can help others facing a similar problem.
Hi all, first time I write here so please be gentle! :)
I got this usb wifi adapter after long time checking online and trusting that the RTL chip could work decently on Linux. I'm using this with my desktop, running Ubuntu 16.04. My router is just in the next room and currently I'm connected using a "hacked together" wifi bridge, which works great and fast but it isn't convenient for me, with all the desk real estate that it's using. A wifi adapter seems the right compromise to make.
Now, I followed the instructions here and all looked like working fine. Adapter recognized, connects to router (a Linksys EA9500) and speed is decent for such a small thingy. Browsing and casual internet use works ok. But suddenly, I realized I had a couple of issues. Note that all the config bits are done by NetworkManager.
FIRST ISSUE
First, the "easy problem"... the adapter sometimes just decides to stop working... when it does, it still shows in iwconfig but it's dead... cannot scan, cannot connect... modprobe -r and reload brings it back.
Here's what I get when I plug in the adapter:
Here's iwconfig while it's working:
This is what dmesg shows when it stops (nothing before that "disconnect or roaming" bit):
And this is how iwconfig shows after it goes dead:
If I have a ping in the background, constantly using the connection, it doesn't go down so often but it still does so it doesn't seem strictly a power saving thing. FWIW, power saving looks like being off from what iwconfig says and a further "iwconfig wlan0 power off" returns:
SECOND ISSUE
The second, more troublesome (but fun) issue is that I noticed regular drops in connectivity... like 5 seconds or so every few minutes. I dug deeper and here's what I found running a simple ping from my desktop to my router/laptop:
The interesting bits from tcpdump logs which drove me to the above are (192.168.1.98 is desktop, Milhouse is my router):
here it works:
then it suddenly looks like no answer is coming back:
and after about 4-5 seconds, looks like the answers to those packets are coming back all in one shot:
Finally, here is where you can see the patterns:
The intervals start sometime at ~60 seconds right after the driver is loaded, then increase to ~80, ~100 and finally ~120 seconds thereafter as you see above.
To note that running tcpdump on the other side (laptop) doesn't show ANY packet coming during those few seconds, seeing them all in one shot afterwards (and that's why the receiving side replies in bulk for those 4 packets seq 65-68). It makes me think that perhaps the adapter as some internal queue which suddently stops being processed for those few seconds and tcpdump is not aware of it.
The adapter is cheap and it isn't a big deal if I have to throw it in the trash but it's an intriguing problem and I enjoyed the digging but now I've reached the end of my sparse knowledge and looking for someone willing/able to take a stab at it. Oh, and yeah, it could be that this is a faulty adapter, perhaps... I don't have another machine to use it on and test Windows drivers... I may look for someone to lend me something to experiment with. Just that faulty seems an odd chance when there are such regular patterns.
Happy to provide other logs and outputs if needed. Bullfrog