I disconnected the 3.3v but no change...same behavior

What OS are you using to interface with the USB to TTL Serial Cable and have you made sure the drivers are working properly?

I personally haven't used "minicom, screen, or picocom" as a console app so can't comment on their usability.  Not saying they wont work, I just have no experience with them.

Hopefully someone else who is watching this thread will provide more input.

Also, OpenWRT IRC channel could possibly lend some assistance.

IRC: irc.freenode.net #openwrt 

(Last edited by kirkgbr on 12 Mar 2016, 16:56)

Do you have any further information about this? The device is great but the wifi issues not.

About the 15.05.1 release, is there maybe a roadmap for the release?

Thx!

Re: mwlwifi, Hit the git
Re: Roadmap, not to my knowledge

Did you solve that?

Wan's LED doesn't working on "4.1.16 #1 SMP Fri Mar 11 09:18:56 UTC 2016 armv7l GNU/Linux"

Someone have an idea why? All other LED works fine.

(Last edited by roylaprattep on 13 Mar 2016, 18:41)

Did you check the GUI settings?

So for the time being, is there any point in going back to the .15 Version? (Does that have the wifi fault, also?) Or just grin and bear it for the time being? Thanks!

You need to set it up in LuCI under System ---> LED Configuration.

nitroshift

Please join #openwrt on freenode server for more info.

nitroshift

For those who are waiting for 15.05.1 to solve the wifi issue: it won't, unless Marvell improves their driver.

nitroshift

I tried! I can only put "Shelby white power" and my power led act as my wan led....

It works well wifi, updating trunk of March 13?
I tried all versions of OpenWRT but always return to ddwrt kong, wifi works very slowly. 4 hours decreases the rate of 300 mbps wifi from 10.
Selby  linksys wrt ac1900acs

@roylaprattep

Shelby uses a different LED chip than Mamba, so I can't help you. Sorry.

nitroshift

Hey Nitroshift,

Can you contact "Stefan Roel" to see if we can get either the kwb files for the WRT1900AC V2 and WRT1200AC? I have both available if you need me to dump the mtd0 partition.

It would be better if we could get the u-boot config used so we can built updated kwb files for these routers.

My update on firmware status:

I gave up on the CC path:  there were no fast and stable mwlwifi/mac80211 combinations I could find.  I could get great data rates but no longer than 5-6 days uptime before 5G network would crash.  Speed:
- talking to another WRT1900AC (V1) in bridge mode (stock firmware) I was getting 40-45MB/sec transfer rates.  No linux boxes on remote end so no iperf statistics.  I had pulled over a late-model mac80211 driver from trunk to achieve this.  That may still be the best 15.05 combo, because:
- the recent 15.05 updates to mac80211 improved this to ~50MB/sec, with peaks up to 60MB/sec -- NICE!  But even 2G network was unstable with this build.  (3.18.27 kernel)
- For this reason I moved to trunk (as of roughly 3/9).  Word is that 15.05.1 will be moving to kernel 4.4 anyway, and I expected to need to re-setup the router in full anyway, so I just bit the bullet and moved to trunk with kernel 4.4.4.  Speeds are again ~50MB/sec, peaks up to 60MB/sec.  Again, very nice.
- This trunk build is approaching crunch time, in 2 hours it will have been up 5 days.

As a side project, I've worked on getting the remote bridges up and running under OpenWRT.  I finally have settled on a method, which is a fully routed client.  I toyed with relayd (it works but peak speeds were around 15-20 MB/sec).

So I now have a portion of my network set up as a different subnet with wireless client access to the main network, fully routed.  Fun fun with Windows and Linux clients mixed, but that's a separate story, it's a fully working "equivalent" to wireless bridge.
- iperf reports 285 Mbits/sec one direction (client network server mode), 97-109 Mbits/sec the other direction (client network in client mode)
- file transfers peak at 30MB/sec (client network to AP network), with averages around 20-22 MB/sec.

So the relayd setup wasn't actually all that bad, and Belkin/Marvell are holding out on us with driver capability.  If the wifi networks prove to be stable, I will likely keep this setup.  Speeds are OK (although close to what I was getting with a strictly wireless-N network) but it is pretty awesome in all other respects getting rid of stock.

As an aside, I was asked (dlang) why I didn't set this up as a kernel bridge.  It has been stated by OpenWRT developers that this driver won't work in bridge mode and I have painstakingly verified that my crude abilities are incapable of making that mode work.  An example was given with a Netgear router setup, and I have no idea what driver is used in that model but I can't figure a way to get the mwlwifi driver working in bridge mode as a client.

@davidc502

Please let me know if you want to test the offload module and I will send you the patches.

nitroshift

@nitroshift

I'm about to build a new image since the last started to bug out big time. If you wouldn't mind sending me the patches?

@lifehacksback

You can find me in #openwrt channel on freenode irc server in about an hour time.

nitroshift

@nitroshift

I'll wait for you

On my TL-WR1043nd on the switch page in Luci, I get a port status indication: diconnected, 100Mbps, Gigabit...
This isn't there in my Wrt1900ac with CC 15.05.
Is there a way to get this back?

Good time of the day,

I've been trying different flavours of OpenWRT firmwares for Linksys WRT1900ACS and didn't get stable WiFi for more than several days. Anyone could share their experience? Really looking forward to get bit more stable build.
Right now I'm running Arokh trunk build based on kernel 4.4.4 and .16 WiFi driver.

Much appreciated!

I was thinking about the performance reduction using OpenWRT as a routed wireless client replacing a true wireless bridge (~25MB/s throughput vs >50MB/s).  This is likely due to the additional overhead of routing packets at the wired level before pushing them to the wireless driver (as opposed to bridging directly within the wireless driver -- that's my uninformed guess).  Note that the 50MB/s number includes the .16 mwlwifi driver on the receiving end so in certain conditions it's capable of decent throughput.

It occurred to me that depending on the software implementation splitting the interrupts to different cpus may actually help in this case?

And in addition the offload module @nitroshift mentioned might help as well?

If there's some merit to this line of thinking I'm willing to do some configuration tweaking and some new builds with the offload module patch.  Otherwise... never mind!

If you need a stable and basic build (No frills), but does include iptables firewall, then download from the link below and choose LuCi_Wifi_.16_NANDPatch

I will check it out! I wonder if you can share your build setup, so I will be able to build some extra kernel modules.
Thanks in advance!