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.

Once you have confirmed output from the serial port, power cycle the router and a few seconds into the boot cycle it will count down from 3 and allow you to hit a key to get into failsafe mode. That will get you the uboot console. Nyt has posted instructions for flashing from tftp on page one of this topic.

If you just want console access to the router firmware, then wait for the full boot sequence and hit enter once it's done to get a console.

Thanks but I'm looking to get into "single user mode" if its possible. Typically I would modify the bootargs or similar variable to include "single" at the end of it.

With the RedBoot Loader I run the fsconfig and add "single" to the variable in there. I don't have any experience with the U-Boot Loader.

Chadster766 wrote:

Thanks but I'm looking to get into "single user mode" if its possible. Typically I would modify the bootargs or similar variable to include "single" at the end of it.

With the RedBoot Loader I run the fsconfig and add "single" to the variable in there. I don't have any experience with the U-Boot Loader.

Why? Just curious

jklap wrote:
Chadster766 wrote:

Thanks but I'm looking to get into "single user mode" if its possible. Typically I would modify the bootargs or similar variable to include "single" at the end of it.

With the RedBoot Loader I run the fsconfig and add "single" to the variable in there. I don't have any experience with the U-Boot Loader.

Why? Just curious

Single User Mode in Linux has a multitude of uses. The main ones are root password resets and drive maintenance.

Standard Linux stuff.

Chadster766 wrote:

Single User Mode in Linux has a multitude of uses. The main ones are root password resets and drive maintenance.

Standard Linux stuff.

Yes, I'm familiar with single user mode... for servers & desktops.

Hitting enter on a serial console after booting gives you a root prompt. You can reset root's pw without an issue.

Root fs, which is often what you are fsck'ing in single user mode isn't needed on the WRT1900AC as it's flash with an overlay. And if the overlay is hosed, well, it's hosed and fsck won't fix it. If your doing something like a root pivot-- again, it simply won't pivot because it won't mount-- no need to single user to fix.

