Bad experience using wireless adapter Netgear A6210 (MT7612U driver), looking for an alternative [SOLVED: Tp-Link ARCHER T9UH]

Here I have an USB 3.0 wifi adapter (Netgear A6210) which has always worked flawlessly on Windows: high gain (I can also catch long distance access points) and very stable connection.

Long story short: I discovered that on Kernel 4.14 is not recognized: the support for such device start on Kernel 4.19 by using the driver mt76x2u: https://cateee.net/lkddb/web-lkddb/MT76x2U.html

The USB adapter here on Linux connects to the router with a ridicolous link speed: 43 MB/s at max despite the facts that I have USB 3.0 ports, and the worst thing is that after a while it cause a complete system freeze, as example as reported here http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=4&t=2830&view=next where such user said “ With kernel 4.19 and later you will have to blacklist the in-kernel driver first, because it doesn't work, even worse - it crashed my kernel. For this create a file name /etc/modprobe.d/mt76x2u.conf with a single line inside: blacklist mt76x2u”

Obviouly I don’t wanna blacklist the driver for two reason: the first is that I need a powerful, functional and stable USB AC Wifi adapter, the second is that my old laptop (Ivy Bridge) works better with the kernel 4.14 (eg: the sleep/suspend doesn’t hangs).

I also tried to build and install the driver from here: https://github.com/kaduke/Netgear-A6210 which build and install fine, but the USB wifi adapter acts at the same way: it connects to the router with a ridicolous link speed and furthermore, when I reboot the system, on the console I get the famous message “a stop job is running” about TLP, NetworkManager and WPA supplicant which never ends and I have to shutdown the system by keep pressing the power switch on the laptop.

By searching something similar I was looking at the top model from netgear: A7000:
https://www.netgear.com/support/product/A7000.aspx which from my research should be provided with the rtl8814au chipset.
So I ask: is rtl8814au compatible with kernel 4.14 (ATM I have 4.14.155-1-MANJARO on stable branch), but most important: is stable and reliable?

If i search on pamac i see that on AUR there is available the rtl8814au-dkms-git driver ( RTL8814AU and RTL8813AU chipset driver with firmware v4.3.21) but I don’t know if is already available inside the Kernel.
By looking at github page https://github.com/zebulon2/rtl8814au the author claims “Updated with support for kernels >= 4.14.
Furthermore there is also another version: https://github.com/tpircher/rtl8814AU

Some hints/suggestions? I am puzzled.
May I ask also to @tbg? On the forum he seems an expert user about these arguments :slight_smile:

I think before you spend extra money to replace your adapter you should test the kernel 4.19 (or higher) more thoroughly. I realize you say you have suspend issues above kernel 4.14, but these may be worked around.

Does your suspend work properly if you are have your internet disabled before suspending on the higher kernels. I have written many suspend services that help with this type of situation. I would try to get your current adapter working properly on your system before spending more money on another adapter that could have the same or potentially even worse issues.

Here is a link to a thread of mine on writing services to correct exactly this type of suspend problem:

While that service is not specific to your adapter, it can be used as a template and can be easily modified to hopefully correct your suspend issue.

Generally I try to steer clear of recommending wifi adapters as this information changes rapidly and recommending something today might not work well down the road. I also only personally have experience with a limited number of adapters and if I haven't used the device myself it's hard to make a recommendation.

My best advice is to find the most up to date reviews you can online and research any prospective purchase very carefully.

Good luck.

1 Like

Thank you for yout exhaustive and gentle answer: I will report back in the next days when I will back to home; in the meantine i will do further researches.

1 Like

See also:

Thank you again for your suggestions, but unfortunately I cannot rely on PCI-E wireless adapter, since as I've said, I have an old laptop.
ATM, to be more specific, inside my laptop I have an Intel Wireless dual band 7260 card, but is not very powerful: in my case I have the router and a net HDD on the upper room: this Intel card has always been poor: doesn't have a stable link speed; the netgear one (USB external) instead, has always been stable: on Windows, also on long distance from the router and the net HDD, the link speed was rock solid.

PCI - E or USB is irrelevant, my recommendations on that thread apply to both types equally.

Have you tried tuning your Intel driver options before. Often connectivity can be I proved somewhat with special driver options.

Also, as I already stated a service may be able to work around the newer kernel issue.

Content of /etc/modprobe.d/iwlwifi.conf:

options iwlwifi power_level=5
options iwlwifi 11n_disable=1
options iwlwifi 11n_disable=8
options iwlwifi wd_disable=1

There are better options?

You could try this option:

options iwlwifi lar_disable=1

It has been helping on recent threads.

Do not use both

