OpenWRT for Linksys WRT1900AC

[jalyst]

Hmm, not seeing definitively bricked in those cases, some may well be PEBKAC.*
It's difficult to brick such devices completely, there's often a way out so that one may begin again.
Good to see such responsiveness by Linksys though, that really is necessary...

But I did just see this, & I dare-day they'll "know" that they're bricked if they have no luck w/the next step:
https://forum.openwrt.org/viewtopic.php?pid=231290#p231290

Still, there def. seems to be more that have had no serious issues after flashing than those who have.
Esp. given the age old rule that when gear (mostly) works, people pipe-up far less than when it doesn't.
But unreliability is def. going to be greater than your typical stock fw, of course...

*everyone has an initial learning curve when there's a (sightly) new process

[now unsub'd from this thread, too busy & too much noise, apologies in advance if I don't respond]

 

[jalyst]

Linksys WRT1900AC OpenWRT

A few weeks later, Belkin finally provided the source code to these components as well, however so far the reception by the OpenWRT development community has been less than enthusiastic...
Complains about the poor shape of the code and the use of custom/proprietary interfaces rather than the standard Linux interfaces for interfacting with the wireless stack even led some of them question whether it was worth the trouble of cleaning it all up, considering that any work (at this moment) would be strictly for this specific router model (as no one else, AFAIK, uses the same Marvell platform at this time).

Re all this, some good points made here...
https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/025066.html

Reception has been mixed, most have been uninterested at this point, some have been vocally opposed to doing anything (most of them not actually devs), & some have started quietly tinkering & ignoring the politics.

 

[jalyst]

Linksys WRT1900AC OpenWRT

I'm not sure if I'm missing something, but... This GPL package lets you download and compile the all the components. But it doesn't seem to generate any firmware out of those compiled components, so I'm not sure I understand what's the point of it (beside providing the patches to comply with the GPL licence, and... prove that they can actually compile?)

So, no go on building your own modified firmware out of this (I was hoping to maybe at least be able to slap a telnetd in there).

I trust you've been following developments here, if not tis worthwhile subscribing:
https://forum.openwrt.org/viewtopic.php?id=50173&p=4
It's gotten much busier in the last ~3-days...

 

[RMerlin]

I trust you've been following developments here, if not tis worthwhile subscribing:
https://forum.openwrt.org/viewtopic.php?id=50173&p=4
It's gotten much busier in the last ~3-days...

I was actually referring to the stock firmware's GPL code. I was hoping to do a quick rebuild with maybe a telnet daemon added so I could poke at a running unit.

I do keep an eye on the OpenWRT development tho, but I doubt we'll see anything of production quality from them for quite a while.

 

[jalyst]

Attitude Adjustment might be worthwhile for you to tinker with then...
Although most folks there seem to think Barrier Breaker is just fine too.
So long as you're fine with possible flakey or downright broken 2.4/5Ghz, for now.

 

[chadster766]

I download Atttitude Adjustment for my WRT1900AC and did some performance testing with various Wireless AC adapters you might fine interesting.

WRT1900AC OpenWRT Performance Testing including adapters AC580 AC1200 AC1300

It seemed to me that wireless "N Only" was a big problem on the 5GHZ but AC setting was super-fast.

The 2.4GHZ just straight out worked.

 

[Mordred]

Would you have time to put the curl script together? I can run the test if you like.

I'm hoping to download the WRT1900AC OpenWRT source to see what's up with the 5ghz wireless N issue. I've done software development for embedded Linux systems before so I'm hoping I can help with the OpenWRT development. Unfortunately I'm very busy as I'm sure you are too.

If you are referring to this:

https://github.com/wrt1900ac/opensource/

then I'm curious how you going to fix the binary blob

There are no sources for the wireless driver there, only a binary blob in the attitude-adjustment branch. There are sources in the gpl download from the linksys firmware, but that code is BS and has been modified to be "releasable" probably doesn't really work.

 

[jalyst]

There are sources in the gpl download from the linksys firmware, but that code is BS and has been modified to be "releasable" probably doesn't really work.

I see, so you are an expert on such things, yeah?

 

[chadster766]

