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.

doITright wrote:
sera wrote:
anomeome wrote:

Some hacking has started on 4.6 and 4.7.

Thanks for the links. 4.6 doesn't have anything of interest as far as I'm aware but I certainly will try 4.7 using the commit above as basis.

Has anyone had any luck with 4.7?  My first attempt at building @ this kernel level bombed sad

Cheers

root@wrt1900acs:~# uname -a
Linux wrt1900acs 4.7.0-rc3 #1 SMP Sun Jun 19 09:36:06 UTC 2016 armv7l GNU/Linux

Though there is the issue with split parser left. Maybe more.

    [    8.583919] mount_root: loading kmods from internal overlay
    [    8.675589] UBIFS error (pid: 609): cannot open "/dev/ubi0_1", error -22
    [    8.682465] UBIFS error (pid: 606): cannot open "/dev/ubi0_1", error -22
    [    8.689242] mount_root: failed to mount -t ubifs /dev/ubi0_1 /tmp/overlay: Invalid argument
    [    8.758069] UBIFS error (pid: 610): cannot open "/dev/ubi0_1", error -22
    [    8.764832] mount_root: unable to set filesystem state
    [    8.770203] mount_root: switching to jffs2 overlay
    [    8.775045] mount_root: switching to jffs2 failed - fallback to ramoverlay

I'll clean up what I have and upload the patches somewhere today, so others which have some spare time can hack on it. I likely wont have before the weekend.

In the meantime rc4 was released which reverts some ubi changes and now the overlay stuff is working again.

The patches are based on openwrt trunk (there was a commit 4 days ago) and add 4.7-rc4 for mvebu. As some complained in here dllin not working enough on inclusion I simply dropped compat-wireless and use in-kernel mac80211. The driver is also added as kmod-net-mwlwifi for testing in-kernel builds of mwlwifi.
Some highlights:

[    0.979448] mvneta_bm f10c8000.bm: Buffer Manager for network controller enabled
[   12.763623] marvell-cesa f1090000.crypto: CESA device successfully registered

On the other hand there are still major issues. iptables and firewall3 need fixing. Also wireless only almost works, have to investigate what I forgot when moving to in-tree builds.

Another interesting one:

[    0.000000] mvebu_mbus: [Firmware Warn]: deprecated mbus-mvebu Device Tree, suspend/resume will not work

An archive can be found here: https://gpldr.in/v/EL0Kz479M9/JWWRT3YVDyirQXpt
sha256: dc782680d0b28fd56387784b199d7d31bdcb61a400d6ab7050d4b7ba9b57d249

@sera

My build was failing at compat-wireless, but I did not have time to look into it at the time...
I also remember that the kernel build itself needed some manual input (a handful of prompts - nothing major).

Will have a look at your archive and give it a spin again... 

Cheers

doITright wrote:

@sera

My build was failing at compat-wireless, but I did not have time to look into it at the time...
I also remember that the kernel build itself needed some manual input (a handful of prompts - nothing major).

Will have a look at your archive and give it a spin again... 

Cheers

Then I sidestepped that issue unintentionally smile.

My issues were cryptodev-linux and parallel build issues due to perfs automagic dep at first, then other stuff. Fixes and hacks included in the tarball. Also updated configs so no manual input is required.

PS: Ha, there was just another commit to openwrt.

Just out of curiosity, what is the urgency (or motivation) to move to 4.7?  I've looked through the feature set and nothing jumped out at me.

Currently I have a rock solid stable build with pretty much all features enabled and working on both ACS and AC V1.  My only remaining issue I'm debugging is I can't get file transfers above about 10MB/s avg on 5G.  iperf3 is between 350 Mbps and 400 Mbps on that link, 450 between proximate android phone and router.

It's a nice place to be at after around a year of random reboots, poor performance, etc.

InkblotAdmirer wrote:

Just out of curiosity, what is the urgency (or motivation) to move to 4.7?  I've looked through the feature set and nothing jumped out at me.

Currently I have a rock solid stable build with pretty much all features enabled and working on both ACS and AC V1.  My only remaining issue I'm debugging is I can't get file transfers above about 10MB/s avg on 5G.  iperf3 is between 350 Mbps and 400 Mbps on that link, 450 between proximate android phone and router.

It's a nice place to be at after around a year of random reboots, poor performance, etc.

so USB 2.0 works?

----------------------------------------------------------------------------------------

is it just me, or does the USB 3.0 port on the ACS only function with USB 3.0 devices? plugged in an USB 2.0 flash drive and it didn't even turn on the light, confirmed working with an USB 3.0 flash drive though. EDIT: seems to not like some USB 2.0 devices....

(Last edited by Redfoxmoon on 22 Jun 2016, 01:23)

