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.

swrt-2017-05-15
---------------

This time it's several kernel bumps and the addition of 4.12. Due to changes in
kernel infrastructure some build system adjustments were needed, and might be
needed in future again as it doesn't seem all went exactly as it should have.
Time will tell.

I did a full build of base using 4.12 which brought two more issues to light.
Fixed and sent a patch upstream for xtables-addons. As for kmod-dm, the
packaging is heinous so mark it broken for now and get back to it if someone
needs it or for when I'm bored.

The memory fix for mwlwifi just got fixed again today, though the one from a
few days seems to have worked to some extent, at least it didn't trigger for me
so far. So the root cause was likely understood.

Then I made gen_initramfs_file_list.sh POSIX compliant, the shebang identified it
as a bash script however when switching to use an interpreter I used sh which
could point to pretty much any other shell as well. Should fix the issue
reported by doITright.

kmod-sched-cake was broken in next already and now the same is true for 4.12, so
mark it broken there as well.

* linux-4.4: bump to 4.4.68
* linux-4.9: bump to 4.9.28
* linux-4.10: bump to 4.10.16
* linux-4.11: bump to 4.11.1
* linux-4.12: add 4.12-rc1
* linux-next: bump to next-20170515

* xtables-addons: fix for 4.12
* kmod-sched-cake: mark also broken in 4.12
* kmod-dm: mark broken in 4.12 and next
* initramfs-mvebu: make POSIX compliant
* mwlwifi: bump to latest commit

* build: support new rc tarball location

swrt-2017-05-15.tar.xz: https://gpldr.in/v/dH3mcFxQOw/kLYYZN46iwGDeMrZ
sha256sum: 72fe2f91cfcbe032716051d4fa12ffc6c04864843f0f9785abceb3af23ef7a81

@sera

4.10 and 4.11 build fine, but next still fails for me:

fs/built-in.o: In function `ovl_get_origin': 
/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.16_eabi/linux-mvebu/linux-next-20170515/fs/overlayfs/namei.c:141: undefined reference to `exportfs_decode_fh'
fs/built-in.o: In function `ovl_encode_fh': 
/openwrt/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.16_eabi/linux-mvebu/linux-next-20170515/fs/overlayfs/copy_up.c:253: undefined reference to `exportfs_encode_fh'
Makefile:997: recipe for target 'vmlinux' failed

Will give the newest driver a beating with 4.11

Cheers

@sera Since you've done an exhaustive amount of work on kernels, what would you recommend as the best place to start learning about kernels and building them?

doITright,

a missing Kconfig dependency declaration, sent a patch upstream to address this. Thanks for the report. Didn't notice myself as a tool I always include selects what is needed here already.

---

JW0914,

Build a kernel for your desktop distribution. Many aspects should already be familiar if you build OpenWrt from source. Unless a minor distribution there likely is a lot of documentation about getting the toolchain, getting the kernel sources, configuring and building a kernel and adding an entry for your own kernel to your bootloader.

Systemd folks at some point noticed they broke booting without an initramfs but it was to late to fix it, so you will likely also have to build one and tell the bootloader about it. Luckily there are tools like dracut which make this a lot less painful.

In the end, the difficult part is probably to figure out what hardware you have an which drivers you need for it. Depending on what software you intend to run you also need certain features. This might be somewhat daunting at first but you can always start with the distributions .config and slowly remove what you think you do not need and check what (if anything) broke.

Kernels for binary distributions are usually really fat, so there is a lot you can strip out, you will likely only need 1-2% of it and the rest is bloat. If they want to support just about everything with a single image they do not have much choice in this matter though.

@sera Thanks! =]

@sera

Mamba esata port isn't detected in any kernel after 4.4. It works on Rango though.

nitroshift

Right now I am just very disappointed in the WRT1200AC, especially wuth the 2.4G band

Get this - I plugged in an AR9271 USB and it even came up as a 802.11 Generic Controller, and STILL pulled better perfomance than the Marvell 88W8864 could muster up at VERY close range and from afar. Even with worse signal the AR9271 performance was BETTER than the 88W8864 which gave me better signal.