If you are referring to this:

https://github.com/wrt1900ac/opensource/

then I'm curious how you going to fix the binary blob

There are no sources for the wireless driver there, only a binary blob in the attitude-adjustment branch. There are sources in the gpl download from the linksys firmware, but that code is BS and has been modified to be "releasable" probably doesn't really work.

Thanks for the tip that the driver code is in the Linksys GPL

 

[sfx2000]

Would you have time to put the curl script together? I can run the test if you like.

I'm hoping to download the WRT1900AC OpenWRT source to see what's up with the 5ghz wireless N issue. I've done software development for embedded Linux systems before so I'm hoping I can help with the OpenWRT development. Unfortunately I'm very busy as I'm sure you are too.

Sorry - if I write code for someone else other than me, I get paid - simply put.

I provide a lot of free advice/insight here as I get much in return, and once you get to know the community here, you'll see what I mean.

Tim Higgins has built a fantastic group of experts that share their time, and truly value the inputs of others.

I've given you the jedi nudge on one way that you can accomplish the task your looking for...

sfx

 

[sfx2000]

Thanks for the tip that the driver code is in the Linksys GPL

Play nice kids

If you grab the GPL source, and unpack the tarball - WRT1900AC_v1.1.7.160177_build_21_RTW.tar.gz

look here.. here's the Marvell source code

~/<home>/publication/src/mrvl_wlan_v7drv

Everything is there, including Marvell confidential release notes for the driver, which I was surprised to see... the file I mention is "Release Notes 88W8864_7.2.5.4_fw_7.2.5.2.pdf"

88W8864 Linux Driver/Firmware Release Note 7.2.5.4 fw 7.2.5.2
Release Note
7.2.5.4_fw_7.2.5.2 Release notes:
April 4th, 2014
This release contains driver for the Kernel 3.2.40
Driver version: 7.2.5.4 Linux Kernel version: 3.2.40 Firmware version: 7.2.5.2​

So everyone play nice...

sfx

 

[chadster766]

Thanks I appreciate it

 

[sfx2000]

I see, so you are an expert on such things, yeah?

Obviously you don't understand, and many folks don't what GPL allows...

From where I sit, Linksys is in compliance, perhaps overly so in some regards, but they're under no obligation to provide a flashable image - nor are they obligated to share any code that does not directly link to GPL code (some weasel room here with GPLv3 ok folks, lots of people avoid GPLv3 including the Linux kernel)

Some vendors do more than required perhaps with regards to GPL... to whit, ASUS, they do provide enough code that people can build their own bootable/flashable images for example

It's also the reason why some OEM's/Vendors use BSD-licensed code instead, for example Google with Android - the bionic lib is a good example of getting around glibc and still provide an OpenSource compliant implementation... in other words, if you don't want to share the entire kitchen, or even parts of it, there are alternatives to GPL - and even then, GPL does provide protection, as does copyrights...

I'm not an IP lawyer, but I know a lot of them...

sfx

 

[sfx2000]

@Jalyst - this wasn't targeted towards you man...

sorry if it came across that way...

sfx

 

[sfx2000]

I was actually referring to the stock firmware's GPL code. I was hoping to do a quick rebuild with maybe a telnet daemon added so I could poke at a running unit.

I do keep an eye on the OpenWRT development tho, but I doubt we'll see anything of production quality from them for quite a while.

My guess is that Linksys is definitely going after the OpenWRT crowd for FOSS builds - like you, I'm a bit disappointed that they didn't provide a full package that one could build and flash - at the same time, they want to protect their secret sauce, which they can do...

oh well... OpenWRT it is then - and I think the community there could use your insight - you've been a great contributor and asset to the enthusiast community...

sfx

 

[jalyst]

Obviously you don't understand, and many folks don't what GPL allows...

Oh I do, been around mobile F/OSS stacks heaps over the yrs*, WR stacks not so much.
I just found the post I was responding to, amusing...
To be so presumptuous is odd, this is a regularly evolving & fluid situation.
It's very early days in the project's life-cycle comparatively speaking, things look like they may change, yet again:
https://forum.openwrt.org/viewtopic.php?pid=232738#p232738
Thanks for trying to be informative though, no offence taken at all...

