OpenWrt Forum Archive

Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

ralfbergs wrote:

Then it's a V1.

Thanks, guys!

ralfbergs wrote:
ralfbergs wrote:

how can I find out without opening the box whether I got a V1 or V2 version of WRT1200AC?
[...]
Is there a reason to prefer V1 over V2, or the other way round?

Anyone who can help, please?

I don't want to keep the router around for much longer, but rather return it if the V1 is to be preferred...

Thanks!

@ralfbergs

I can only go by what's on the Linksys website.

http://www.linksys.com/us/support-artic … =141117#a2

Blue and Black
 
Step 1:
Flip the device over.
 
Step 2:
The model number can be found on the sticker underneath the device.  In the example below, the model number of the device is WRT54G.
 
NOTE:  For WRT1900AC, the model number is located on the front panel, below the Linksys logo. 
 
Serial and version numbers:  The serial number is located on the sticker underneath the device.  If there is no version number beside the model number, it means that it is a version 1.
 

My apologies if this has already been discussed, but I couldn't find it:  in several places it is claimed that the Linksys WRT1900ACSV2 is the same hardware as the Linksys WRT1900ACS.  I just got one of the former.  A recent OpenWRT (well, technically LEDE) snapshot installed smoothly, but I am unable to control the radio power output.  I've tried varying the radio power to settings between 2mW and 200mW and the WiFi signal monitor on my phone records the same (high) level no matter what I set it to.  Is this an issue with the mwlwifi driver in general, or something specific to the WRT1900ACSV2 hardware?  If the latter, is there hope of overcoming it or is this an instance of the manufacturer locking it down?  If the latter, I will probably ask for my money back for this "open source ready" router.

Thanks in advance for any information you can provide.

You don't state what image you installed. There is both a ACS and ACV2 image, the DTS varies.

@sera
Ran with your latest patch-set on 4.8rc5 for quite a few hours today, wifi only, but it did eventually die on me. There was no console output to capture.

Edit: Misread that, the latest mwlwifi blob was to support the V2 flavours of the ACS and 1200 supposedly. This topic was created around discussing this issue.

(Last edited by Villeneuve on 9 Sep 2016, 01:29)

I believe @chappy's experience is due to the FTC locking down the transmitting power on the V2s, however someone else will need to confirm or elaborate.

One would assume they were locked down so they couldn't be brought out of specifications... not that it will only transmit at one power level.

Just a quick check shows power levels changing, and I have acs.

Test 1

Channel 157 80mhz width @ 1000mW 27dBm.

Walked out to the end of my driveway, and checked the wifi analyzer and signal strength ranged between 48-52dBm.

Walked back inside and turned it down to 2mW, and walked back out to the street and checked the meter. Signal strength ranged between 62-58dBm which is in "Yellow" or "Caution" range.

Power levels seem to be adjusting properly as there's a significant drop off of signal strength.

One will notice the largest drop off when there are a lot of walls between the receiving device and transmitter.  In my case there is only 1 wall, so I had to walk out pretty far to test.

If there is anyone else who has many walls, the test should be more pronounced going between 1watt and 2mW.

(Last edited by davidc502 on 9 Sep 2016, 02:15)

I completely misread @chappy's post, thanks for pointing that out =]

@Villeneuve: I installed lede-mvebu-linksys-wrt1900acs.  Please note, I'm talking about an ACSV2, *not* an ACV2.

@davidc502: Thank you for the point of information.  That's what I was afraid of, but didn't want to jump to conclusions.  For the record, I'm not trying to increase the Tx power beyond FCC limits, but rather to decrease it (the wife's afraid the WiFi will cook the kids--I know, but anyway).  Surely there is no law against that.

If anybody else has hardware- or driver-specific knowledge, I'd be really grateful to hear it.

@chappy
Yes, that's why I added the edit and pointed you at the topic regarding the V2 versions..

@Villeneuve: Thanks, but I could find nothing in that thread about varying the Tx power.  Am I missing something?

I doubt it. My understanding was that this was simply a sku to deal with FCC/US OEM FW. Not really any HW modification that would cause any change in behaviour or functionality. IOW I would expect things to work with the latest mwlwifi.

Edit: Might be informative to try the latest @kaloz CC build to see if there is any difference in behaviour.

(Last edited by Villeneuve on 9 Sep 2016, 04:32)

Villeneuve wrote:

@sera
Ran with your latest patch-set on 4.8rc5 for quite a few hours today, wifi only, but it did eventually die on me. There was no console output to capture.