Redfoxmoon wrote:

so USB 2.0 works?

I can't remember a time it didn't work.  This is the super-old 1G USB stick I use to store logs etc:

Bus 002 Device 002: ID 090c:1000 <...snip...> Flash Drive
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
InkblotAdmirer wrote:

Just out of curiosity, what is the urgency (or motivation) to move to 4.7?  I've looked through the feature set and nothing jumped out at me.

Currently I have a rock solid stable build with pretty much all features enabled and working on both ACS and AC V1.  My only remaining issue I'm debugging is I can't get file transfers above about 10MB/s avg on 5G.  iperf3 is between 350 Mbps and 400 Mbps on that link, 450 between proximate android phone and router.

It's a nice place to be at after around a year of random reboots, poor performance, etc.

Just curiosity on my part... 

I don't have the knowledge or the skills to truly contribute to such an effort, but don't mind spending time trying to get things to just work...

If I remember correctly you were using your v1 as a wireless bridge once upon a time. 
Any updates on how this is working out for you, if still doing so?

Cheers

InkblotAdmirer wrote:

My only remaining issue I'm debugging is I can't get file transfers above about 10MB/s avg on 5G.  iperf3 is between 350 Mbps and 400 Mbps on that link, 450 between proximate android phone and router

Have you verified the same thing occurs on more than one device (preferably at least two devices on different OSes]?

Have you tried tweaking settings of the wifi driver on client PCs?

InkblotAdmirer wrote:

Just out of curiosity, what is the urgency (or motivation) to move to 4.7?  I've looked through the feature set and nothing jumped out at me.

No urgency, openwrt trunk works fine. Why 4.7, because it contains the work nitrohshift helped to get upstream, namely mvneta_bm.

There are few hundred unfamiliar patches between me and upstream, to tainted for my taste as to report anything upstream. Any bug is an openwrt bug. Yes, even the dreadful wireless N performance I can't blame on upstream yet. If dlin can reproduce it, great, otherwise it's my issue. Anyway who is OpenWrt to tell Marvell to upstream their driver when carrying stuff around for years. Don't preach what you don't practice. With very few exceptions any patch that is in trunk for more than 6 months should never have been committed.

Also I don't consider my bugs valid when I'm several versions behind, not just linux, and in this patch ridden environment a simple bump can already be a pain. Quite a few in here didn't manage the bump from 4.4.10 to 4.4.11 on their own. Let's say I report a bug and upstream asks me to test a new version and the answer is sorry, I fail to bump the version, let's wait a couple months to see the result of your work which you sacrificed your weekend for.

So the goal is ripping out many many patches and assert the actual opensource support of this device family, the motivation is getting familiar with what I use (buildroot or what it's called). Also I prefer hacking to watching tv on a rainy Sunday wink

sera wrote:
InkblotAdmirer wrote:

Just out of curiosity, what is the urgency (or motivation) to move to 4.7?  I've looked through the feature set and nothing jumped out at me.

No urgency, openwrt trunk works fine. Why 4.7, because it contains the work nitrohshift helped to get upstream, namely mvneta_bm.

There are few hundred unfamiliar patches between me and upstream, to tainted for my taste as to report anything upstream. Any bug is an openwrt bug. Yes, even the dreadful wireless N performance I can't blame on upstream yet. If dlin can reproduce it, great, otherwise it's my issue. Anyway who is OpenWrt to tell Marvell to upstream their driver when carrying stuff around for years. Don't preach what you don't practice. With very few exceptions any patch that is in trunk for more than 6 months should never have been committed.

Also I don't consider my bugs valid when I'm several versions behind, not just linux, and in this patch ridden environment a simple bump can already be a pain. Quite a few in here didn't manage the bump from 4.4.10 to 4.4.11 on their own. Let's say I report a bug and upstream asks me to test a new version and the answer is sorry, I fail to bump the version, let's wait a couple months to see the result of your work which you sacrificed your weekend for.

So the goal is ripping out many many patches and assert the actual opensource support of this device family, the motivation is getting familiar with what I use (buildroot or what it's called). Also I prefer hacking to watching tv on a rainy Sunday wink

@sera nice explanation, i also prefer this way spending of time during bad weather:-)
@nitroshift  thank you!
@InkblotAdmirer i have much better result on 5G, about 30MB/S.

Hi, can someone please post the link for the mwlwifi 10.3.0.17 driver latest build for 4.4.6?

@sera - I figured something like that, just wanted to make sure.  I'm not criticizing by the way, but I also think your efforts may be somewhat quixotic -- do you think there will ever be minimal patches in trunk?

@doITright - I settled on a fully routed network, so I have separate subnets for each wirelessly-linked network.  It works fine, but I've been considering retesting WDS since I think it was added to the driver in one of the recent commits.  The main drawback to my setup is with Windows clients -- the firewall pretty much sucks and to easily forward traffic across subnets pretty much all traffic is allowed.

@gsustek - I've seen speeds like that as well, just not with my latest build (which has been running a while so it isn't "latest" available).  There have been a lot of patches in mac80211, yuhhuarlin says to not build with patches but LEDE has kept a few, I have some personal patches of my own, etc etc etc.  I just haven't had time to track this down.

