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.

ssdnvv wrote:
Chadster766 wrote:

1) That would be great and it would help the wireless driver development testing on a different system too. I will be releasing a new updated rootfs with a .16 driver variant and some additional preconfigured scripts.

https://github.com/Chadster766/McDebian/wiki

2) I can't see why not it looks like there is a serial console on that router for u-boot access.

2) Perfect :-) (they even offer a hacker-perk in order to get exactly those things done)

1)It will take ca. 1-2 weeks before I'm ready to start (other personal projects atm). When will you have finished development of your new updated rootfs?
First some questions:
1.1 Is a openssh-server included in the image? I'm a friend of editing config-files rather than command-line instructing.
1.2 README.md states "WRT1900AC V1 (NO FAN CONTROL)". Is this correct (as v1 does have a fan that is for sure needed)?
1.3 Your current wiki doesn't include a guide how to revert to openwrt/stock firmware.
1.4 Why debian (or another full linux system) would be a must-have for me: Data security is not only about securing your internet-connections, but also doing a Full-Disk-Encryption (FDE) (with unlocking via SSH). If you've ever been a victim of burglary you will understand my concerns about this topic.
And at least that part is not practicable with openwrt - even mounting of a externel dm-crypted drive is difficult...

We need to keep McDebian specific question out of this thread. Please email me your questions using the email address listed under my profile in the McDebian repo :-)

Chadster766 wrote:
dlang wrote:

In practice, this doesn't always work. There are 'switches' that just send all vlans to every port, and even the expensive switches have failure modes that 'leak' traffic across vlans.

vlans are useful, but not good security.

I've never heard of a managed switch that leaked vlan packets. If one were to do this it would be malfunctioning majorly.

I've witnessed it on high end Cisco gear (admittedly several years ago)

while I believe that things are probably better now, the key thing to remember is that switch manufacturers main priority is to make sure that the machine that needs to get the packet, gets it. If it goes to some other machine as well, that's a degradation in efficiency, but doesn't break the network, so they are not as careful in making sure that such cases never happen.

As switch chips have become more integrated, I easily believe that they are also more reliable. But I still don't trust them. :-)

The more expensive the gear, usually the more problems it poses... bugs, bugs, and more bugs. One would think the opposite, but it just doesn't work that way. I've been fortunate to work with the high end Cisco and Juniper gear, and they all have lots of problems.

dlang wrote:
RickStep wrote:

@honicky
@dlang
@CalvinF
@davidc502

The issue that I poked at was that any new router may/maybe not (prove this) have the ability to know what country you are in by identifying your ISP.

<SNIP>

With a router behind a router Bell only sees the router (wrt1900ac) NOT what is connected to the router.

However; IF any device on the router CAN access the Internet; the WRT1900AC instantly MAY know the counrty where the owner resides.

Prove me wrong.

let me point you at this slashdot article http://yro.slashdot.org/story/16/01/13/ … to-enforce

It talks about how netflix has restrictions based on what country you are from (which are based on the IP address, exactly the thing you are proposing depending on), and how people bypass these restrictions by using a VPN.

so the result is

1. the OpenWRT device cannot depend on the IP it has on it's WAN port, as it may be inside another router

2. the OpenWRT device cannot depend on the IP address that some website sees it connect from because it could be going through a VPN

As a result, trying to ENFORCE country code settings by checking what IP address you have or are connecting from is not reliable.

It IS a good way to set the DEFAULT value for a brand new OpenWRT device that has not had any country code set on it yet. But the user still should have the ability to override this DEFAULT and set it.

Perhaps I am missing something.

First my comments are NOT about speciality business or university services to get access to the Internet; but using "off the shelf retail providers".

The country where modem is and the service provider for that modem WILL be known to anything below it; router, access point and moved along with every router and switch added.

The only exception to that will be if there is NO modem in the setup.

As far as Netflix is concerned; IF I tunnel into the US to access a US server; Netflix sees the US server and the server transfers the movie to me in Canada.  However my WRT1900AC v1 MUST go through the Bell modem to the first stop which is a Bell server, in Canada. The chances of spoofing that first leg is zero; at which point the game is up.