This is also the behavior for the 5G band as well, which only pulls N performance at moderate distances.

I need suggestions, is there ANY way I can improve the speed? Perhaps use another firmware? Please do NOT give me basic suggestions like "Make sure the channel is 1, 6 or 11" I've already debunked those because in the same conditions the AR9271 was performing better than the 88W8864, almost in the exact same spot. I need fixes because I am getting angry that I wasted money on a product that's inferior to my N150 device. The only thing I can do is get a replacement from Linksys, but I am scared that I'll get the same results, and I'll be very peeved by then.

Note: I also get the same results on the stock firmware so I've ruled that out.

I saw someone else that reported in this thread the same problem, I am with you sir, this thing is terrible. Maybe Linksys delivered on the old school looks, but not the speed and reliability, shame on you Linksys.

There are lots of possible reasons why one router will perform better than another at the same location.

I would guess that the better antennas of the 1200ac are hearing more other stations than your USB device is, and therefor sees less time that the band is idle and is able to transmit.

try doing iw <dev> scan on both radios and see how many different things they each see.

@Sizeable Swiss Venting in a forum does very little, as it's not relevant to the issues.

  1. What firmware version are you running?

    • What firmware versions have you tried?

      • Are you utilizing pre-built images (if so which ones), or are you building your own?

  2. What are the dB levels for both networks?

    • Please list the dB levels from 5ft in front of the router, then again moving back in 5ft increments up to 30' (or as far as possible if shorter than 30ft).

  3. Please post (within [ code ] brackets):

    • /etc/config/wireless

      • Ensure you remove the WiFi password

      • Since you tried different channels, what were the dB levels & speeds on the channels you tried?

    • System log

  4. Are any home appliances within 10ft of the router?

    • For example, microwaves, fridges, or any large appliance utilizing 120v+ (washer/dryer, water heater, etc.)?

  5. Are there any cordless phones in your home?

  6. Are you connecting through walls/different floor levels?

    • If through walls, are they concrete or were they built with metal, not wood, studs?

  7. Is the router positioned in approximately the center of the area you want covered by WiFi?

  8. What devices have you tried and what were the dB levels and speed on all devices?

    • Please perform speed tests 3x in a row per device via SpeedTest.net, while connected to WiFi only, then please post the resulting download and upload speeds,as well as the ms time for the ping, along with the up/down speed of your internet service.

  9. If you live in the US, do you reside within a NRQZ [National Radio Quiet Zone]?

    • These are areas where state & federal laws discourage and limit, if not outright ban, the use of everyday EMF devices, allowing the NSF's NRAO to operate unimpeded from EMF signal noise.  For example, there's a 13,000sq.mi. NRQZ in West Virgina.


It is entirely possible you simply got a lemon, as it does happen from time to time since there's no way a production line can create 100% of products defect free, especially in the nanometer tolerances required for PCBs.  If the answers to the above don't supply any conclusive answers, it would be recommended to exchange the router for a new one from where you bought it, or via Linksys directly if that's not an option. 

  • I manage 2 WRT1200s, both running DD, and I've never had the issues you're having, which means it's either environment related, with the above questions answering, or it's simply a defective unit.

(Last edited by JW0914 on 25 May 2017, 01:36)

swrt-2017-05-22
---------------

The new sata driver (since 4.5) according to help text is for mvebu, looking at
the code aramda-xp / Mamba doesn't count as mvebu in this context, my bad only
checked 385, re-enable the old driver which is needed on Mamba. Reported by
nitroshift.

Then I fixed the missing dependency in overlayfs for 4.12+. Reported by
doITright.

Further add the armada-385-linksys.dtsi rework and Rango addition to Linux 4.12
& next, only 4.12+ has all dependencies already. Currently waiting for it to
get merged upstream.

4.10 is about to reach EOL, so it's about time to move on, unless someone knows
of an issue new in 4.11 I'll change the default with the next release.

Finally the usual kernel bumps except for next which wouldn't boot, so use the
one from before and try to figure out what went wrong later.

