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.

JW0914 wrote:

@LogicoZone It's physically impossible to "brick" any of the WRT AC Series routers, as they can be reflashed directly via serial [port]using a USB-TTL cable/Arduino/RS232-TTL converter, and even if one fully corrupts the bootloader, that can also be rebuilt thanks to Nitroshift's work with Stefan Roese of U-boot.

Well, you can brick it with a large enough hammer wink

But yes, as long as the hardware isn't damaged recovering is always possible.

@sera,
I have a problem installing the kernel-4.12 modules. With the cores less than 4.12, there is no problem. Here is the output listing.

root@wrt3200acm:/home/kernel/linux-4.12-rc2# make ARCH=arm CROSS_COMPILE=arm-none-eabi- INSTALL_MOD_PATH=/ modules_install
  INSTALL crypto/authenc.ko
cp: cannot stat ‘crypto/authenc.ko’: No such file or directory
  INSTALL crypto/authencesn.ko
cp: cannot stat ‘crypto/authencesn.ko’: No such file or directory
  INSTALL crypto/deflate.ko
cp: cannot stat ‘crypto/deflate.ko’: No such file or directory
  INSTALL crypto/echainiv.ko
cp: cannot stat ‘crypto/echainiv.ko’: No such file or directory
.... 
And so on to the end

The module files are created but not copied.
I would be happy to your advice.

(Last edited by ValCher on 29 May 2017, 23:19)

sera wrote:
LogicoZone wrote:

1. Does OpenWRT image for WRT1900ACx supports failsafe mode? I tried to follow the instruction. It doesn't seem having failsafe mode and while listen to the broadcast message, there is no message at all.

Should work but have never tried myself. Not needed to debrick at all.

LogicoZone wrote:

2. I tried serial port but almost always that the power led and SATA led are lit and nothing happen. Only once, it seems I got serial output to console but the freeze.

I don't understand what exactly you are doing. Did you ever connect the usb2tll cable before and had proper console output? Ie. you actually know how to do it and confirmed it was working?

Yes. As said, I've connected the pin correctly and plug-in the usb to pc with putty opened and connected to the right com port.

The problem is I've tried at least dozen times. As soon as I turn on the router, the power led and SATA led turned on with no console output. I saw some other people having same issue on other forum.

During several tries, I only successfully get serial console output to show some boot sequence but then it showed some garble characters after some seconds.

I'd like to see what does solid power and sata led mean? I cannot figure out why it seems working for just once and what's the difference for all other failed attempts. All pin connection and putty settings are identical for all attempts.

JW0914 wrote:

@LogicoZone It's physically impossible to "brick" any of the WRT AC Series routers, as they can be reflashed directly via serial [port] using a USB-TTL cable/Arduino/RS232-TTL converter, and even if one fully corrupts the bootloader, that can also be rebuilt thanks to Nitroshift's work with Stefan Roese of U-boot.

Ok. seems everyone sees "bricked" and start getting excited on how it's impossible to brick wrt. smile

I'll rephrase.

It seems I have issue to get serial console output with usb-to-ttl cable and putty on windows. See my other post. It seems the pin is connected properly and putty setting is ok. It must be somewhere I'm doing it wrong where I seems getting console ouput for once.

@LogicoZone

Make sure the contacts in the pin header are OK and that you don't use the Vcc pin.

@JW0914

nitroshift isn't spelled with a capital 'N'.

@sera

Thanks for your work.

nitroshift

LogicoZone wrote:
sera wrote:
LogicoZone wrote:

1. Does OpenWRT image for WRT1900ACx supports failsafe mode? I tried to follow the instruction. It doesn't seem having failsafe mode and while listen to the broadcast message, there is no message at all.

Should work but have never tried myself. Not needed to debrick at all.

LogicoZone wrote:

2. I tried serial port but almost always that the power led and SATA led are lit and nothing happen. Only once, it seems I got serial output to console but the freeze.

I don't understand what exactly you are doing. Did you ever connect the usb2tll cable before and had proper console output? Ie. you actually know how to do it and confirmed it was working?

Yes. As said, I've connected the pin correctly and plug-in the usb to pc with putty opened and connected to the right com port.