But if you want to give it a go anyway (caveat that there aren't actually runlevels in OpenWrt that I know of wink then printenv & setenv are your uboot friends with "linksys_nandboot" and "linksys_altnandboot" the two variables that contain the bootargs depending on which firmware you are booting from.

You can also manipulate them from the shell using fw_printenv and fw_setenv

root@faster:~# fw_printenv nandboot
nandboot=run linksys_nandboot

root@faster:~# fw_printenv linksys_nandboot
linksys_nandboot=nand read $default_load_addr $pri_kern_addr $pri_kern_size; setenv bootargs $console $default_mtdparts root=/dev/mtdblock5 ro rootfstype=$fs_type init=/sbin/init; bootm $default_load_addr;

root@faster:~# fw_printenv linksys_altnandboot
linksys_altnandboot=nand read $default_load_addr $alt_kern_addr $alt_kern_size; setenv bootargs $console $default_mtdparts root=/dev/mtdblock7 ro rootfstype=$fs_type init=/sbin/init; bootm $default_load_addr;

(Last edited by jklap on 22 May 2014, 18:56)

jklap wrote:
Chadster766 wrote:

Single User Mode in Linux has a multitude of uses. The main ones are root password resets and drive maintenance.

Standard Linux stuff.

Yes, I'm familiar with single user mode... for servers & desktops.

Hitting enter on a serial console after booting gives you a root prompt. You can reset root's pw without an issue.

Root fs, which is often what you are fsck'ing in single user mode isn't needed on the WRT1900AC as it's flash with an overlay. And if the overlay is hosed, well, it's hosed and fsck won't fix it. If your doing something like a root pivot-- again, it simply won't pivot because it won't mount-- no need to single user to fix.

But if you want to give it a go anyway (caveat that there aren't actually runlevels in OpenWrt that I know of wink then printenv & setenv are your uboot friends with "linksys_nandboot" and "linksys_altnandboot" the two variables that contain the bootargs depending on which firmware you are booting from.

You can also manipulate them from the shell using fw_printenv and fw_setenv

root@faster:~# fw_printenv nandboot
nandboot=run linksys_nandboot

root@faster:~# fw_printenv linksys_nandboot
linksys_nandboot=nand read $default_load_addr $pri_kern_addr $pri_kern_size; setenv bootargs $console $default_mtdparts root=/dev/mtdblock5 ro rootfstype=$fs_type init=/sbin/init; bootm $default_load_addr;

root@faster:~# fw_printenv linksys_altnandboot
linksys_altnandboot=nand read $default_load_addr $alt_kern_addr $alt_kern_size; setenv bootargs $console $default_mtdparts root=/dev/mtdblock7 ro rootfstype=$fs_type init=/sbin/init; bootm $default_load_addr;

Thanks that's exactly what I was looking for smile

It will be interesting to find out if "Single User Mode" is available.

What are the U-Boot commands to TFTP the active firmware image for backup and restore?

(Last edited by Chadster766 on 22 May 2014, 19:07)

Chadster766 wrote:

What are the U-Boot commands to TFTP the active firmware image for backup and restore?

Restore would be the same as what nyt noted earlier:

setenv ipaddr 192.168.200.1
setenv serverip <tftpd_server_ip>
setenv firmware_name <name>
run flash_pri_image
[or]
run flash_alt_image

I don't believe there is anyway to backup a firmware from within uboot-- at least not as a hack. See http://wiki.openwrt.org/doc/howto/generic.backup for a couple of notes.

But you can probably back it once you've booted-- something along the dd lines with /dev/mtdblock* .. I believe the firmware is actually the combination of 2 (maybe 4 & 5 and 6 & 7??)

Thanks smile

Chadster766 wrote:

Can I get some simple point form instructions on?...

I would suggest starting a new thread with that request. Your likely to get a better response (ie more viewers) along with no one yelling "off topic" on this thread.

jklap wrote:
Chadster766 wrote:

Can I get some simple point form instructions on?...

I would suggest starting a new thread with that request. Your likely to get a better response (ie more viewers) along with no one yelling "off topic" on this thread.

Done, thanks for the heads up wink

Rainor wrote:

New .TAR posted on Linksys WRT1900AC GPL download

http://support.linksys.com/en-us/gplcod … #WRT1900AC

WRT1900AC_RC2_SP1_v1.1.7.160582.tar


What is this?  Anyone know?

That's the latest WRT1900AC Linksys firmware version.

(Last edited by Chadster766 on 24 May 2014, 06:17)

The new code in the GPL center contains a new build of the AP8X.ko driver (v7.2.5.6), but unlike the previous one, contains no source code for the wireless driver.

Driver looks like it was built May 15th. I'll give it a test later today, see if it resolves any of the crash issues.

Drakia wrote:

The new code in the GPL center contains a new build of the AP8X.ko driver (v7.2.5.6), but unlike the previous one, contains no source code for the wireless driver.

Driver looks like it was built May 15th. I'll give it a test later today, see if it resolves any of the crash issues.

Does it look like these...

https://forum.openwrt.org/viewtopic.php … 87#p233687

(Last edited by gufus on 24 May 2014, 19:40)

gufus wrote:
Drakia wrote:

The new code in the GPL center contains a new build of the AP8X.ko driver (v7.2.5.6), but unlike the previous one, contains no source code for the wireless driver.

Driver looks like it was built May 15th. I'll give it a test later today, see if it resolves any of the crash issues.

Does it look like these...

https://forum.openwrt.org/viewtopic.php … 87#p233687

ap8x.ko
Size: 12.9 MB (13,544,439 bytes)
MD5: DA7978F58D12987521B4EBB7C4D0A114
CRC32: 59805BE3
SHA-1: E30C13C9F7A3AF062D869FFF2FD9D35E7D6CDBC5

quite a bit larger eh  hmm

(Last edited by gufus on 24 May 2014, 20:18)

gufus wrote:

quite a bit larger eh  hmm

It's not stripped
It's also not likely you'll get too far..

vermagic:       3.2.40 SMP mod_unload ARMv7

nyt wrote:

It's not stripped

Ah...

nyt wrote:
gufus wrote:

quite a bit larger eh  hmm

It's not stripped
It's also not likely you'll get too far..

vermagic:       3.2.40 SMP mod_unload ARMv7

Indeed, not usable with the trunk OpenWRT. Wonder why they ditched the source for the driver and just included the binary in this release though...

I just want to say that I have bought this router and I am amzed by it so far. In fact I see no reason why I would want to flash it with openwrt at the moment. When I have done tests with grc port scan and PC flank stealth test every thing gets passed. I can not achieve any thing close to those results with openwrt unfortunately.

zopico wrote:

I just want to say that I have bought this router and I am amzed by it so far. In fact I see no reason why I would want to flash it with openwrt at the moment. When I have done tests with grc port scan and PC flank stealth test every thing gets passed. I can not achieve any thing close to those results with openwrt unfortunately.

The only thing that GRC Port Scan and PC Flank Stealth Test check for is ports you have opened (OpenWRT by default won't open any ports to the internet), or ping response (This can be disabled, though I'm not sure if it's included in LUCI or not. Might need to be done via command line).

The description that GRC gives for ports is extremely exaggerated (443 is not used for only credit card information, and "This implies that the successful intruder could access the web server's credit card database and score bigtime" is laughable at best. Having port 80 open is common practice for anyone who does web dev work).

Having ICMP echo response enabled does "better hide systems from hackers" to an extent, but if you've already got every port closed, an ICMP echo response won't matter, and if you don't have every port closed, an ICMP echo response won't matter. So in short, an ICMP echo response really isn't going to matter.

I flash OpenWRT so I can fully utilize and customize my router, the stock firmware lacks far too much to be useful to anyone except the most basic of end user.

As they've pulled the file containing the driver source from the GPL Code Center, I've uploaded the code from April 4, 2014 to GitHub: https://github.com/TheDgtl/mrvl_wlan_v7drv

The code is licensed under GPLv2 according to the headers in all the source documents, so distributing it shouldn't be an issue.

Drakia wrote:

Wonder why they ditched the source for the driver and just included the binary in this release though...

Good question

I've asked about the wifi driver

Always the same answer sad
https://forum.openwrt.org/viewtopic.php … 04#p233604

gufus wrote:
Drakia wrote:

Wonder why they ditched the source for the driver and just included the binary in this release though...

Good question

I've asked about the wifi driver

Always the same answer sad
https://forum.openwrt.org/viewtopic.php … 04#p233604

Do they know their binary driver doesn't work so well?  My inquiries were met with silence =[