* linux-4.4: bump to 4.4.69
* linux-4.9: bump to 4.9.29
* linux-4.10: bump to 4.10.17
* linux-4.11: bump to 4.11.2
* linux-4.12: bump to 4.12-rc2

* kernel: enable old sata driver for Mamba
* kernel, 4.12 & next: overlayfs fix missing dependency
* kernel, 4.12 & next: add Rango dts rework

swrt-2017-05-22.tar.xz: https://gpldr.in/v/z9f9ZBxqhd/eLGneTnxzcxpPEHV
sha256sum: 56f5722f779a67f282490728e1baccbd5c2842fe444669b8a9f39fc847a5ff65

@Sera
Great news, Rango entered the Armada-385-Linksys!
Thank you.

@sera

swrt-2017-05-15 @ 4.11.1 up for a few days now and I can't force the crash/reboot via torrent anymore smile

Cheers

ValCher,

yes, though that needed some rework of the dtsi and the dts of other boards. Also means backporting to before 4.12 isn't trivial any longer, well still doable but you will have to wade through git history to pick all required preparatory patches.

---

doITright,

that is fantastic news, so the Mamba reboot issue is in all likelihood fixed in 4.11.1 which leaves the missing /dev/input/event0 issue and an usb2 power issue in 4.12 on Mamba.

All the more reason to make 4.11 the default. 4.11 also works well for me on Shelby and Rango.

Thanks

Hm, looks like yuhhaurlin is busy closing valid mwlwifi bug reports ...

@sera

Perhaps I jumped the gun a bit...  It seems the mamba rebooted itself last night....

Will put load on it after work.  Perhaps it now takes longer for the crash to trigger?

Cheers

sera wrote:

Hm, looks like yuhhaurlin is busy closing valid mwlwifi bug reports ...

Probably he has decided Marwell only wants to support the latest 88W8964 chips. sad
Any issues for older chips seem to be closed.

doITright,

would have been to nice for the issue to be magically fixed ...

---

adri,

I doubt that is the official position of Marvell but sure one can easily get this impression.

What I can say there is a lot of noise on that tracker and as yuhhaurlin isn't that fluent in English such eats _a lot_ of his development time. If you can't read, don't post. So this might be just a desperate attempt at cutting down on the load. Also he doesn't seem to be a seasoned open source developer having a feel for what people expect or how to deal with the community. Some user actually tried to explain to me that the tracker isn't a tracker but in fact a study group at some point ...

DFS channels work well for me on Shelby, wasn't dropped to a non DFS channel even once and someone already stated to have the DFS issue on Rango, so nothing to win from limiting it to the most recent chip only. Also what Linksys exposes in their UI is utterly irrelevant. They also clock down the CPU on the cheaper models, after all they need to create some incentive for users to go for the more expensive models. The 1200AC is really a lot of hardware for little money otherwise.

Not allowing to reduce power levels certainly can't be blamed on FCC either.

Well as long as there are more pressing issues he can close those bugs, we just have to file them again when things have calmed down.

sera wrote:

doITright,

would have been to nice for the issue to be magically fixed ...

---

adri,

I doubt that is the official position of Marvell but sure one can easily get this impression.

What I can say there is a lot of noise on that tracker and as yuhhaurlin isn't that fluent in English such eats _a lot_ of his development time. If you can't read, don't post. So this might be just a desperate attempt at cutting down on the load. Also he doesn't seem to be a seasoned open source developer having a feel for what people expect or how to deal with the community. Some user actually tried to explain to me that the tracker isn't a tracker but in fact a study group at some point ...

DFS channels work well for me on Shelby, wasn't dropped to a non DFS channel even once and someone already stated to have the DFS issue on Rango, so nothing to win from limiting it to the most recent chip only. Also what Linksys exposes in their UI is utterly irrelevant. They also clock down the CPU on the cheaper models, after all they need to create some incentive for users to go for the more expensive models. The 1200AC is really a lot of hardware for little money otherwise.

