I'd use the latest patches sent to the openwrt-devel the other day and build off source checked out from the recommended revision.  I still need to look at that further and see if its any different than the patches that are/were up on github

I've done some initial analysis back when they first opened up the Mamba repo and there are *a lot* of changes-- although the bulk of them seem to be due to Mamba using a different commit baseline. I didn't run into anything in Mamba that was interesting.

I've experimented with the git head and things seem to run fine (1/2 day of testing)--- caveat the wifi as the binary module won't load into head as they've updated the kernel version.

I'd stick with the recommend commit hash unless your goal is to play around. In which case better make sure you are ready to flash via serial

My config: http://pastebin.com/PfGbYVTP

Note, I have a handful of things enabled they you may not want, netatalk, hfs+, bind, lightly, xmail....

Does anyone know if the LAN ports can be segmented? The bridging config appears to only refer to the LAN ports as eth0

I'm actually building based off the recently-made-public Mamba repo: https://github.com/jimmychungbelkin/Mamba

The repo itself seems to come with everything to build the code, but patch 0085 seems to fail. It actually looks (Based on grabbing the kernel it's building against) that the bug patch 0085 is supposed to fix has already been fixed in 3.10.32.

This is the list of patches in the current Mamba head that have failed and appear to already be included in the 3.10.32 kernel (Or are duplicates of different numbered patches):
/target/linux/mvebu/patches-3.10/
----------------------------------------------------
0085-irqchip-armada-370-xp-fix-IPI-race-condition.patch
0196-ata-sata_mv-setting-PHY-speed-according-to-SControl-.patch
0304-ARM-mvedu-nand-2048-pagesize-support.patch
0305-ARM-mvedu-nand-mamba-nand-support.patch
0306-ARM-mvedu-add-I2C0-note-dtb.patch
0307-ARM-mvebu-USB20-dtb.patch
0308-ARM-mvedu-mamba-nand-force-4bit-ecc.patch
0310-ARM-mvebu-support-fixed-phy-dts.patch
0310-ubifs-xattr-fix-no-longer-define-config.patch
0311-ARM-mvebu-add-button-node-dtb.patch
0313-ARM-mvebu-fan-monitor.patch

/package/libs/openssl/patches/
-----------------------------------------------------
120-cisco-dtls-fix.patch

/package/libs/polarssl/patches/
------------------------------------------------------
300-openssl_cipher_name_compat.patch

[Edit w/ Update]
With those patches removed, the image patches, builds, and runs.

(Last edited by Drakia on 12 May 2014, 06:07)

My recollection is the Mamba repo is actually behind. Took another quick glance and the kernel is behind and a couple of the shell scripts seem to be older versions.

(Last edited by jklap on 12 May 2014, 13:57)

I understand this post can be seen as offtopic, but I am willing to get some attention.
Who on earth is in charge for OpenWRT.ORG home page?
It's really disturbing to see those 3 years old "Headlines", the "Documentation" link under "Latest release" section pointing to Kamikaze while the Documentation link in the headline points to the Wiki.
I already raised this point at least twice in the past. With no chances.
In the beginning I could not even open a ticket, as the tracking system was not sending the verification token to me until I pressed the "resend email" button.
Now we have a ticket none is taking care of.

I do really think this project deserves something better that this. Doesn't it?

P.S.
If I disturbed you, the reader, that wasn't intentional. I am sorry.

Odd that it would be behind when they just pushed code to it a few days ago. Are you using the wrt1900ac repo over the recommended revision?

Sorry-- should have clarified-- my comparison was when they originally had opened Mamba to the public at which point I compared it against OpenWrt with their commit hash. Might be worth a re-review.

Ah okay. There was a commit on May 6th marked "v4.3_rc" and when I compared it against the OpenWRT r40006 it didn't seem too off (Though I only did a quick compare, didn't look too far into it). They did really mess up the patches though, duplicates and unneeded patches in a couple places.

Gave OpenWRT git head a try again... last time it had some issues and I bricked.

root@faster:~# uname -a
Linux faster 3.10.36 #2 SMP Mon May 12 09:51:04 CDT 2014 armv7l GNU/Linux
root@faster:~# cat /etc/banner
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r40752)
 -----------------------------------------------------
  * 1/2 oz Galliano         Pour all ingredients into
  * 4 oz cold Coffee        an irish coffee mug filled
  * 1 1/2 oz Dark Rum       with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -----------------------------------------------------