It is best to use only one or the other (not both).

It is usually better to use:

options iwlwifi 11n_disable=8

Reboot after any changes.

Also, have you tried:

options iwlwifi swcrypto=1

There are other options that are worth trying as well. You could also try testing older versions of the linux-firmware as some of the recent Intel firmware versions have been buggy.

I added such options and kept 11n_disable=8 and the situation is not changed. I connect to the 5Ghz net.
The problem which I have with the intel wifi adapter is that is very unstable about the the link speed.
After boot, when there is no network activity the link speed is at 866.7 MBit/s. But when there is network activity (is enough browse on internet) it also drops, eg before to 520 MBit/s and if the activityy increase also drops to 390 MBit/s. If i access to the HDD on the lan, it also drop lower, also to 267 MBit/s. Such behaviour is never occurred with Netgear A6210 on Windows: was alaways stable on 866.7 MBit/s.
P.S: the power saving is already disabled.
Output of sudo systool -m iwlwifi -av :

Module = "iwlwifi"

  Attributes:
    coresize            = "315392"
    initsize            = "0"
    initstate           = "live"
    refcnt              = "1"
    srcversion          = "5C6FBD76518435320712A3C"
    taint               = ""
    uevent              = <store method only>

  Parameters:
    11n_disable         = "8"
    amsdu_size          = "0"
    antenna_coupling    = "0"
    bt_coex_active      = "Y"
    d0i3_disable        = "Y"
    d0i3_timeout        = "1000"
    disable_11ac        = "N"
    fw_monitor          = "N"
    fw_restart          = "Y"
    lar_disable         = "Y"
    led_mode            = "0"
    nvm_file            = "(null)"
    power_level         = "5"
    power_save          = "N"
    swcrypto            = "1"
    uapsd_disable       = "3"

  Sections:
    .altinstr_replacement= "0xffffffffc0be31dd"
    .altinstructions    = "0xffffffffc0bfef20"
    .bss                = "0xffffffffc0c03ac0"
    .data.unlikely      = "0xffffffffc0c02810"
    .data               = "0xffffffffc0c00300"
    .exit.text          = "0xffffffffc0be31d8"
    .gnu.linkonce.this_module= "0xffffffffc0c03780"
    .init.text          = "0xffffffffc09ad000"
    .note.gnu.build-id  = "0xffffffffc0be4000"
    .orc_unwind         = "0xffffffffc0bf8ff9"
    .orc_unwind_ip      = "0xffffffffc0bf56e9"
    .parainstructions   = "0xffffffffc0bff0a8"
    .ref.data           = "0xffffffffc0c02900"
    .rodata             = "0xffffffffc0be4520"
    .rodata.str1.1      = "0xffffffffc0bf0093"
    .rodata.str1.8      = "0xffffffffc0bf1a58"
    .smp_locks          = "0xffffffffc0bfef3c"
    .strtab             = "0xffffffffc09ba738"
    .symtab             = "0xffffffffc09ae000"
    .text               = "0xffffffffc0bc3000"
    .text.unlikely      = "0xffffffffc0be2ee3"
    __bug_table         = "0xffffffffc0c02078"
    __jump_table        = "0xffffffffc0c00000"
    __kcrctab           = "0xffffffffc0be4420"
    __kcrctab_gpl       = "0xffffffffc0be4430"
    __ksymtab           = "0xffffffffc0be4030"
    __ksymtab_gpl       = "0xffffffffc0be4070"
    __ksymtab_strings   = "0xffffffffc0bf51e0"
    __mcount_loc        = "0xffffffffc0bfe598"
    __param             = "0xffffffffc0bfeca0"
    __tracepoints_ptrs  = "0xffffffffc0bff1c8"
    __tracepoints_strings= "0xffffffffc0bff290"
    __tracepoints       = "0xffffffffc0c03140"
    _ftrace_events      = "0xffffffffc0c02820"

By doing a research on Google about a similar problem, i read that someone suggest to install linux-firmware-iwlwifi-git 20160725.26a5c2a-1
But is very out of date:

Screenshot_2019-11-25_12-39-39

I would also try:

bt_coex_active=0

The Intel site should have the newest Intel firmware. It is also worth trying the older Intel firmware from earlier in the year.

See here for further info on firmware download etc:

Many thanks again for all your suggestions :+1:
I'm trying various combinations in the /etc/modprobe.d/iwlwifi.conf

However I discovered that options iwlwifi lar_disable=1 has no effect:

[dave@probook] $ cat /sys/module/iwlwifi/parameters/lar_disable
N

To have

[dave@probook] $ cat /sys/module/iwlwifi/parameters/lar_disable
Y