Not allowing to reduce power levels certainly can't be blamed on FCC either.

Well as long as there are more pressing issues he can close those bugs, we just have to file them again when things have calmed down.

Can that driver be forcked? As you know i am not a coder but, what i am trying to say if a thing does not get fixt could you fix it if you were so inclined? I saw your PL...

Considering how many manufacturers bowed out after the new FCC rules came out, I'm just happy that Marvel stayed in the game. Yes, it's going to take a long time to get the Wifi driver working right... For me at least, it's about the "Router" and all the features, and not so much about the Wifi end of it. Because I put so much value on OpenWrt/Lede, I would be willing to buy a Wifi AP, and just plug it into the router, and work that way, if that's what it meant for me to keep OpenWrt/Lede going. A lot of people were bent out of shape when it took forever to get the 1900ac Wifi working right, and we went through it again with the 3200acm (I don't blame them), but with Opensource we can't always predict or demand things be working immediately as much as we want them to.

(Last edited by davidc502 on 23 May 2017, 19:35)

tapper,

the stuff handled in firmware can't be fixed without the collaboration of Marvell. Also as long as it's an out of tree driver there is little incentive to work on anything but build fixes / porting to more recent kernels anyway.

As an access point Shelby works fine for me, supports all features I need. Just like davidc502 I don't need the wireless bit as I had a working setup before which I could have continued to use instead. The important bit for me it's a true gigabit router which can be used with any Linux distribution, has the looks to be placed in the living room and doesn't eat all that much power (a lot less than the old setup at least).

Also when I said not a seasoned open source developer I didn't mean not able to work on the code properly but dealing with the community in a way that doesn't cause frustration on both ends which is an entirely different skill set. Dealing with proprietary and open source customers is quite different after all.

sera
I understand that in kernel-4.12 A radical change has been made to ' gpio-mvebu.c ' and no longer need a PWM patch. Right?

sera wrote:

DFS channels work well for me on Shelby, wasn't dropped to a non DFS channel even once and someone already stated to have the DFS issue on Rango, so nothing to win from limiting it to the most recent chip only. Also what Linksys exposes in their UI is utterly irrelevant. They also clock down the CPU on the cheaper models, after all they need to create some incentive for users to go for the more expensive models. The 1200AC is really a lot of hardware for little money otherwise.

@sera,

I agree what Linksys exposes is irrelevant to the open source version.
I do like to have DFS fixed, since it doesn't work for me and a lot of other users on Shelby.
Most interference seems to be interpreted as radar pulses, causing the router to abandon the channels.
I Europe we don't have access the UNII-3 and ISM band, channels 149-165, so that leaves only UNII-1 band, channels 36-48, usable.

ValCher wrote:

sera
I understand that in kernel-4.12 A radical change has been made to ' gpio-mvebu.c ' and no longer need a PWM patch. Right?

Yes, the rewritten pwm-fan driver made it into 4.12, the dts(i) and defconfig change patches to use it on Mamba got applied yesterday for 4.13 as well. So in 4.13 you wont need any extra patches. For 4.12 grab the patches 1-3 in the latest swrt under target/linux/mvebu/patches-4.12. The ones you currently use probably wont do, as I also had to adjust the bindings for the new driver.

Btw, the dtsi rework and Rango addition got merged for the most part as well already (11 out of 13 patches). So the missing mwlwifi driver will basically be the only missing bit.

adri wrote:

I agree what Linksys exposes is irrelevant to the open source version.
I do like to have DFS fixed, since it doesn't work for me and a lot of other users on Shelby.
Most interference seems to be interpreted as radar pulses, causing the router to abandon the channels.
I Europe we don't have access the UNII-3 and ISM band, channels 149-165, so that leaves only UNII-1 band, channels 36-48, usable.

adri,

which leaves a single non overlapping channel for 80MHz and doesn't allow 160MHz at all. Sort of obvious that it needs fixing me thinks.

Well, there are more pressing issues but at least acknowledging that this is sub par would help.

@sera,
You've done a great job, it's impressive.
Thank you!