Boot the router normally, then transfer the firmware over to the router (/tmp is good) somehow. You can SCP from your computer, or if your Internet connection is up from the router you can use wget to fetch it, e.g.

root@OpenWrt:/# cd /tmp
root@OpenWrt:/tmp# wget http://downloads.openwrt.org/snapshots/trunk/mvebu/generic/openwrt-mvebu-armada-xp-mamba-squashfs-sysupgrade.tar

then either of

Save settings:

root@OpenWrt:/tmp# sysupgrade -v openwrt-mvebu-armada-xp-mamba-squashfs-sysupgrade.tar

Don't save settings:

root@OpenWrt:/tmp# sysupgrade -n -v openwrt-mvebu-armada-xp-mamba-squashfs-sysupgrade.tar

If you want to go to Linksys or something else it's the same syntax; just replace the sysupgrade.tar file with the .img or .bin or whatever it uses.

n.b., in case you see it elsewhere: with most routers you can use sysupgrade with http directly (e.g. sysupgrade -v http://whatever/blah.bin), but that didn't seem to work with a .tar file last I tried.

Anyone got an idea about Wifi performance?

Well........lol...........still not up and running.

Now I have a WRT1900AC to try and revive.

As a side point, I bought this router the day it was on the shelf and waited this long to get a decent firmware.

I checked out ASUS website, the AC87U is fully DD-WRT compatible, right on the ASUS website. So, I went and
got one, flashed it with DD-WRT and all I can say is HOLY CRAP!!!! Best Router I've ever used. If I ever revive the WRT, it will make a great AP.

@mojolacerator

If your router doesn't boot anymore:

https://github.com/Chadster766/McWRT/wiki/WRT1900AC-corrupt-bootloader-recovery

If your router does boot but is missing the firmware:

https://github.com/Chadster766/McWRT/wiki/Flashing-Firmware-using-a-USB-to-TTL-Cable

nitroshift

(Last edited by nitroshift on 1 Mar 2015, 06:59)

@ nitroshift

Thanks, but the hit any key to stop, does not work. I can only get into Openwrt failsafe mode.

@mojolacerator

I recommend you flash the u-boot then carry on with flashing the firmware from the USB connection.

nitroshift

Is the build bot borked?

For the last few days I haven't been able to connect to:
http://buildbot.openwrt.org:8010/builders/mvebu

and no new snapshots since the Feb 25:
https://downloads.openwrt.org/snapshots … u/generic/

Someone forgot to pay the bill.. Ok people, let's pack our stuff and go home

Guys, are you using CC build now ? What about kaloz builds (last from 14th Feb) at the moment ?

Are the CC coming with everything else that was on kaloz builds ?

@belliash,
Poor overall WiFi speed with OpenWrt Chaos Calmer is a known issue due to the open source WiFi driver provided by Marvell, but, if I understand you correctly, what you're seeing is a drop in WiFi performance after some period of time, correct? FWIW, I have the same issue with WiFi performance, and have even RMA'd the router a few weeks ago, and still have the same issue with the new router: WiFi speed starts off fine then suddenly drops off (~2-3Mbps) after some period of time (a couple of days). In my case, this drop in speed happens with both OpenWrt and stock Linksys firmware (although the latter offers better initial WiFi speeds - I can get my full 30Mbps down, where I only get 15Mbps down with OpenWrt). What amazes me is that you're the only person that I've seen complain about the drop off in WiFi speed after some period of time (although this thread has gotten pretty long and I might have just forgotten) - but it seems that most people are using a hard-wired connection and reboot their router frequently (which, temporarily, fixes the problem) when they install a new firmware.

So... while not a solution for you, FWIW, you're not alone with the drop in WiFi speed, I feel your pain as, pretty much, all of my devices are wireless, but a reboot temporarily fixes the issue and it seems to be the same with stock firmware...

(Last edited by silca on 1 Mar 2015, 16:50)

To all:

I got tired of arguing with the WRT1900AC, and tired of waiting for Marvell/Belkin/Linksys to come good on their promise of making this router truly opensource and releasing current drivers etc. My router bricked for the 4th time. Yesterday, due to my own lack of time I shelved the WRT and I bought an AC87U with the intention of reviving the WRT1900AC when I do have time. I flashed DD-WRT on the AC87U, from unpacking to active use, took 25min. The WRT1900 never dreamed of the day it could perform like this ASUS router.

I'm not sure I'm going to even bother with the WRT1900. I switched from Linksys to ASUS when the N56U came out. Then bought the N66U. Being nostalgic, I bit on the WRT1900. Now I'm back to ASUS, going to be a looooooong time before I try anything "Linksys" again.

I do appreciate all the time everyone volunteered to the development of Openwrt on this router.

Sorry to see you go. Thanks again for your contributions. I managed to debrick my WRT1900ac per your guidance and that of others. And I persist.

Chaos Calmer r44532 / LuCI (git-15.051.48491-4137afe) - Feb.25 full img. Just now hitting 4 days uptime. No drops in performance. I have about a dozen clients that include laptops, tablets, phones (even a washer / dryer pair). Acrylic Wifi reports an average RSSI on both radios of -25db (Ch.1 / Ch. 149). My (desktop) (Asus) wireless ac adapter reports a 1.3 Gbps connection speed. The router is located on the lower floor of a single family dwelling (below grade) in a relatively uncongested area. My spouse, on the second floor, pulls about 700 mbps via an Intel ac wifi card on a 5 year-old laptop. I realize this kind of reporting does nothing for you if you're experiencing problems, but it may encourage you if you're contemplating a kick at the can.

(Last edited by grimley on 1 Mar 2015, 17:30)

No, this is the preferred method... except it works best from ssh

I think he meant whether or not to use the particular image I had posted, which is based on a highly experimental early build of kernel 4.0-rc1.

Not sure I agree with the second part, apart from being able to see what's going on. What about it do you think works better from the command line? LuCI is just calling sysupgrade for you if you do it through the web interface. It writes the uploaded firmware file to /tmp/firmware.img and runs /sbin/sysupgrade on that -- not any different than scp'ing or wget'ing the image to /tmp and running sysupgrade yourself.

ok, I was not aware you could sysupgrade from the webif...   either way sysupgrade is the preferred method to install new builds openwrt.

Lets wait & see before being so sure...
There's only so long this kinda thing can be strung out before:
(1)
Official change of direction (+ an apology or excuse) is announced.
(2)
Official apology + continued direction + actions to back-that-up...
(3)
death is unofficially announced by the community at large after an extended period of WTF!?%$&#*

I agree with jalyst

Got excited by this post, but did some reading and now not so exited.  DD-WRT is having stability issues that include spontaneous reboots.  Might still give it a try though.

has anyone solved the usb -> nfs/samba problem?

I am running r44532 (trunk), I've installed kmod-fs-nfs and kmod-fs-ntfs with no change, the fileshares are not present. There is no luci config, nor can I find any config files related to either in ssh.

(Last edited by digitalgeek on 2 Mar 2015, 03:20)

@carlos.quiron and @leitec - have a look at the diagram below.  I have a /29 public IP address space I have been using for the last 7 years in a two router configuration.  Public facing router does routing based on the public IP address space, and the second wireless router behind the public router would serve the private Wifi and LAN devices.  I am collapsing into one device using the 1900AC (I hope).

How can I configure a VLAN(s) that would allow me to hang my servers with the public IP address off the LAN ports along with devices in the private IP space?  Can you show me a modified /etc/config/networks file?

Thanks!

(ISP x.x.x.160/29)
       ^
       |
       v
  VDSL Modem
       ^
       |
       v
WAN (x.x.x.161/29)
     1900AC
(192.168.1.1/24)
      WIFI <---> Devices (192.168.1.x/24)
      LAN  <---> Devices (192.168.1.x/24)
       |-------> Servers (x.x.x.162-166/29)

(Last edited by hacksaw on 2 Mar 2015, 05:50)

@digitalgeek

Have you installed Samba too? What filesysytem is your hard-disk formatted in? I never encountered problems, even on the early-experimental 4.0-rc1 firmware, although I have removed Samba and stayed with nfs shares which need a totally different approach.

nitroshift

@leitec

4.0-rc1 (which Linus said it was actually 3.20 but renamed to 4.0 due to users request) seems stable enough to be flashed on a production device. Testy has passed all connectivity and stability tests since I flashed it, as it never slowed down, hung on me or rebooted. I do NOT advise anyone that is not familiar with recovery and / or system files modifications to use it as yet though.

nitroshift

(Last edited by nitroshift on 2 Mar 2015, 07:23)

@hacksaw
I don't know for sure, but based on this layout https://s3.amazonaws.com/Justin.Schuhma … layout.png
I think the basic configuration you need is something like this:
"config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 5'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '3 4 6'
"
plus your layer 3 interfaces (LAN and WAN)
for LAN you have to use eth0.1 and for WAN eth1.2
then plug your server in port 3 (base on the layout is port 1 in linksys) and your ISP in port 4 (base  on the layout is WAN port)
maybe leitec could confirm.

What about errors seen on eth1 (wan)? Anyone else having this?

[  373.104850] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=1512
[  385.232830] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=947
[  410.449674] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=1197
[  500.741130] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=1146
[  517.378288] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=1186
[  519.598396] mvneta f1074000.ethernet eth1: bad rx status 0f810000 (crc error), size=1231

          RX packets:23099 errors:62 dropped:0 overruns:0 frame:0
          TX packets:17803 errors:0 dropped:0 overruns:0 carrier:0

Anyone?

(Last edited by belliash on 3 Mar 2015, 21:31)

I did my first attempt at a openwrt install by using OpenWrt Chaos Calmer r43823 / LuCI Master (git-14.359.33351-5e6c33e) and I am facing a weird problem.
I got PC1 on ethernet directly cabled into the router and Laptop connected on radio0 with N.
Now my Laptop can see DHCP Inform packets made by itself on wifi and PC1 on eth. It cannot however see DHCP ACK packets made in reply to DHCP Inform packets. My PC1 can see these DHCP ACK packets tho are being made by the router's DHCP-server.
Now I thought that I couldn't see the router, but when my Laptop made a DHCP Request (from 0.0.0.0), it did get the DHCP ACK packet.

While I was writing this another weird thing happened with DHCP:
Wireshark on my Laptop tells me it sent 1 DHCP Request packet.
Wireshark on my PC1 tells me that it received 36 DHCP request packets but 0 DHCP ACK packets.
Wireshark on my laptop tells that it received 36 DHCP ACK packets.

Each DHCP Request packet seen on PC1 has the same Identification header.
Each DCHP ACK packet seen on Laptop has a unique Identification header (and checksum).
Not sure how the packet got replicated.

Network on Ethernet:
* nas-server
* printer
* PC1
* TV
Each on their own port on the router, no switches involved.

Network on Wifi:
* Android phone
* Laptop running windows 7

Yeah, nothing magical about the version number It's just coincidental that a probably-relevant fix landed with this version (see https://git.kernel.org/cgit/linux/kerne … mach-mvebu) It could also be an improvement/fix elsewhere (i.e. not mvebu-specific) that I haven't seen yet (or both, of course).

I suppose we can't actually "prove" the lockups people are reporting don't happen anymore, since nobody has figured out what triggers it. But it's still encouraging that it's working for you and l3333.

edit: looking into backporting just the relevant fixes to 3.18. that might be the way to go.

(Last edited by leitec on 2 Mar 2015, 13:13)