OpenWrt Forum Archive

Topic: Linksys WRT1200AC v2 / WRT1900ACS v2 support

The content of this topic has been archived between 19 Apr 2018 and 3 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Mwlwifi 10.3.0.18-20160804, the wireless driver was released [1]. With this the
two new models, the WRT1200AC v2 and the WRT1900ACS v2, are now supported.

When asked about other changes, the answer was none [2], so I went and
downloaded the official sources for the WRT1200AC v2 [3]. Indeed Code Name is
Caiman again, whether intentionally or not. The same can't yet be confirmed for
the WRT1900ACS v2 as the sources are still missing.

Commit [4] adds support to OpenWrt Chaos Calmer. Commit [5] adds support to
OpenWrt Designated Driver.

Owners of a WRT1200AC v2 (Caiman) or WRT1900ACS v2 (Shelby) follow the wiki [6]
instructions for the model with the same Code Name.

First Images can be found at [7]

Happy testing!

NOTE: I'm not affiliated with Linksys, so it can't be helped if I have to amend
this post later. wink

[1] https://github.com/kaloz/mwlwifi/commit … e75707b8e1
[2] https://forum.openwrt.org/viewtopic.php … 21#p334121
[3] http://www.linksys.com/us/support-artic … Num=114663
[4] http://git.openwrt.org/?p=15.05/openwrt … 9d3347f7f3
[5] https://github.com/openwrt/openwrt/comm … 18f5f066c5
[6] https://wiki.openwrt.org/toh/linksys/wrt1x00ac_series
[7] https://downloads.openwrt.org/people/kaloz/

Edit: Adding Kaloz images.

(Last edited by sera on 12 Aug 2016, 09:16)

FAQ:

Q: What is the difference between the v1 and the v2?

A: The v2 have the powertable which determines the signal strength at which the the router transmits built in. The v1 need an externally supplied powertable to work. This lends itself for operating outside of legal limits says FCC.

(Last edited by sera on 16 Feb 2017, 18:38)

reserved

I'm a novice home user.

Kaloz's image flashed OK on my 1900ACS v2. So far, basic function is working well: can access the net, wired or wireless, and my throughput speeds (testing with iperf) are consistent with what I was getting with the stock firmware. Just doing some cursory poking around, I have noticed that I can't get control of the WiFI LEDs. I also noticed that when I had flashed back to the stock firmware, my original settings were still there.

I'm going to get it set back up and let it run for a few days. If someone would like me to test something specific, I'd be glad to help in any way I can.

Linksys stores the setting in a partition OpenWrt doesn't use by default. So if you go back to stock firmware you might indeed still have your settings intact. There is no guarantee though.

Beside the wifi leds the switch leds can't be controlled either with OpenWrt. If all else works it's a success already.

Kaloz's image is working fine on my WRT1900ACS v2. Can someone update the wiki in the appropriate way to acknowledge the v2's existence?

fluxdensity wrote:

Kaloz's image is working fine on my WRT1900ACS v2. Can someone update the wiki in the appropriate way to acknowledge the v2's existence?


I'm not sure which image in kaloz image directory works
this one openwrt-mvebu-armada-385-linksys-shelby-squashfs-factory.img?

@chinanet

You didn't tell us which model you have. openwrt-mvebu-armada-385-linksys-shelby-squashfs-factory.img is for the WRT1900ACS v1 and v2.

@sera

Could you please provide an ipk for CC 15.05.01? Kernel is 3.18.23. I tried to download from Kaloz source, but kernel version is not right.

My router is WRT1900ACS V2. Here's the problem I encountered. Maybe updating a new version wifi driver will help.
Here's the link: https://forum.openwrt.org/viewtopic.php … 89#p343789

Thanks.

(Last edited by wduwant on 15 Nov 2016, 14:52)

As the first post says, 15.05.1 is no good and starting from there is a pain. Kaloz provides complete firmware images based on CC and not a ipk for mwlwifi, flash on of those images instead and get additional bug and security fixes at the same time.

sera wrote:

As the first post says, 15.05.1 is no good and starting from there is a pain. Kaloz provides complete firmware images based on CC and not a ipk for mwlwifi, flash on of those images instead and get additional bug and security fixes at the same time.

Thanks for replying! The problem is I'm currently using ExpressVPN router firmware, it's based on CC 15.05.1. If I flash another firmware, i'll lose all functions from ExpressVPN. If I can get an ipk, at least I can try it on 15.05.1 first. I found mwlwifi package in CC download source, so I think maybe it's possible to just update mwlwifi/

(Last edited by wduwant on 16 Nov 2016, 03:44)

wduwant,

NemoAlex built binaries for new releases for as long as it was feasible on top of 15.05.1. His latest mwlwifi ipk fixes the performance issues for the old models. You can try that one even so it's supposed to be to old for the V2. The link and instructions are on the wiki.

sera wrote:

wduwant,

NemoAlex built binaries for new releases for as long as it was feasible on top of 15.05.1. His latest mwlwifi ipk fixes the performance issues for the old models. You can try that one even so it's supposed to be to old for the V2. The link and instructions are on the wiki.

Thanks for sharing. I updated a new version of ExpressVPN Router firmware. Problem solved. Not perfect but at least far better than previous one.

Hi.

I have test this images for my WRT1900ACS v2 and It have a problem with the switch. After the flash the port 6 has disappear and when I try to configure a VLAN on the lan side It fails to boot.
Finally I have installed CC and update the wifi driver like the wiki said and all works ok.

Edit: Moved here from here, @sera this link should maybe be in first post of this thread.

@starcms, Not talking about DFS, which all these units have, google 5 GHz and DFS, or look at wiki 5 GHz table for channels impacted by DFS. But DFS does enter into the discussion as 5 GHz channels are restricted as to behaviour by DFS.

DTS is loadable .dts file that describes HW attributes/parameters of device, including radios. This file is under control of anyone compiling an image, and therefore can be freely modified within the confines of available HW, and said HW capabilities. So, with a loadable DTS, an image could conceivably operate a device outside of legislated values (frequency,power) for a locale. If an image cannot override those parameters with a loadable DTS, this is not possible(well, that would be the intent).

Is a V1 flavour better? Owner would have to make that decision, I have a shelby-v2, not too concerned about the difference(I am not in the US, which is supposedly driving this by way of FCC). All channel/power settings are available, just restricted to the legal settings based on locale. Yes you can change locale, but you are using the embedded parameter table, not one that was loaded with your image.

(Last edited by Villeneuve on 16 Dec 2016, 01:32)

Villeneuve wrote:

@starcms, Not talking about DFS, which all these units have, google 5 GHz and DFS, or look at *link ommited* 5 GHz table for channels impacted by DFS. But DFS does enter into the discussion as 5 GHz channels are restricted as to behaviour by DFS.

*link ommited* is loadable .dts file that describes HW attributes/parameters of device, including radios. This file is under control of anyone compiling an image, and therefore can be freely modified within the confines of available HW, and said HW capabilities. So, with a loadable DTS, an image could conceivably operate a device outside of legislated values (frequency,power) for a locale. If an image cannot override those parameters with a loadable DTS, this is not possible(well, that would be the intent).

Is a V1 flavour better? Owner would have to make that decision, I have a shelby-v2, not too concerned about the difference(I am not in the US, which is supposedly driving this by way of FCC). All channel/power settings are available, just restricted to the legal settings based on locale. Yes you can change locale, but you are using the embedded parameter table, not one that was loaded with your image.

Thanks for all the detailed info!  I've been lurking on these board since I got my caimen v1, and been running @david's fantastic builds for almost as long, but I definitely don't know as much as I would like to.  I know you weren't talking about DFS (which is one of the few things I do understand), but I mentioned it because as you said it does enter into the discussion.  Thanks for your very detailed explanation of what DTS is!

