Linksys WRT1900ACS - Wifi Connectivity Issues on 19.07.0

Installing and Using OpenWrt
1

Hello Everyone,

I am sad to say that OpenWRT from version 18.06.2 onwards (including 19.07.0) the 5ghz wifi on the Linksys WRT1900ACS (i have the v2) is not stable.

I have tried every version after 18.06.1 and every single one has the same problem. The Wifi remains up for about a day then starts becoming unstable by not allowing new clients to connect and then slowly dropping clients over time.

Every day or so the radio requires a manual restart to restore wifi functionality.

When I revert back to 18.06.1 everything works perfectly.

It's sad because I really enjoy getting new features and security upgrades for my router...

If anyone has any suggestions or advice please let me know. It would be awesome to use the latest versions of OpenWRT. :frowning:

Thanks.

2 Likes
2

Marvell sold off this business unit and wifi driver development basically stopped a year or so ago.

In the future, all in one devices are less of a thing. I suggest to replace the router function with something like a Raspberry Pi 4 and a smart switch... replace the wifi function with separate access points. Access points are more or less dumb devices compared to routers where firewalling and DNS and SQM take place. I'm considering using TP-Link EAP devices with stock firmware as my next round upgrade in a few years. I run WRT32x access points and also experience some instability.

3

I am using a WRT1900ACSv2. I installed 18.06.4 shortly after it became available and ran it without issue. I installed 19.07.0 yesterday and have had no problems so far, but it may be too early to tell.

I have always had the best luck upgrading saving my settings, upgrade not choosing to keep the settings, and then loading the saved settings after.

4

Thanks for the reply. I've noticed that some seem to have no issues while others like myself are having problems.

I have tried all of the settings approaches you have and nothing seems to help. With the 19.07 install I decided to not copy the settings and start from scratch. Still not working.

I do have a lot of wifi clients, like google homes and a couple of cell phones a laptop and a bunch of chromecasts. So maybe my setup is slightly different the most people using the WRT1900ACSv2.

I am considering trying the builds from: https://dc502wrt.org/

5

Drivers for the wireless chipset at release 18.06.1 come from upstream version of 2018-06-15, while drivers on further releases come from upstream version of 2018-11-14. So, it looks like something changed on the wireless drivers between 18.06.1 and 18.06.2.

Drivers at release 19.07.0 come from upstream version 2019-03-02 (and that is the last commit), but you already mentioned this release is not stable for you. And @davidc502's builds are always based on latest commits; you can try them, but I would not expect much.

If you are familiar with the build procedure, you could build "kmod" packages for 19.07.0 (or whatever version of your choice) using drivers from the latest upstream version that works for you (2018-06-15, apparently), just changing the proper "Makefile". If you are not, drop a note here and I will try to build them for you.

6

I have used David's builds in the past. You will be using the same drivers. David's builds provide a convenient set of packages, but no harm in trying.
I currently have 7 5G and 6 2.4G devices connected. If you have an android phone you might try using a wifi analyzer to check what channels are being used in case that is a problem.

7

Thanks for the information. I would appreciate a build of those older wifi drivers. I am a web developer so hardware drivers are a bit out of my comfort zone.

8

Thanks @dos. I have been using wifi analyzer and have always kept the router away from highly used channels around me.

I have tried EVERYTHING and the only thing that works is OpenWRT 18.06.1. It's really really strange.

9

Ok, which release? 19.07.0?
My memory tends to be fragile, if I do not answer in a couple of days, feel free to poke me.

10

Yes please, and thank you.

11

Try the packages here, please:
https://drive.google.com/open?id=10RaUzqiC_hVEztv2X4sNJSaa-5teo7BQ

For your device, you will need the "kmod-mlwifi_..." and "mwlwifi-firmware-88w8864_..." packages.

12

The packages installed correctly but... now the wireless devices just say "Device is not active" and I get no wireless connection at all:

image
image955×501 32 KB 

Tue Jan 14 17:56:58 2020 user.notice mac80211: Failed command: iw phy phy0 set antenna 0xffffffff 0xffffffff
Tue Jan 14 17:56:58 2020 daemon.notice netifd: radio0 (4652): command failed: Not supported (-95)
Tue Jan 14 17:56:58 2020 user.notice mac80211: Failed command: iw phy phy0 set distance 0
Tue Jan 14 17:56:58 2020 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Tue Jan 14 17:56:58 2020 kern.debug kernel: [  226.393816] ieee80211 phy0: change: 0xffffffff
Tue Jan 14 17:56:59 2020 kern.info kernel: [  226.472077] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: wlan0: INTERFACE-ENABLED
Tue Jan 14 17:56:59 2020 daemon.err hostapd: nl80211: Could not configure driver mode
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: nl80211: deinit ifname=wlan0 disabled_11b_rates=0
Tue Jan 14 17:56:59 2020 daemon.err hostapd: nl80211 driver initialization failed.
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: wlan0: interface state UNINITIALIZED->DISABLED
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: wlan0: AP-DISABLED
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: wlan0: CTRL-EVENT-TERMINATING
Tue Jan 14 17:56:59 2020 daemon.err hostapd: hostapd_free_hapd_data: Interface wlan0 wasn't started
Tue Jan 14 17:56:59 2020 daemon.notice hostapd: wlan0: INTERFACE-DISABLED