*Maemo/MeeGo, OpenWebOS, Android (eeeiiiwww), MeR/Nemo/Sailfish, Tizen, Ubuntu-Touch etc.

[anyway, unsubscribing from this thread, too busy & too many distractions]

 

[RMerlin]

My guess is that Linksys is definitely going after the OpenWRT crowd for FOSS builds - like you, I'm a bit disappointed that they didn't provide a full package that one could build and flash - at the same time, they want to protect their secret sauce, which they can do...

oh well... OpenWRT it is then - and I think the community there could use your insight - you've been a great contributor and asset to the enthusiast community...

sfx

If the OpenWRT devs decide to embrace the device, they definitely have the technical know-how to get it working. The question is whether the core OpenWRT devs will decide to support the device, or if they will decide it's too much effort to support just one single router model (since, AFAIK, no other router is based on the same Marvell platform at this time). In which case it could survive as a side project maintained by other developers than the core guys.

 

[Mordred]

Oh I do, been around mobile F/OSS stacks heaps over the yrs*, WR stacks not so much.
I just found the post I was responding to, amusing...
To be so presumptuous is odd, this is a regularly evolving & fluid situation.
It's very early days in the project's life-cycle comparatively speaking, things look like they may change, yet again:
https://forum.openwrt.org/viewtopic.php?pid=232738#p232738
Thanks for trying to be informative though, no offence taken at all...

*Maemo/MeeGo, OpenWebOS, Android (eeeiiiwww), MeR/Nemo/Sailfish, Tizen, Ubuntu-Touch etc.

[anyway, unsubscribing from this thread, too busy & too many distractions]

There is nothing changing.

This post from one of the main openwrt devs, says it all:

https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/024944.html

He was quite nice by writing "This looks like rewrite (not cleanup) material".

Look at the mailinglist and you will notice, no work is done on the 1900ac. Just a bunch rookies playing around with the unofficial openwrt build and their comments show you where this build stands and again this openwrt build does not even use the sources provided by linksys.

If the sources would be the same you would find them in the openwrt build, but there you can only find a bin. Why would they be so stupid to only post the binary? Most likely, the openwrt driver bin contains stuff they don't want to disclose, and that most likely is not available in the linksys driver sources.

I mean linksys or the guy that worked on the openwrt stuff definitely knows, that openwrt devs would not accept any bins. If you have the knowledge to add support for it you definitely must know that. Thus all their actions are on purpose and there is no so called "bad communication".

But the situation is simple, if there is no openwrt/dd-wrt/tomato... support for this unit in the next few month, even the dumbest customer will be aware of that before buying the router.

Then there will be a new Asus with the same or better specs and with the best oem firmware and probably it will get rmerlin, tomato and dd-wrt support like always.

 

[chadster766]

I was under the impression that Linux adapter drivers were normally given out in a binary executable.

Isn't the "rewrite" you mention a complaint that driver source code provided by marvel needs to be modified to work with OpenWrt better?

Right now it's only the wireless 5ghz N by itself that isn't working. The other wireless protocols and AC seem fine

 

[sfx2000]

Oh I do, been around mobile F/OSS stacks heaps over the yrs*, WR stacks not so much.
I just found the post I was responding to, amusing...
To be so presumptuous is odd, this is a regularly evolving & fluid situation.
It's very early days in the project's life-cycle comparatively speaking, things look like they may change, yet again:
https://forum.openwrt.org/viewtopic.php?pid=232738#p232738
Thanks for trying to be informative though, no offence taken at all...

*Maemo/MeeGo, OpenWebOS, Android (eeeiiiwww), MeR/Nemo/Sailfish, Tizen, Ubuntu-Touch etc.

[anyway, unsubscribing from this thread, too busy & too many distractions]

I think we've both had our share of fun working on FOSS stacks - bringing up masmo/meego and tizen, reminds of hours of fun (and pain) spending time on stretch-board with JTAG, serial cables, and whatnot... those were the days

@Jalyst - again, my comment wasn't directed at you, it on the comment/rant posted by someone else -- sfx