So all wrt 1200/1900/3200 models have DFS?  I'm too new a user to post links, but according to the tech data at wikidev, it identifies the 3200acm as 4x4:4.  I know it really is 4x4:3 (if I'm wrong on this, let me know), but according to wikidev, the 3200acm not only has the Marvel 88W8964 (which is 4x4:3), but also has a Marvel 88W8887 (1x1:1) which is used as a DFS monitor.  I didn't see any info on DFS chipsets/monitors on any of the other WRT AC/ACS series routers; so that's why I was assuming they didn't support DFS (or allow use of the 5ghz channels which require it).  Please correct me where I'm wrong here.

According to the link to github that you had posted that explains difference between v1 and v2 of caimen and shelby, in the comments, @yuhhaurlin who had made the commit had said "For new device, it is embedded with power table and region code. There is no way for you to change it in order to comply with FCC rules. It also won't allow you to change region code."

That's why I was thinking not only the power tables, but even the region was locked down in the "new" (v2 of caimen and shelby) devices to the locale where the router was sold.  That way, for instance someone living in the US, couldn't simply change the locale to a region where DFS isn't needed or where more channels or higher transmit levels are allowed.

For instance on my caimen v1, I can change the region, transmit power levels, and have access to all the 5GHz channels.  Would someone with v2 (assuming they bought it in the US) be unable to do any of this (I know part of this answer goes back to one of my original questions if indeed the entire WRT AC/ACS/ACM family supports DFS or if only the 3200acm does)?

I know that's alot of questions, but I hope you can be patient with me and explain further.

Thanks very much for your time!

Villeneuve wrote:

All channel/power settings are available, just restricted to the legal settings based on locale. Yes you can change locale, but you are using the embedded parameter table, not one that was loaded with your image.

Is this actually true?  I wanted to decrease the radio transmit power on my shelby v.2, but no matter what level I set it to, my WiFi analyzer showed the power output unchanged.

I would really like to learn which radio parameters are actually under the user's control and how to modify them, but I haven't been able to find a clear description of this.

chappy wrote:
Villeneuve wrote:

All channel/power settings are available, just restricted to the legal settings based on locale. Yes you can change locale, but you are using the embedded parameter table, not one that was loaded with your image.

Is this actually true?  I wanted to decrease the radio transmit power on my shelby v.2, but no matter what level I set it to, my WiFi analyzer showed the power output unchanged.

That is what I'd expect looking at fwcmd.c. Setting the txpower and not just max txpower is disabled in the driver. One might consider this a bug as decreasing can be seen as a valid use case. Suggest you file a bug asking for that feature.

As wduwant demonstrated old drivers also work for the recent models so you might want to give that route a try. The older driver wont ask the firmware if it's ok to set power levels. Just a shame the older drivers don't perform that stellar. It'd be a workaround anyway but could shed some light on how that FCC compliance hack actually is implemented.


chappy wrote:

I would really like to learn which radio parameters are actually under the user's control and how to modify them, but I haven't been able to find a clear description of this.

The utility iw exposes pretty much all there is available to user space, suggest looking into that one for a start. Also the source code is open to read wink

---

Villeneuve,

I reserved a post for hardware differences once they are known to some degree and one for general issues. Guess the former now deserves an update, will think on how to put it, thanks for the note.

@sera

Gave the dsa implementation a spin on kernel 4.9. Using a gigabit internet connection, speed caps at ~170 Mbps as opposed to the old switch implementation where I can achieve almost line rate.

nitroshift

nitroshift wrote:

@sera

Gave the dsa implementation a spin on kernel 4.9. Using a gigabit internet connection, speed caps at ~170 Mbps as opposed to the old switch implementation where I can achieve almost line rate.

nitroshift

That is quite awful. Even though you have a Mamba I'd expect it to perform a lot better. Can you test with 4.8 as well, just in case it's a recent regression?

Grettings and happy holidays, @sera et al. I came across your post while trying to troubleshoot some issues I'm having. I have the WRT1200ACv2, and have tried both the Chaos Calmer and Designated Driver flavors of OpenWRT. Depending on which version, I have different issues.