I think the recommendations for kernel bridging were well-intentioned but I wasted way too much time trying to get that to work -- I'm guessing that the function isn't supported in the drivers for this unit (but obviously don't rule out operator ignorance).

InkblotAdmirer wrote:
Redfoxmoon wrote:

so USB 2.0 works?

I can't remember a time it didn't work.  This is the super-old 1G USB stick I use to store logs etc:

Bus 002 Device 002: ID 090c:1000 <...snip...> Flash Drive
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00

I do get Linux Foundation USB 2.0 hub, but when I connect anything to my USB 2.0 / E-SATA combo port, it doesn't show up on my ACS, running trunk build kernel 4.1

sera wrote:

There are few hundred unfamiliar patches between me and upstream, to tainted for my taste as to report anything upstream. Any bug is an openwrt bug. Yes, even the dreadful wireless N performance I can't blame on upstream yet. If dlin can reproduce it, great, otherwise it's my issue. Anyway who is OpenWrt to tell Marvell to upstream their driver when carrying stuff around for years. Don't preach what you don't practice. With very few exceptions any patch that is in trunk for more than 6 months should never have been committed.

Also I don't consider my bugs valid when I'm several versions behind, not just linux, and in this patch ridden environment a simple bump can already be a pain. Quite a few in here didn't manage the bump from 4.4.10 to 4.4.11 on their own. Let's say I report a bug and upstream asks me to test a new version and the answer is sorry, I fail to bump the version, let's wait a couple months to see the result of your work which you sacrificed your weekend for.

So the goal is ripping out many many patches and assert the actual opensource support of this device family, the motivation is getting familiar with what I use (buildroot or what it's called). Also I prefer hacking to watching tv on a rainy Sunday wink

Have you explored running a vanilla build of 4.7 (or any kernel) without the OpenWrt/LEDE patches involved? OpenWrt's root doesn't work well, but you can fairly quickly build a Debian armhf rootfs with 'debootstrap --foreign' on a Linux PC. I've been using this by booting the kernel over tftp mounting a filesystem over NFS.

I used this to e.g. compare the Linksys kernel (which supports this NFS boot setup) routing performance against vanilla 4.6.something.

There's also Chadster's McDebian for a more polished version of this. I haven't tried it myself, though.

InkblotAdmirer wrote:

@sera - I figured something like that, just wanted to make sure.  I'm not criticizing by the way, but I also think your efforts may be somewhat quixotic -- do you think there will ever be minimal patches in trunk?

Well, it depends on your definition of 'minimal' :-)

I think that it's very possible that we can get to the point where the upstream kernel can be used without patches.

That's slightly different from saying that trunk has no kernel patches. It's valid for trunk to have some patches that are being tested, or are band-aids on really oddball corner cases (every major linux distro has some patches)

But as a general rule, it should not be a requirement to have patches to be able to run the device. It may not eek out the last percentage of performance, but it should run.

InkblotAdmirer wrote:

@sera - I figured something like that, just wanted to make sure.  I'm not criticizing by the way, but I also think your efforts may be somewhat quixotic -- do you think there will ever be minimal patches in trunk

I was trying to make a point smile. Anyway, git makes it incredibly easy to maintain a fork. The laborious part is figuring out how everything works together. I'm not out of stuff to learn yet.

leitec wrote:

Have you explored running a vanilla build of 4.7 (or any kernel) without the OpenWrt/LEDE patches involved? OpenWrt's root doesn't work well, but you can fairly quickly build a Debian armhf rootfs with 'debootstrap --foreign' on a Linux PC. I've been using this by booting the kernel over tftp mounting a filesystem over NFS.

A vanilla kernel doesn't know  about shelby, because the dts sits in the openwrt repository for far to long already smile.

Jokes aside, once I get tiered of fiddling with buildroot the next step would be something like that. Will report eventual findings.

Redfoxmoon wrote:

I do get Linux Foundation USB 2.0 hub, but when I connect anything to my USB 2.0 / E-SATA combo port, it doesn't show up on my ACS, running trunk build kernel 4.1

Apply https://bpaste.net/show/9abbe9ad9549

@dlang, well said

InkblotAdmirer wrote:

@doITright - I settled on a fully routed network, so I have separate subnets for each wirelessly-linked network.  It works fine, but I've been considering retesting WDS since I think it was added to the driver in one of the recent commits.  The main drawback to my setup is with Windows clients -- the firewall pretty much sucks and to easily forward traffic across subnets pretty much all traffic is allowed.

I think the recommendations for kernel bridging were well-intentioned but I wasted way too much time trying to get that to work -- I'm guessing that the function isn't supported in the drivers for this unit (but obviously don't rule out operator ignorance).

That is pretty much the setup I was using as well. 

There were some performance gremlins to be sure, so about 6 months back I switched back to stock just for the bridging...  However, there are problems with the stock setup as well, so I may just try to do it again with LEDE.

Cheers

Bundle 2 ports as backbone / uplink on wrt1900acs with latest mr. frezee image.

Hi,

I got a Netgear 24 port GS724T Gigabit smart switch which is placed in the office.
On the router I am running with hardware RAID 5 (ICY raid 4 bay) connected through USB3.0.
We use this NAS in our office with several client simultaneously through ethernet.

Therefor I like to bundle 2 ports as uplink to the Netgear switch to get best performance possible in this constellation.

How do I need to configure the WRT1900ACS to handle port 0 and port 1 as one port?

Thank you!

Here is a link where someone else was trying to set up Bonding >  https://forum.openwrt.org/viewtopic.php?id=34342

I'm not sure what you will get out of link aggregation, but it might be fun to try and set up.

NeuerLinuxfan wrote:

On the router I am running with hardware RAID 5 (ICY raid 4 bay) connected through USB3.0.
We use this NAS in our office with several client simultaneously through ethernet.

Wholly off topic, but thought it prudent to mention since a major tech review company I subscribe to on YouTube lost a substantial amount of data when one of their RAID5 configs went down (they had 3), resulting in substantial data loss for a period of time

If utilizing RAID, the best type to use is ZFS, as it's almost impossible to have data corruption due to ZFS's auto healing features.  Not sure if you're using a store bought NAS, but if you're able to choose your own running platform, check out FreeNAS (you can either set up FreeNAS on your own equipment [it's opensource & free], or buy FreeNAS's corporate sponsor's hardware [iX-Systems] with TrueNAS; FreeNAS is a fully configured FreeBSD NAS Server OS)

(Last edited by JW0914 on 23 Jun 2016, 16:35)

JW0914 wrote:
NeuerLinuxfan wrote:

On the router I am running with hardware RAID 5 (ICY raid 4 bay) connected through USB3.0.
We use this NAS in our office with several client simultaneously through ethernet.

Wholly off topic, but thought it prudent to mention since a major tech review company I subscribe to on YouTube lost a substantial amount of data when one of their RAID5 configs went down (they had 3), resulting in substantial data loss for a period of time

If utilizing RAID, the best type to use is ZFS, as it's almost impossible to have data corruption due to ZFS's auto healing features.  Not sure if you're using a store bought NAS, but if you're able to choose your own running platform, check out FreeNAS (you can either set up FreeNAS on your own equipment [it's opensource & free], or buy FreeNAS's corporate sponsor's hardware [iX-Systems] with TrueNAS; FreeNAS is a fully configured FreeBSD NAS Server OS)

This is very off-topic, but all RAID types can be self-healing. I would not use RAID 5 , only RAID 6, just based on how long it takes to recreate a drive when you are talking about multi TB drives, the odds of loosing a second drive in the meantime (which results in data loss) is just too high. With RAID 6 you would have to loose three drives before you loose any data.

ZFS doesn't change that.

dlang wrote:

This is very off-topic, but all RAID types can be self-healing. I would not use RAID 5 , only RAID 6, just based on how long it takes to recreate a drive when you are talking about multi TB drives, the odds of loosing a second drive in the meantime (which results in data loss) is just too high. With RAID 6 you would have to loose three drives before you loose any data.

ZFS doesn't change that.

All RAID configs can be self healing... ZFS is self healing (with or without parity) - there's an important distinction there. 

ZFS is simply a far more efficient file system for many reasons, not least of which software RAID is a far better solution than non-standardized hardware RAID controllers.

(Last edited by JW0914 on 24 Jun 2016, 01:52)

As SSD continues to come down in price, and continues to kill the old style platter drives in performance, I wonder if disk mirroring will be the #1 choice in the future. Simply because of the reliability factor alone.

hi, some info for latest LEDE build,

after latest commit, WRT1900acs doesn't boot anymore. http://sprunge.us/YJRO

(Last edited by gsustek on 24 Jun 2016, 06:15)

Sorry, posts 12251 to 12250 are missing from our archive.