This was one of the reasons why:

commit 3296c14614211043dd2d2757c784bfc7b192accb
Author: nbd <nbd@3c298f89-4303-0410-b956-a3cf2f4a3e73>
Date:   Wed Mar 26 10:50:09 2014 +0000

    mtd: add support for bad blocks in NAND flash

    NAND flash is very likely to contain bad blocks.

    Currently, mtd and therefore sysupgrade fails when it encounters a single bad block, potentially leaving an unbootable system.

    This patch allows the mtd utility to skip bad blocks in NAND flash and complete sysupgrade successfully.

nand_read_bbt: Bad block at 0x000003820000

So far it looks good-- wifi does come up but haven't tested much yet to see if the disconnect is still there.

That's awesome. Is that OpenWRT git head with the patches from here https://github.com/wrt1900ac/opensource … er-Breaker applied?

Also, it looks like new patches were just pushed 4 minutes ago, wonder what the difference is.

[Edit]
Ah nice, I've got that running too:

root@OpenWrt:/etc/config# uname -a
Linux OpenWrt 3.10.36 #3 SMP Mon May 12 17:43:18 PDT 2014 armv7l GNU/Linux

root@OpenWrt:/etc/config# cat /etc/banner
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r40755)
 -----------------------------------------------------
  * 1/2 oz Galliano         Pour all ingredients into
  * 4 oz cold Coffee        an irish coffee mug filled
  * 1 1/2 oz Dark Rum       with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -----------------------------------------------------

(Last edited by Drakia on 13 May 2014, 02:06)

Looks like the 2.1 patch submission is mostly a re-work of the existing patches based on responses to the original patch set on the OpenWRT mailing list. Of course they submitted the 2.1 patches late last week and got lots of additional feedback.. so suspect we'll see another re-work in a couple of weeks

Note, from what I can see applying this patch set will require a fine-tooth comb walk through on the config file.

Yup, they changed some of the config option names in this patchset compared to 1.6. I did get it to compile, and am running it right now. Will keep an eye out for any CPU stalls like their image was giving me.

WTF's happening with source for the wireless drivers?
Why STILL confusion/uncertainty, getting beyond a joke.

If I remember right there is code released for the wireless driver, but it was a mess. I'm also not sure whether it was signed off or under a license usable by OpenWRT

Yes, but there's been very little progress (or updates on that progress) since then, WTF are Linksys/Marvell doing.
This isn't the early days when Linksys started this entire game, they can't expect to be less open (overall) than they were back then.
The entire field is far more competitive/dynamic nowadays...
If they want to garner serious interest/momentum, they need to heed the several (very pertinent) criticisms that've been levelled.
Which (so far) they still seem completely oblivious too...

Oh I know, their patches submitted to OpenWRT still contain the binary driver instead of driver source. It's probably going to be quite a while before we see base support for the WRT1900AC built into OpenWRT itself. Until then, we're stuck using the Belkin/Linksys build, or building our own firmware.

At this rate it'll never be added, or be added in a ridiculously late time-frame.
At which point this device will be a white elephant, comparatively speaking.
I mean look at this FFS...
http://www.dd-wrt.com/phpBB2/viewtopic. … 492#895492

It's more likely that Belkin's patches will be the base for someone ELSE to create a proper implementation. Based on how little Belkin is changing due to the feedback from the OpenWRT guys, I don't think their patches will be added to the trunk before someone else says screw it and adds support themselves.

Git head. USB support now

Ask them...

I did*, & in perhaps an indication of future inaction/incompetence, there was nothing but radio silence.

*albeit via Twitter, which admittedly isn't the best medium to relay concern/criticism

(Last edited by jalyst on 14 May 2014, 08:10)

The guy Matthew Fatheree posting to the openwrt mailing list was responsive when I mailed him earlier.  You might try again though.

On 4/18 I received the following reply.

(Last edited by nyt on 14 May 2014, 08:15)

I unsub'd from that list, too high volume, maybe later I'll get his direct addy & try him...

(Last edited by jalyst on 14 May 2014, 08:18)

Were you having problems with USB before?