I have access to Bell Canada and Cogeco Cable and many re-sellers from each. All of those re-sellers MUST go through Bell or Cogeco, and I can't see either of them allowing any re-seller to pretend that they are from a different country.  The only other options are Cell networks or Satellite, neither of which are economical. Cell is trackable; Satellite may be the easiest to spoof.

So unless you can remove Canadian hardware from the loop, any router could have the capability built in to determine the country where you reside; Satellite excepted; if there is a modem in the loop.

davidc502 wrote:

The more expensive the gear, usually the more problems it poses... bugs, bugs, and more bugs. One would think the opposite, but it just doesn't work that way. I've been fortunate to work with the high end Cisco and Juniper gear, and they all have lots of problems.

These days even the ISP trusts VLAN tech. I have a MPLS delivered via ISP VLAN.

I was just referencing general issues, and nothing specific like vlans.

ssdnvv wrote:

@northbound: Thanks again. I think I will try this at the weekend

You are welcome.

So far so good. Forgot to mention there will be a share1 and share2 under /mnt
Also used the nand patch. And the rest is about the same.

Just a general question. Has anyone noticed on a wrt1900acv1 that the transfer speeds increasing  have followed the trunk more that the mwlwifi.ko itself? Using 10.3.0.13?

Anyone with a 4.4.0 build notice wan<->lan speed increase? On my ISP 50 Mbps, doing a large file transfer, where I have consistently seen ~5.8 MBs, starting this week with 4.4 final I am now consistently seeing ~6.7 MBs. I seem to remember some talk regarding mvneta acceleration to be added. Has NAT improved?

Kaloz is still alive? What are you waiting bud to create a new sysupgrade? November 27 2015 is now far away... wink

(Last edited by roylaprattep on 15 Jan 2016, 02:15)

anomeome wrote:

Anyone with a 4.4.0 build notice wan<->lan speed increase? On my ISP 50 Mbps, doing a large file transfer, where I have consistently seen ~5.8 MBs, starting this week with 4.4 final I am now consistently seeing ~6.7 MBs. I seem to remember some talk regarding mvneta acceleration to be added. Has NAT improved?


I am seeing the same on 4.4.0, r48233.

If it matters I was talking lan. Usb transfer using samba and vsftpd. on a usb3 drive using ntfs  My wan is slow so I can't compare.

No issues downloading 900+Mbps as long as I switch interrupts (wifi on cpu0 and ethernet on cpu1).  This is on kernel 4.1.13.

What I like is that it's stable... no more crashes. Since the wife works from home, and I'm beginning to work from home more often, so stability is needed.

roylaprattep wrote:

Kaloz is still alive? What are you waiting bud to create a new sysupgrade? November 27 2015 is now far away... wink

You do realize there is more to choose from than waiting on Kaloz to build images?

WIKI - Linksys WRT1900ac - firmware images

anomeome wrote:

Anyone with a 4.4.0 build notice wan<->lan speed increase? On my ISP 50 Mbps, doing a large file transfer, where I have consistently seen ~5.8 MBs, starting this week with 4.4 final I am now consistently seeing ~6.7 MBs. I seem to remember some talk regarding mvneta acceleration to be added. Has NAT improved?

I am capped at 25 Mbps so for me internet is always just shy of 3MB/s

But...  since my second unit is a wireless client of the fist and hence does WAN<->LAN:

1. ave of 9 MB/s via the 5 GHz radio at VHT80
2. ave of 7 MB/s over 2.4 GHz at HT40

Both have txpower set to 27, and playing with this does make a big diff in both directions smile

Cheers

I be confused. My post was regarding WAN download speed, not WLAN wifi throughput.

Assuming my ISP is not giving me a New Year bonus, the differential I am seeing on a relative basis is a significant percentage increase. So this device running 4.4 final is apparently processing many more packets per second than running either 4.1.* or 3.18.*. Also I did not see any increase with any of the 4.4rc* kernels, in fact rc8 seemed abysmally slow on a relative basis.

