Wifi issues with TL-WN822N USB adapter: it connects but seems to shut down after few minutes despite updates
- Inicie sesión ou rexístrese para enviar comentarios
Dear Trisquel community,
First of all, thanks to all of you for bringing Trisquel alive. I just switched from Windows, and I am completely discovering a new world in which I feel active, getting in control, and it is awesome. However, as a newbie, I face wireless problems that seem to be hard to solve. And believe me, I looked for updating the drivers, the kernel, opening the network configuration with a bunch of different commands but still, the same problem remains. I am using a wireless USB Adapter called TP-Link TL-WN822N which, according to what I gather from the internet, is a compatible firmware that would work on Trisquel almost, I assume, out of the box. So that thing is recognized by my computer when I first log in, and I can browse few minutes on the net, but then, nothing. It is still recognized by the computer, and it seems to connect to the internet, but gives nothing except blank pages that seems to load eternally. In such a situation, I have to plug the adapter off, wait few seconds, and plug it in to continue browsing. It is very annoying as I can’t use wifi while I am using a laptop for professional purposes. I started thinking about installing the firmware for my Intel AC-7620 wireless card, but I really want to respect Trisquel’s philosophy as I truly love it, which is why I choose this OS at the end... I may buy a Penguin wireless adapter that seems to work also out of the box, but I am afraid to encounter the same problem. I don't know what to do.
I am sorry for this long message and for such stupid questions.
Anyway, thanks a lot for any answer and for your patience.
I wish you a very nice day.
Yours faithfully,
Philippe
I have WN722N dongle and I can confirm the issue.
It looks like it gets no DNS lease when this happens. The connection doesn't drop completely but eventually there's an error "server not found".
I remove the dongle and reinsert it, and it works again.
I use a TL-WN722N dongle all day long. I do not have any issue. Let us first check, with 'lsusb', that we really have the same chipset:
$ lsusb
(...)
Bus 001 Device 002: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
(...)
If it is the case, the difference may have to do with the fact that I am using GNOME Shell. There is not much to install on top of Trisquel 8 to try GNOME Shell (the "gnome-shell" and "nautilus" packages are the minimum to get a usable desktop): https://trisquel.info/en/wiki/installing-gnome-shell
You would then see if, really, the dongle better behaves on GNOME Shell, for some mysterious reason.
Thanks to both of you for your answer. That's really unfortunate that loldier faces the same problem.
Here is the output of the "lsusb" command, sorry for non-appropriate display:
Unknown line at line 2468
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 04f2:b3fd Chicony Electronics Co., Ltd HD WebCam (Asus N-series)
Bus 003 Device 002: ID 062a:5918 MosArt Semiconductor Corp.
Bus 003 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
It's the same chip but different from the OP. The OP has a Realtek and it probably shouldn't work.
Bus 001 Device 008: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
I have to be clear, this is on my NUC which has Ubuntu 18.04 at the moment. It's possible these are different issues as I use Dovado Tiny AC to create a wireless network and there have been some issues with it (Dovado) before.
I'm having issues with the wireless symbol going out and being replaced with a question mark (on Ubuntu, that is).
> to try GNOME Shell and see if really, the dongle better
> behaves on GNOME Shell (for some mysterious reason):
Is there reason to think this might be the case? My USB dongle works pretty well but occasionally needs to be removed and reinserted. This is the case whether I use nm-applet (the frontend to network-manager used in MATE) or nmcli (the command-line interface to network-manager). I recall GNOME using something other than nm-applet, but I don't know what it is called. Is there reason to think it would get better results than nm-applet or nmcli?
Is there reason to think this might be the case?
Well, I have the same dongle as loldier, like him I use Trisquel 8, but I do not face any issue with Wifi. The main difference between the system I run and Trisquel's default is the GNOME session. That is why I suggest to investigate in that direction.
You are certainly right that it is not GNOME Shell itself that could have any influence on the Wifi. I was thinking of a dependency of it. I have no idea which one it could be (APT's log on my system does not help much in that case: right after logging into my freshly installed Trisquel 8, I installed the "gnome-shell" package along with *many* other packages).
I recall GNOME using something other than nm-applet, but I don't know what it is called. Is there reason to think it would get better results than nm-applet or nmcli?
I do not know. Maybe it is the other way around (i.e., the processes that NetworkManager executes may be different): looking in the GNOME System Manager at the dependencies of NetworkManager, I see dhclient and dnsmaq. Is it the same with the default desktop environment?
Please note that each model of USB WLAN adapter has different hardware revisions, which may use completely different chipsets from different vendors.
And also obviously your USB WLAN adapter is not from Atheros and therefore cannot be supported by Trisquel.
For more details, see wikidevi.com
To the best of my knowledge, only few earlier revision(s) of TL-WN822N use(s) Atheros chipset, whereas all later revisions are Realtek based.
I really know how to install non-free firmware to "support" those awkwardly and defectively designed WLAN adapters (all non-Atheros ones, including Intel, Realtek, Broadcom, etc.) but I cannot post the methods here because of the community guideline.
And also obviously your USB WLAN adapter is not from Atheros and therefore cannot be supported by Trisquel.
Some Realtek chipset work with Trisquel. Some have even started to work with Trisquel 8, as I experienced myself: https://trisquel.info/forum/trisquel-8-codename-flidas-release-candidate-ready-testing?page=1#comment-130698
I have RTL8188EU but it's not recognized let alone functional on Trisquel 8.
Personnaly, I use Gnome everyday as desktop environment, but it does not solve the problem. I should consider buying a Penguin wireless adapter then. Thanks a lot for all your messages.
Like Magic Banana, I'm running a TP-LINK TL-WN722N since 3 days without any issue like Philippe describe.
My device :
lsusb
Bus 001 Device 002: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
Philippe, look at :
https://h-node.org/wifi/view/en/357/Atheros-Communications-Inc--AR9271-802-11n
and at (it's the chip of your current TP-LINK TL-WN722N) :
https://h-node.org/search/results/en/1/search/wifi/RTL8192CU
Over the last few days I've experienced the same issue while using WebHTTrack to clone
a big website (ca. 30 GB so far, maybe twice that in all ... eventually) but the download
stalls after varying periods. My ThinkPenguin dongle is TPE-N150USB, for which:
> lsusb
...
> Bus 002 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
...
WebHTTrack opens & closes four ports as it grabs the linked webpages. There are many .wav
files, and some do not open right away. Eventually everything stops, and when I attempt
a reconnection to my wireless network, I get the following message:
"Connection activation failed"
"(24) Timeout was reached"
Thinkpenguin Support suggests that this may be a firmware issue and sent me the
appropriate file and instructions, but I'm not going to try for a while because of
competing time-sensitive issues. I'm running Flidas on a Lenovo T420 laptop and storing
the data on a USB-connected IOMEGA 1.0TB hard drive. Lots of room there.
This issue has surfaced only recently. I have cloned other websites with Belanos without
any issues.
George Langford
Some time ago I wrote:
"WebHTTrack opens & closes four ports as it grabs the linked webpages. There are many .wav
files, and some do not open right away. Eventually everything stops, and when I attempt
a reconnection to my wireless network, I get the following message:
"Connection activation failed"
"(24) Timeout was reached"
This morning I ducked my own problem with WebHTTrack by moving the external USB-connected
hard drive to a desktop PC that's also outfitted with Trisquel (Flidas) and got it to run
by just doing sudo update-grub after booting up the PC once and then restarting to choose
the OS in the external hard drive. Now that drive (the same one that was having trouble
before) is continuing the capture of the remote website, and that operation is ongoing,
so far OK, even with occasional bouts of zero connections, but with no zero transfer rate
situations. This is a handy fix for me because I have several occasional-use desktops that
I saved from the scrap heap by installing Trisquel-friendly motherboards and Trisquel OS's.
When WebHTTrack resumes an interrupted download, it goes back over the files that it got
before and checks them for changes. This takes quite a while in my present project, so the
repeated stalls meant that I was making zero progress with each restart, except for the
updates to the more recently downloaded pages.
...
Still watching WebHTTrack at work, two-and-a-half hours into the resumed interrupted download.
...
Quite often it gets to a point where no ports are open ... but there's still an indication
of a finite, non-zero transfer rate. That may be an artefact from the use of some averaging
in the rate calculation, but now that the host PC is hard-wired to the FIOS installation,
these sometimes lengthy periods with no open ports do not stop WebHTTrack.
Not a universal solution, just some observations of WebHTTrack's operation with the wi-fi
system out of the loop. Nonetheless, it's also running pretty fast at > 1MB/sec.
ThinkPenguin support suggested that I should check whether the download is overloading the
power supply of the USB port. That's not an issue with this IOMEGA external hard drive,
because it has a separate power supply from a wall wart. It's also staying quite cool to
the touch.
George Langford
- Inicie sesión ou rexístrese para enviar comentarios