For purposes of my set up, the WRT1200AC is strictly an access point, trunking in 5 tagged VLANs on eth1, and I have 5 each 5GHz and 2.4GHz networks, one per VLAN (maybe that's overkill for a home network, but I prefer separating traffic into home, work, printer, media devices, and also a guest network).

With Chaos Calmer, my issues have been more specifically with WiFi, which lead me to your post. More often with Windows (7 and 10, both 64 bit, on several laptops) it will stay connected but any and all data transmission stops, including ICMP echos. I've tried adjusting various aspects of the wireless connection including channel and encryption (I prefer WPA2 PSK with CCMP (AES) for security reasons, but I've also tried WPA/WPA2 Mixed Mode and/or auto cipher). When I update the mlwifi driver per the OpenWRT wiki, I get better connection on non-Windows clients, but Windows gets even worse - shows connected but NEVER transmits traffic. Checking the logs it appears to repeatedly attempt handshake, which I can provide if anyone has any input.

With Designated Driver, I can't seem to get VLAN tagging to work at all, which halts my progress there.

My question(s) for you - is there a way to incorporate a newer driver than whats listed on the OpenWRT wiki, and if so, how? Or is it better to use a different build. Once again, this is strictly for use as an AP but the multiple VLAN/SSID setup is essential to me.

Thanks in advance for any guidance you can provide.

(Last edited by dizturbedxmind on 2 Jan 2017, 04:18)

dizturbedxmind,

if you have issues with vlans the first thing I'd try is install ip-full package. Sorry can't say off the top of my head what might be going wrong but it must work respectively it's an issue that needs to be debugged and addressed. So I hope you don't give up on getting that to work all to soon.

As for building a more recent mwlwifi driver for the release, it's possible in theory, but apparently a lot more difficult than before. Can give it a try, no promises though. Building CC branch from source might be the easiest for you to get something that works well for you.

So, did build something that might work. Latest mwlwifi built for the 15.05.1 release, untested:

kmod-mwlwifi_3.18.23+10.3.2.0-20161222-1_mvebu.ipk: https://gpldr.in/v/ztyr3VWYnE/31fdrrhU6pbNjOyK
sha256sum: 520cb7e307e0fd0910dc8371b955692e59d8e298ce74074a96c3872fbd7be2de

Sera,

Thanks for the response. I tried flashing the image from Kaloz you linked in your first post (openwrt-mvebu-armada-385-linksys-caiman-squashfs-factory.img) and it seemed to soft-brick the router. Fortunately I was able to recover by toggling the power switch 4 time, waiting for the lights to come on each time. I ended up reflashing the CC image and updating the mwlwifi driver per the OpenWRT wiki, and (fingers crossed), everything seems to be ok for now. Should the issue recur, I will delve further into it. As the old addage goes "If it ain't broke, don't fix it."

The link in your last post isn't working sad

dizturbedxmind wrote:

Sera,

Thanks for the response. I tried flashing the image from Kaloz you linked in your first post (openwrt-mvebu-armada-385-linksys-caiman-squashfs-factory.img) and it seemed to soft-brick the router. Fortunately I was able to recover by toggling the power switch 4 time, waiting for the lights to come on each time. I ended up reflashing the CC image and updating the mwlwifi driver per the OpenWRT wiki, and (fingers crossed), everything seems to be ok for now. Should the issue recur, I will delve further into it. As the old addage goes "If it ain't broke, don't fix it."

The link in your last post isn't working sad

I'd highly recommend @david502's builds. They have the latest wifi driver, are based on LEDE (which branched from Open-WRT about 6 months ago and has had alot more progress made -- it looks and works just like Open-WRT). There's a link in the wiki, but here it is for you http://davidc502sis.dynamic-dns.net/index.shtml  It includes most if not all of the packages you'll need (fully featured) and regularly updated (once a week).

I'd recommend flashing back to the stock Linksys firmware, then flashing @david's build.

Some info on LEDE can be found at https://lede-project.org/, but if you didn't know, you'd think a LEDE build was Open-WRT.  Most, if not all, the devs who make firmware for the WRT series now base it on LEDE.

Edit: And for the fastest speeds and best reliability, you should always and only use WPA2 PSK with CCMP (AES)

(Last edited by starcms on 2 Jan 2017, 20:58)