So to your 25 Mbps / ~3MBs values, which would have been close to what I was seeing pre-4.4.0. If you are running 4.4, has your MBs values increased to say ~3.4 MBs?

And the interesting part, if the increase is true, from whence did it come?

anomeome wrote:

I be confused. My post was regarding WAN download speed, not WLAN wifi throughput.

Assuming my ISP is not giving me a New Year bonus, the differential I am seeing on a relative basis is a significant percentage increase. So this device running 4.4 final is apparently processing many more packets per second than running either 4.1.* or 3.18.*. Also I did not see any increase with any of the 4.4rc* kernels, in fact rc8 seemed abysmally slow on a relative basis.

So to your 25 Mbps / ~3MBs values, which would have been close to what I was seeing pre-4.4.0. If you are running 4.4, has your MBs values increased to say ~3.4 MBs?

And the interesting part, if the increase is true, from whence did it come?

I have a 150mbs download from my ISP. I WAS getting about 120mbs download. I just did a couple more tests and I am getting right now, 155mbs-165mbs download.

Incidentally, it is now equivalent to DDWRT.

Edit:
Movie download peaked a 4.5mbs

(Last edited by mojolacerator on 15 Jan 2016, 05:00)

anomeome wrote:

I be confused. My post was regarding WAN download speed, not WLAN wifi throughput.

Assuming my ISP is not giving me a New Year bonus, the differential I am seeing on a relative basis is a significant percentage increase. So this device running 4.4 final is apparently processing many more packets per second than running either 4.1.* or 3.18.*. Also I did not see any increase with any of the 4.4rc* kernels, in fact rc8 seemed abysmally slow on a relative basis.

So to your 25 Mbps / ~3MBs values, which would have been close to what I was seeing pre-4.4.0. If you are running 4.4, has your MBs values increased to say ~3.4 MBs?

And the interesting part, if the increase is true, from whence did it come?

I promise to learn to read one of these days (slaps forehead)...

Will spin up torrent and test...  latest Bond is available smile

Cheers

** EDIT ** Nope....  no goodies for me...  2.9 MB/s peak....

(Last edited by doITright on 15 Jan 2016, 04:24)

davidc502 wrote:

David's Snapshot Builds W/LuCi - http://personalpages.tds.net/~davidc502/mvebu/

Never could get WiFi working right with this router. Tried the official 15.05 from https://wiki.openwrt.org/toh/linksys/wrt1900ac
Plus the RC3 version. Both were completely bunk in terms of WiFi, constant drops, speeds around 1 to 2 MB/s.

Now with your build, 40 to 50 MB/s on AC, stable, thank goodness.

I didn't bother to read any of the posts here, too much information that's not well organized. If anybody else is perusing this forum for easy information, use David's build for good WiFi!

kirkgbr wrote:
roylaprattep wrote:

Kaloz is still alive? What are you waiting bud to create a new sysupgrade? November 27 2015 is now far away... wink

You do realize there is more to choose from than waiting on Kaloz to build images?

WIKI - Linksys WRT1900ac - firmware images


Great images here in this forum as well: https://forum.openwrt.org/viewtopic.php?id=50914

comes with luci, adblocking, torrent, tor, etc.....

also very current. running 4.4.0 - r48233, right now.

comzee wrote:
davidc502 wrote:

David's Snapshot Builds W/LuCi - http://personalpages.tds.net/~davidc502/mvebu/

Never could get WiFi working right with this router. Tried the official 15.05 from https://wiki.openwrt.org/toh/linksys/wrt1900ac
Plus the RC3 version. Both were completely bunk in terms of WiFi, constant drops, speeds around 1 to 2 MB/s.

Now with your build, 40 to 50 MB/s on AC, stable, thank goodness.

I didn't bother to read any of the posts here, too much information that's not well organized. If anybody else is perusing this forum for easy information, use David's build for good WiFi!

Appreciate the kudos!  Yeah, I have no issues getting those kind of wifi speeds with the test I've run. Glad you are as well.