The problem is I've tried at least dozen times. As soon as I turn on the router, the power led and SATA led turned on with no console output. I saw some other people having same issue on other forum.

During several tries, I only successfully get serial console output to show some boot sequence but then it showed some garble characters after some seconds.

I cannot figure out why it seems working for just once and what's the difference for all other failed attempts. All pin connection and putty settings are identical for all attempts.

Are you using female pins with a 2.0mm pitch or the more common 2.54mm pitch?  All WRT AC Series headers have a 2.0mm pitch, and while 2.54mm pitch female pins will work in a pinch, one has to ensure they're properly insulated with vinyl [electrical] tape and cocked just so.

  • Unless there's some physical damage to the serial header, then your female pins aren't making a consistent connection to the header pins, which explains the intermittent and garbled output.

  • Ensure header pins 1 (Gnd) and 4 (Rx) have a solid connection (Tx is 2), and ensure your header pin count is correct (triangle on PCB annotates pin 6), as all Armada 385 boards have the header flipped horizontally.

    • I've been meaning to upload a photo of the Armada 385 header to the wiki, and keep forgetting to take the photo.

If doing what @nitroshift suggested and the above do not work, you may have a cable issue (while a header issue is possible, it's highly unlikely)... if you have a multimeter/voltmeter, test continuity between each header pin and the corresponding USB pin. 

  • You don't need to look up the USB female pin out, though an image search should show the pin out in the first few results returned, simply ensure each USB pin only has continuity with one of the three female header pins, and that one USB pin has no continuity with any of the 3 female header pins.

    • Continuity symbol is the diode symbol (arrow with a vertical line across the point) with horizontal signal waves radiating left or right from it.

I'd like to see what does solid power and sata led mean?

If only Power and eSATA lights are lit, it means the firmware has experienced a fatal error during the boot process, meaning at least one of the firmware partitions is corrupted.  You can switch partitions via the Firmware Recovery process.

Does OpenWRT support... failsafe mode?

OpenWrt did have a failsafe mode capability prior to CC (via a package that can be installed), however it's strongly discouraged due to the massive security risk it poses.  I would never recommend anyone utilize it, both because of the massive security risk, but also because it's simply not needed.

  • If a device is capable of running OpenWrt, then a user flashing OpenWrt should already know prior to flashing they should have access to a USB-TTL cable, Arduino/Raspberry Pi, or a breakout board for RSxxx, accompanied by a RSxxx serial cable. Provided the user has one of the three, there's no point to attempt to implement and utilize fail safe mode.



@nitroshift  Noted =]   It's simply a habit to capitalize names, and occasionally I forget to correct forum names in the proof read prior to posting.

(Last edited by JW0914 on 30 May 2017, 06:31)

JW0914 wrote:

@nitroshift  Noted =]   It's simply a habit to capitalize names, and occasionally I forget to correct forum names in the proof read prior to posting.

Thanks all. I'm going to give it a try again.

JW0914,

looking at the boot log found on the wiki failsafe is still present in DD.

[ 5.275239] init: - preinit -
 Press the [f] key and hit [enter] to enter failsafe mode
 Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
 [ 8.594314] mount_root: loading kmods from internal overlay

Also how would removing help security? If you have physical access you can do as you please.

---

ValCher,

you build the kernel natively in McDebian, so if the toolchain is installed properly a simple "make && make modules_install" should do. From your output alone I can't say what is wrong, will check later on another machine whether it works for me.

Something changed in kernel-4.12, I'll check all the settings again.

sera wrote:

JW0914,

looking at the boot log found on the wiki failsafe is still present in DD.

[ 5.275239] init: - preinit -
 Press the [f] key and hit [enter] to enter failsafe mode
 Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
 [ 8.594314] mount_root: loading kmods from internal overlay

Also how would removing help security? If you have physical access you can do as you please.