Mwlwifi is still the prime suspect, also someone somewhere commented that dd-wrt went back by a version (not giving a reason). You should try downgrading mwlwifi without changing anything else. If that is stable we can narrow it down further quite easily. Enough for a bug report at least.

Btw, do you have an esata disk attached?

PS: Patch to revert to old version https://bpaste.net/show/09f949a81c14

sera wrote:

@thelakesclub

You're welcome. "Finally" sounds desperate, what is there that you want that urgently.

lol. Im always a fan of testing and running the lastest and greatest.

btw some of the patches have hunks and wont apply via git am. Is there any other way to apply? e.g The "netifd" patch has got hunks for sure. Im pretty sure netifd is broken not 100% sure but.

Im not sure "if" hunks is the right word.?

Hello community
After waiting couple of months for a proper and usable openwrt/lede firmware for TP-Link Archer C2600 and not finding any, I now decided to get a Linksys WRT1900ACS instead which has a way bigger community and the vendor acknowledges and even advertises the router as being openwrt compatible.
From what i understood, the hardwares between V1 and V2 of this model, are exactly the same and the only difference is the wifi driver and location of power tables which is apparently more restrict in V2 to comply with FCC regulations.

Is that correct? and if could get either, I'm assuming V1 is the preferred one, right?

@sera, Ya, that was my intent for today. If it narrows down to that then all we really have is a blob issue, as I doubt it's the wrapper. No sata device, just an old usb device on the usb2 port holding collectd data.

@thelakesclub, I don't get any hunk failed messages on applying @sera patch-set.

@Hamy, seems like if you just read the last ~10 posts...

thelakesclub wrote:
sera wrote:

@thelakesclub

You're welcome. "Finally" sounds desperate, what is there that you want that urgently.

lol. Im always a fan of testing and running the lastest and greatest.

btw some of the patches have hunks and wont apply via git am. Is there any other way to apply? e.g The "netifd" patch has got hunks for sure. Im pretty sure netifd is broken not 100% sure but.

Im not sure "if" hunks is the right word.?

The latest and greatest is 4.8-rc5 wink. Change target/linux/mvebu/Makefile to KERNEL_PATCHVER:=4.8

Patches consists of one or more hunks. Hunks are the smallest entity that can apply or fail to apply.

The first thing that comes to mind is you might have set whitespace=error in your git configuration. So append --whitespace=warn to the git-am command or paste the log so I can fix it if there is something to fix.

@Sera

Here the logs. It going to be alittle long but I didnt leave anything to chance.

http://pastebin.com/sWshALnC

@thelakesclub

Before running git-am you have to create a new local branch, you can't apply the same patch twice. This errors are to be expected. To start over:

git checkout master
git branch -D swrt-2016-09-07
git remote update
git checkout -b swrt-2016-09-07 origin/master
git am <patches>/*
sera wrote:

@thelakesclub

It's all there, just create a local branch from openwrt/master and apply _all_ patches using git am. For convenience there is then a script swrt/build_dist.bash.

Basic steps are:

git clone https://github.com/openwrt/openwrt.git
cd openwrt
git checkout -b swrt-2016-09-07 origin/master
git am <path to patches>/*

@sera @thelakesclub, when peforming the 'git am' command, which 'path to patches' are you referring to? target/linux/mvebu/patches-4.4 or target/linux/mvebu/patches-4.1 ?

Thanks,

Mike

The path to which you extracted the @sera patch-set.

anomeome wrote:

The path to which you extracted the @sera patch-set.

So for my next dumb question... where can I find the patch-set?

Thanks,

Mike

This is the last set. Just link the moniker and look at posts to see all that have been posted.

anomeome wrote:

This is the last set. Just link the moniker and look at posts to see all that have been posted.

Thanks anomeome.. I found it right after I posted it.. RTFM right??  Thanks again.

Mike

sera wrote:

@thelakesclub

Before running git-am you have to create a new local branch, you can't apply the same patch twice. This errors are to be expected. To start over:

git checkout master
git branch -D swrt-2016-09-07
git remote update
git checkout -b swrt-2016-09-07 origin/master
git am <patches>/*

Ok. Now we are getting some where smile. I tracked down the source of the patches that are not applying.

New logs http://pastebin.com/X67zvp7Y

@thelakesclub

Looks like you try to apply the series ontop of lede, in which case you have to fix conflicts yourself. A series for lede can be found at https://github.com/lede-project/source/pull/125, though it doesn't look ready  yet.

If origin is lede and you want to add my series to the same local repo:

git remote add openwrt https://github.com/openwrt/openwrt.git
git remote update
git checkout -b swrt-2016-09-07 openwrt/master
git am <patches>/*

To list configured remotes:

git remote -v