WRT1900ACS/AC hardware stability issues, WAN dropping

Has anyone experienced hardware stability issues with later batches of the WRT1900ACS/AC ? We have been using the WRT1900ACS (AU/NZ, same as the AC v2) in accommodation deployments for guest wifi - using LEDE v17.01.2 and wifidog custom bin image. Only recently we have had a run of bad linksys routers - there's been random reboots and the WAN port intermittently dropping its ethernet link (ie as if someone unplugged the cable), the custom LEDE/wifidog bin image has not been changed and all the previous deployments are fine. The issues start when the connected device count gets up over 10. Some of our sites can reach > 50 connected devices. I'm wondering if there has been some change in components that go into the WRT1900 ?

A lot of improvement has been made after 17.X so I'd suggest that you try the master/head/trunk-branch instead.

The WRT1900AC v2 & WRT1900ACS are two completely different devices. They have the same specs, but are not the same device (see Devices in the WRT AC Series ToH).

  • Linksys did rebrand the 1900AC v2 as the 1900ACS, however each had their own OEM codename:
    • 1900AC v2: Cobra
    • 1900ACS: Shelby

  • 1900AC v2 firmware cannot be used on a 1900ACS or vice versa

As to stability, I've never had issues with my 1900ACS, however the most amount of devices I've had connected to it is around 30, but at any given time it's far less for active clients, usually around 15.

  • With that being said, the only way to determine what the issue is/issues are is to monitor the system log.
    • Since the log is volatile and does not survive a reboot, a syslog server, or other means of maintaining a remote log, would be recommended.

  • I do know there were previous issues with odhcpd and kernel 4.4.x (as well as 4.1.x), however IIRC, those issues no longer exist on 17.01.4+

It's always recommended to run the most recent firmware for the devices, and to ensure the most up to date mwlwifi driver is installed (garnish version: opkg list-installed | grep mwlwifi).

  • The most recent stable firmware is 17.01.5 was just released, whereas 18.06 is currently on RC2.
    • As @diizzy suggested, you may want to try 18.06, however since this is being utilized in a business, if you were to tentatively try 18.06, I'd recommend keeping 17.01.4 or 17.01.5 on the other partition, allowing for a swap back if any issues are experienced with 18.06-RC2.

What you haven't mentioned is that the majority of WRT19**/32** most likely runs master/trunk och not 18.X.
https://davidc502sis.dynamic-dns.net/ etc and pretty much all contributors runs master/trunks so I'd be a bit hesitant about recommending 18.X for the WRT series in general.

@gareth41
Keep in mind that irregardless of what tree you go for always expect that it can brick your device (ie lookup how you recover if needed).

Master/Trunk is what 18.06 was built from... last I checked, master was a few hundred commits ahead of openwrt-18.06 (I build from openwrt-18.06).

I'm not sure what branch @davidc502 builds from (master or openwrt-18.06), however his Build Info page is fairly comprehensive and it's likely on his site somewhere.

Another option if you want to stay on the 17.05.x stable would be to install the updated mwlwifi drivers. The ones you get OOTB on the 17.x images are very dated and with known problems.

@JW0914
"Compiled from Trunk sources for the Linksys 1900, 3200, and 1200 series routers"
That's the second line on the front page. =)

As for the 18.06 branch, I'm not sure of what or how things gets cherry-picked. Having a quick look at the branch shows hostap being older for instance which can affect performance. Otherwise driver and kernel is up to date (for the Marvell WRT-series at least).

@anomeome
True although you also have software such as hostap, etc which may impact on performance.

Thanks for all the help, I have always used the ACv2 firmware as I read some years back on the old openwrt forum that the ACS distributed in AU/NZ was actually the AC v2 and to use the AC v2 firmware.
I've got one of the problem routers here:
ACSv2

And an earlier one which doesn't have any issue:
ACS

Note the FCC ID is also ACv2 on both. The wifi country code on both of these also defaults to AU on openwrt/lede.

Anyway I tried the ACS firmware and flashed that, it flashed no problem also and also confirmed the board name in /tmp/sysinfo is now showing as shelby, where as when I flashed the AC v2 firmware the board showed as cobra. I'm going to test the ACS firmware and see if there is any improvement in stablity.

The hardware all seems identical, what is the actual difference between the ACSv1/v2 and ACv2 ?

I completely forgot about that... great point =]

There is a difference, but I can't recall what that difference is.

  • The second batch of 1900AC v2's were rebranded by Linksys as the 1900ACS, however the first batch of AC v2's are different, but in order to discern what that difference was, I'd have to utilize google's advanced search options to search the WRT1900AC thread on the OpenWrt forum
    • There's no guarantee with this due to the OpenWrt Forum's crash, as I'm not sure if all posts were able to be recovered.

I remember having the discussion with @sera and a few other users in the 1900AC thread specifically about this, as I wanted to do away with the 1900AC v2 in the WRT AC Series ToH, and just have the rebranded 1900ACS, however it was pointed out they are in fact two difference devices, with someone posting what the actual differences were.

Just an FYI, if you ever flash via serial, the ACS's OEM firmware name is still cobra.img / cobra.bin.

  • I'm not sure why Linksys didn't change the OEM firmware name expected by Uboot to the device's code name

The dts files differ between the cobra and _shelby_builds, don't recall the differences as being critical (or involving the radios), but probably best to stick to the right image.

1 Like

go to openwrt search linksys wrt1900acs v2 compatible for your router after that you can install wifidog.
opkg update
opkg install wifidog
use putty to install this scripts.
If you want to manage routers from cloud use cloudwifizone

I haven't heard of cloudwifizone, however a quick check reveals a lot of spelling and grammatical errors.

Additionally Chrome reports the site as not secure, so I probably wouldn't trust it with any of my customers information.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.