I have to use
options iwlwifi lar_disable=Y

modinfo tell me:
parm: lar_disable:disable LAR functionality (default: N) (bool)

However, currently I have, in the config file:

options iwlwifi power_level=5
options iwlwifi 11n_disable=8
options iwlwifi lar_disable=Y
options iwlwifi swcrypto=0
options iwlwifi bt_coex_active=0
options iwlmvm power_scheme=1
options iwlwifi d0i3_disable=Y
options iwlwifi uapsd_disable=1

And seems that the Intel wireless adapter is slightly less prone to lowering the link speed and seems faster to back to 866.7. I will test further combinations, also by changing the firmware and I will report back but will take some time, since I'm away.

Yes sometimes the options are like a jigsaw puzzle as to which are the best. You are getting there. I would also try without the power level option. Sometimes that can be counterproductive.

Here on such discussion: Intel Corporation Wireless-AC 9260 I read

I have 6 drivers installed :

/lib/firmware/iwlwifi-9260-th-b0-jf-b0-33.ucode
/lib/firmware/iwlwifi-9260-th-b0-jf-b0-34.ucode
/lib/firmware/iwlwifi-9260-th-b0-jf-b0-38.ucode
/lib/firmware/iwlwifi-9260-th-b0-jf-b0-41.ucode
/lib/firmware/iwlwifi-9260-th-b0-jf-b0-43.ucode
/lib/firmware/iwlwifi-9260-th-b0-jf-b0-46.ucode

I used the 46 but it is the one which was the most problematic with deconnection. (When I speedtest , it results always in a deconnnection.)
I've tested the 43 and 38 as well which were more stable but my connection is now very slow (54 Mbit/s)
The 34 has given me the best result, in term of stability and connection speed. (it is the one which is given on the Intel Drivers for Linux website)

What is the procedure to load another firmware? Also here, under /lib/firmware, I have various versions. How can chack the one which is in use an load another one?

Screenshot_2019-11-25_14-22-11

Not something I've ever had to do, but I assume if you rename the newest firmware with a .bak extension it should load the next newest firmware (and so on, etc, etc).

I tried, reboot, and the wireless adapter disappeared; I reverted the changes and the adapter was back. However: I will continue these tests better when I will have more time.

I think @dglt will help you. I assume he will advise to use older linux-firmware packages. He was replying and he's had lots of experience with these adapters.

That is more of a scattershot approach as it downgrades all of your Linux firmware packages. You may need to install the downgrade package.

I would also test your changes on different kernels as they may react differently. As I stated your suspend issues on newer kernels may be worked around.

1 Like

the instability problem with iwlwifi seems to of been fixed in the latest firmware update in regards to connections dropping.

keep the lar_disable=1module option that @tbg gave you, it's to fix an issue with Location Awar Regulatory that ends up disabling a good portion of channels/width and speed and/or stability is a problem. with that disabled i get great solid speeds.

the module options can be deceiving but 5 actually puts the adapter in it's lowest power state. change that to 0.

i'll post my current module option settings for the each related module, you can try to match the setup to see if it works out better for you.

iwlwifi
 Parameters:
    11n_disable         = "0"
    amsdu_size          = "3"
    antenna_coupling    = "0"
    bt_coex_active      = "N"
    d0i3_disable        = "Y"
    d0i3_timeout        = "1000"
    debug               = "0"
    disable_11ac        = "N"
    disable_11ax        = "N"
    enable_ini          = "N"
    fw_monitor          = "N"
    fw_restart          = "Y"
    lar_disable         = "Y"
    led_mode            = "0"
    nvm_file            = "(null)"
    power_level         = "0"
    power_save          = "N"
    remove_when_gone    = "N"
    swcrypto            = "0"
    uapsd_disable       = "3"

iwlmvm
 Parameters:
    init_dbg            = "N"
    power_scheme        = "1"
    tfd_q_hang_detect   = "Y"
mac80211
 Parameters:
    beacon_loss_count   = "7"
    ieee80211_default_rc_algo= "minstrel_ht"
    max_nullfunc_tries  = "2"
    max_probe_tries     = "5"
    minstrel_vht_only   = "Y"
    probe_wait_ms       = "500"

and make sure your regulatory domain is detected properly and is not also disabling channels

iw reg get
2 Likes

Awesomely detailed response @dglt. You da man.

2 Likes

no, you da man! :grin:

my recent involuntary commitment to screwing with every known thing in the universe has yet to provide positive results on windows but on linux is the best performing card i've ever used given the parameters are set properly. i wish i could say it was a painless journey but i'd be lying :sob:

Forum kindly sponsored by