If you have any other suggestions I would be grateful, but it looks like I am going back to 18.06.1 :slight_smile:

13

@eduperez Thanks for your help. I installed the latest davidc build and I will see how that goes.

If the wifi still fails I will revert to 18.06.1.

Thanks again! Very much appreciated.

14

I have a WRT1900ACSv2 which I compiled 19.07.0 myself and the issue I'm having at the moment is that I can't change the transmit power. It just doesn't do anything.

15 
cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/info
power table loaded from dts: no

v2 flavours do not load a power table

16

I can understand the use of a high power limit to comply with regulations but I have two AP's and I need to be able to turn them down. Is there a workaround for this?

I did the 'iw phy0 info' command and is shows my maximum TX power for 5GHz is 23dB. Here is the output of that command

Wiphy phy0
        max # scan SSIDs: 4
        max scan IEs length: 2247 bytes
        max # sched scan SSIDs: 0
        max # match sets: 0
        max # scan plans: 1
        max scan plan interval: -1
        max scan plan iterations: 0
        Retry short limit: 7
        Retry long limit: 4
        Coverage class: 0 (up to 0m)
        Device supports AP-side u-APSD.
        Device supports T-DLS.
        Available Antennas: TX 0 RX 0
        Supported interface modes:
                 * managed
                 * AP
                 * AP/VLAN
                 * monitor
                 * mesh point
        Band 2:
                Capabilities: 0x106f
                        RX LDPC
                        HT20/HT40
                        SM Power Save disabled
                        RX HT20 SGI
                        RX HT40 SGI
                        No RX STBC
                        Max AMSDU length: 3839 bytes
                        DSSS/CCK HT40
                Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
                Minimum RX AMPDU time spacing: 4 usec (0x05)
                HT TX/RX MCS rate indexes supported: 0-23, 32
                VHT Capabilities (0x33837930):
                        Max MPDU length: 3895
                        Supported Channel Width: neither 160 nor 80+80
                        RX LDPC
                        short GI (80 MHz)                                                                                 SU Beamformer
                        SU Beamformee
                        RX antenna pattern consistency
                        TX antenna pattern consistency
                VHT RX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT RX highest supported: 0 Mbps
                VHT TX MCS set:
                        1 streams: MCS 0-9
                        2 streams: MCS 0-9
                        3 streams: MCS 0-9
                        4 streams: not supported
                        5 streams: not supported
                        6 streams: not supported
                        7 streams: not supported
                        8 streams: not supported
                VHT TX highest supported: 0 Mbps
                Frequencies:
                        * 5180 MHz [36] (23.0 dBm)
                        * 5200 MHz [40] (23.0 dBm)
                        * 5220 MHz [44] (23.0 dBm)
                        * 5240 MHz [48] (23.0 dBm)
                        * 5260 MHz [52] (20.0 dBm) (radar detection)
                        * 5280 MHz [56] (20.0 dBm) (radar detection)
                        * 5300 MHz [60] (20.0 dBm) (radar detection)
                        * 5320 MHz [64] (20.0 dBm) (radar detection)
                        * 5500 MHz [100] (27.0 dBm) (radar detection)
                        * 5520 MHz [104] (27.0 dBm) (radar detection)
                        * 5540 MHz [108] (27.0 dBm) (radar detection)
                        * 5560 MHz [112] (27.0 dBm) (radar detection)
                        * 5580 MHz [116] (27.0 dBm) (radar detection)
                        * 5600 MHz [120] (27.0 dBm) (radar detection)
                        * 5620 MHz [124] (27.0 dBm) (radar detection)
                        * 5640 MHz [128] (27.0 dBm) (radar detection)
                        * 5660 MHz [132] (27.0 dBm) (radar detection)
                        * 5680 MHz [136] (27.0 dBm) (radar detection)
                        * 5700 MHz [140] (27.0 dBm) (radar detection)
                        * 5720 MHz [144] (disabled)
                        * 5745 MHz [149] (13.0 dBm)
                        * 5765 MHz [153] (13.0 dBm)
                        * 5785 MHz [157] (13.0 dBm)
                        * 5805 MHz [161] (13.0 dBm)
        valid interface combinations:
                 * #{ AP } <= 16, #{ mesh point } <= 1, #{ managed } <= 1,
                   total <= 16, #channels <= 1, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz, 160 MHz }

        HT Capability overrides:
                 * MCS: ff ff ff ff ff ff ff ff ff ff
                 * maximum A-MSDU length
                 * supported channel width
                 * short GI for 40 MHz
                 * max A-MPDU length exponent
                 * min MPDU start spacing
        Supported extended features:
                * [ RRM ]: RRM
                * [ CONTROL_PORT_OVER_NL80211 ]: control port over nl80211
17

I cant. Due to their (mis)interpretation of one country's regulatory body rules, they have pegged the TX power at the maximum permissible; but it is what it is. If your interest in the region code unlocking PR is around this issue, that PR will not allow you to change TX levels.

18

Have you tried the httpstorm patches to see if they solve the TX power override issue?

19

Someone replied to one of the GitHub pages found here > https://github.com/openwrt/openwrt/pull/2397#issuecomment-576282087 with the links to the two patches. I will be trying them over the weekend and I'll get back to you.

20

my understanding is the tx power is locked at high in hardware