Of course wifi is very fickle and evironment has so much to do with performance, so everyones results are likely to vary.

Best Regards,

P.S. if you plan to stay on that image, be sure to grab the packages you need from trunk repo ahead of time. As trunk evolves the repository will be updated with new Kernel builds, which will make those packages useless.

For what it's worth, I believe that the currently released code for 15.05 CC has severe limitations on wifi speeds.  I reverted some hacks I had in place to the committed code and my wifi link speeds on 5GHz went to as low as 3.5 Mbps (yes, Mbits/s, not MB/s).

I have isolated this to the interaction between the wifi driver mwlwifi and the mac80211 packages -- if I build with the released CC package, speed is poor.  If I update to my hacked package, I get 49MB/s on the 5GHz link.  That's not a typo.

The hack:
pull the 100-drop_old_api.patch from the mwlwifi package in trunk, and put it in kernel/mwlwifi/patches.  This will break your build unless you do the next step as well:
Update Makefile in package/kernel/mac80211 to pull a newer version.  I'm using 2015-10-26.  This will likely require you to fix build issues as there are a lot of interdependencies that are no longer consistent between CC and trunk.  For example, I just blew away a bunch of brcm patches since I'm not building anything for that platform.

Just thought I'd mention it since I see a lot of complaints about speed.  I'll mention again that this applies to the CC-based code only.  Anything trunk-based should already have these changes.  Good luck!

p.s. I'd likely fix all this and submit a pull request to get it committed but it looks to me like there are interdependencies with other platforms that I'm unfamiliar with and couldn't test, so I'm going to leave this one to the developers (or anyone with the expertise).  I'm not on the latest trunk mac80211 with this hack and these interdependencies may be resolved.

InkblotAdmirer wrote:

For what it's worth, I believe that the currently released code for 15.05 CC has severe limitations on wifi speeds.  I reverted some hacks I had in place to the committed code and my wifi link speeds on 5GHz went to as low as 3.5 Mbps (yes, Mbits/s, not MB/s).

I have isolated this to the interaction between the wifi driver mwlwifi and the mac80211 packages -- if I build with the released CC package, speed is poor.  If I update to my hacked package, I get 49MB/s on the 5GHz link.  That's not a typo.

The hack:
pull the 100-drop_old_api.patch from the mwlwifi package in trunk, and put it in kernel/mwlwifi/patches.  This will break your build unless you do the next step as well:
Update Makefile in package/kernel/mac80211 to pull a newer version.  I'm using 2015-10-26.  This will likely require you to fix build issues as there are a lot of interdependencies that are no longer consistent between CC and trunk.  For example, I just blew away a bunch of brcm patches since I'm not building anything for that platform.

Just thought I'd mention it since I see a lot of complaints about speed.  I'll mention again that this applies to the CC-based code only.  Anything trunk-based should already have these changes.  Good luck!

p.s. I'd likely fix all this and submit a pull request to get it committed but it looks to me like there are interdependencies with other platforms that I'm unfamiliar with and couldn't test, so I'm going to leave this one to the developers (or anyone with the expertise).  I'm not on the latest trunk mac80211 with this hack and these interdependencies may be resolved.

Interesting.... looks like a couple changes today (mwlwifi and mac80211) have made a diff....

@ 4.4.0 with r48251 I see perhaps a 10 % improvement in wifi transfer rates over yesterday

I am happy with 9 MB/s on 2.4, and not quite happy with 11 MB/s on 5 GHz

....  but what you are seeing is amazing (49 MB/s)

Cheers

InkblotAdmirer wrote:

For what it's worth, I believe that the currently released code for 15.05 CC has severe limitations on wifi speeds.  I reverted some hacks I had in place to the committed code and my wifi link speeds on 5GHz went to as low as 3.5 Mbps (yes, Mbits/s, not MB/s).

I have isolated this to the interaction between the wifi driver mwlwifi and the mac80211 packages -- if I build with the released CC package, speed is poor.  If I update to my hacked package, I get 49MB/s on the 5GHz link.  That's not a typo.

If you don't mind me asking, what utility do you use to measure your speeds?