I completely missed that, and also just realized I should have checked the failsafe wiki, which has received some major updates in the past year.

  • The failsafe wiki used to state the requirement for enabling failsafe was installing the luci-mod-failsafe package, and, in the beginnings of this thread, there was a post about the massive security risk failsafe causes, with a recommendation to never utilize it.

    • It used to be where a specific button combination had to be pressed on the router was the only way the wiki spoke about accessing failsafe mode, which was discouraged as anyone with physical access to the router could bypass the root password or PKI entirely with a button press.  IIRC, one of the examples given was a guest in the home could gain root access in a fully inconspicuous manner.

(Last edited by JW0914 on 30 May 2017, 13:19)

ValCher,

make modules_install worked for me with 4.12-rc3, debugging your issue wouldn't belong into this topic either. Well, it's not generally broken.

---

JW0914,

don't know what nasty fellows you are willing to have as guests in your home.

@sera,
Thank you.

@sera

One bug with swrt: MAC addresses keep changing on every reboot.

nitroshift

ValCher,

got my hands on a functional specification for 38x now (the one for xp is public). So unlike I was told before the 385 also has the blinking hardware, so you can actually use the fan as a pwm-fan on your modded Rango unit without worry. Registers ranges and offsets are the same.

---

nitroshift,

true, but the same is / was true for OpenWrt and Shelby last I checked (only one is fix, the other random). DSA using the Ethernet with the random address as transport makes it more apparent. My custom config already sets mac addresses so I haven't thought about it. Will add stable and unique addresses for the default config with the next release. Thanks for the report.

@sera,
yes, I've already looked at it and I appreciate it.
A little bit from the theme profile. My module problem was in the mwlwifi driver, and he's not going to kernel-4.12. Everything else works. Excuse me again for off.

Oh, you're a genius!  smile

Got the problem fixed. My cp2102 adapter is a broken one. I got another adapter with another chip and it works.

@LogicoZone Just an FYI, generally speaking, most recommend any adapter with FTDI chips since they're high quality and well supported.  The downside is they're quite a bit more expensive (due to their high quality) compared to other chip manufacturers (an FTDI USB to TTL or TTL AJ shouldn't be bought for more than $25 - $30, whereas just a USB board like the CP2102 is generally in the $20 range)

(Last edited by JW0914 on 2 Jun 2017, 07:18)

dlang wrote:

serial adapters are available at much lower costs

Adafruit has three
$5.95 https://www.adafruit.com/product/3309
$14.75 (FTDI equivalent of the above) https://www.adafruit.com/product/284
$9.95 https://www.adafruit.com/product/954

I personally wouldn't recommend anyone buy a board or USB TTL cable that doesn't use an FTDI chip, as there's too many negative reviews about generic chips failing, and I've yet to see a negative review about ones with FTDI chips.

  • My oldest FTDI USB -TTL cable [I have 4] is 8 years old and still works flawlessly

FTDI charges a fairly high licensing fee, which is why even USB adapter boards out of Asia are always ~$10+, however FTDI has a solid product of high quality that's worth the extra few dollars.

  • I've seen too many reviews where time lost and shipping to replace a generic product with a failed chip ends up costing the same price, or more, as a product with an FTDI chip would have costed the first time round.

While it may save $5 - $10 to go with a generic product, is it really worth the chance of having that tool fail when you need it, as unless one has an Arduino or Pi, one generally only uses their USB TTL tool of choice when something has broken (I doubt most are like me, as I flash exclusively via serial)

(Last edited by JW0914 on 5 Jun 2017, 22:19)

JW0914 wrote:

I personally wouldn't recommend anyone buy a board or USB TTL cable that doesn't use an FTDI chip, as there's too many negative reviews about generic chips failing, and I've yet to see a negative review about ones with FTDI chips.

personally, I try to avoid FTDI, any company that releases drivers that are designed to break hardware I own (even if they claim it's 'counterfeit') should not get my money. There is a very long history of building devices that are work-alikes for popular hardware, and work with the same drivers to make it easy for users. Deciding that only devices they manufacture should be allowed to work with the drivers and not just refusing to work with other hardware, but going a step further and trying to permanently break that hardware is so far beyond reasonable I don't want to deal with them.

@dlang I've never had the experiences you've had, but I do understand where you're coming from.

(Last edited by JW0914 on 6 Jun 2017, 01:42)

FTDI USB -TTL cable are the only ones I use. Never an issue for me.