# Debricking a Linksys WRT3200ACM through its serial port



## justinnoor (Jan 18, 2019)

Hello community,

I’m trying to debrick a Linksys WRT3200ACM router from a laptop running Freebsd 12.0 release. Essentially this means re-flashing the firmware through a terminal session from the Freebsd host, and sending a firmware image via TFTP. All attempts to establish a terminal session with the router have failed.

The router’s serial port is a JST PH 6 pin connector. The cable is an Adafruit 954 USB to TTL. It includes separate ground, Tx, Rx, and 5v (not needed), connectors.

Although Freebsd is not listed under the cable’s supported OSs, dmesg recognizes the device driver:

`$ grep uslcom /var/run/dmesg.boot`

```
uslcom0 on uhub1
uslcom0 <CP2102 USB to UART Bridge Controller> on usbus0
```

Considering the possibility that it may work, configuration entries were added per the handbook instructions in Ch.25 USB Device Mode / USB OTG.

*Added entries:*

/boot/loader.conf

```
hw.usb.template=3
usb_template_load=“YES”
umodem_load=“YES”
uslcom_load=“YES”
```

/etc/ttys

```
ttyU0    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
ttyU1    "/usr/libexec/getty 3wire"    vt100    onifconsole secure
```

/etc/dev.conf

```
notify 100 {
    match "system"        "DEVFS";
    match "subsystem"    "CDEV";
    match "type"        "CREATE";
    match "cdev"        "ttyU[0-9]+";
    action "/sbin/init q";
};
```


`# reboot`

*Terminal session attempt:*

`# cu -s 115200 -l /dev/ttyU0`

*Output:*

```
connected
```

However, there’s no command line prompt, and the laptop freezes to the extent that a hard shutdown is the only way out. Unfortunately, at the moment, this is the only computer available.

The serial cables are indeed attached correctly to the serial port pins.

Any ideas?


----------



## SirDice (Jan 18, 2019)

Those ttys(5) settings are terminal settings for the host. They do nothing for the serial device. They allow _incoming_ serial connections to the FreeBSD host.


----------



## malavon (Jan 18, 2019)

Try lower baud rates, many devices use a baud rate of 9600 bps, sometimes even as low as 2400 bps. Connecting with a higher baud rate won't work. 
Also, make sure you're using the correct voltage. If you're using a cable that delivers 5V to a 3.3V device, you're probably going to destroy the serial port interface.
Reversely, lower voltage won't damage the device but you won't be able to connect to it.


----------



## Phishfry (Jan 19, 2019)

In a similar vein as above some devices UART require power from the host. 1.8v, 3.3v or 5V are common.

I would suggest you checkout the OpenWRT project for hardware details.
https://openwrt.org/toh/hwdata/linksys/linksys_wrt3200acm
Unfortunately it looks like serial details are missing.


----------



## Phishfry (Jan 19, 2019)

The whole Linksys AC series is similar. There are some nuggets in here:
https://oldwiki.archive.openwrt.org/toh/linksys/wrt_ac_series#serial_header

Maybe the reason you are not getting a response is because it has not booted or uboot is broken.
The serial port/UART requires no power from my reading.
Have you tried network/remote booting it ?
https://kernelnomicon.org/?p=306


----------



## Phishfry (Jan 19, 2019)

So just for reference. You are trying to debrick the stock Linksys firmware or were you already running modified firmware OS?

Here is an in-depth dive at recent uboot env settings with the DD-WRT crowd.
Our uboot is close to parity with upstream uboot so these might be relevant if you are trying to run FreeBSD on it.
https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1096831&sid=780db580930cf5324de59fd67ad0a418


> the trick is to place rango.img at right possition (ie 132mb offset) :


----------



## justinnoor (Jan 19, 2019)

SirDice said:


> Those ttys(5) settings are terminal settings for the host. They do nothing for the serial device. They allow incoming serial connections to the FreeBSD host.



Ah yes, gross misread on my part.

So then with FreeBSD as client, following handbook Ch.26.3, removing all of the previous settings, except the Adafruit cable driver:

/boot/loader.conf

```
uslcom_load="YES"
```

Examining the device nodes:
`# ls /dev/cu*` outputs:

```
/dev/cuaU0
/dev/cuaU0.init
/dev/cuaU0.lock
```

Terminal session attempt:
`# cu -s 115200 -l /dev/cuaU0` outputs:

```
connected
```

Unfortunately, still no terminal session.


----------



## justinnoor (Jan 19, 2019)

malavon said:


> Try lower baud rates



The baud rate for this operation is 115200, based on several guides and tutorials, primarily from the OpenWRT and DD-WRT communities.

https://openwrt.org/toh/linksys/linksys_wrt3200acm#serial1


----------



## justinnoor (Jan 19, 2019)

Phishfry said:


> In a similar vein as above some devices UART require power from the host. 1.8v, 3.3v or 5V are common.



Yes OpenWRT is the firmware I will be flashing. Previoulsy, a thread was initiated on the OpenWRT forum about the appropriate voltage. The consensus was that the power is supplied by the router during the flash process. So when connecting the Adafruit cable, only the ground, Tx, and Rx, connectors are attached to the serial port. The red hot cable is _not _connected.


----------



## justinnoor (Jan 19, 2019)

Phishfry said:


> The whole Linksys AC series is similar. There are some nuggets in here:
> https://oldwiki.archive.openwrt.org/toh/linksys/wrt_ac_series#serial_header
> 
> Maybe the reason you are not getting a response is because it has not booted or uboot is broken.
> ...



Awesome, thanks for the links.

I have not tried remote booting but will definitely check it out.

Honestly I'm not sure if Uboot is broken. One night the router abrubtly stopped working. It was late and it was also "one of those days." Out of anger I hit the reset button without thinking. After that it was totally unresponsive. Later it was discovered that the abrupt stoppage _may _have been related to a bug in the last stable release.

However, one of the most compelling features of the Linksys WRT family is their dual firmware flash layout, which to the best of my knowledge, makes it practically impossible to permanently brick one of these devices unless the board is physically damaged or fried. It appears that once the command line prompt is accessed, running the Uboot `run update_both_images` command will flash both of the flash-partitions via TFTP. A clean slate.


----------



## SirDice (Jan 19, 2019)

justinnoor said:


> Unfortunately, still no terminal session.


Yes, but you said it yourself, the device is _bricked_. So I guess it's hard bricked. If it's _soft_ bricked you might be able to recover it. 



justinnoor said:


> However, one of the most compelling features of the Linksys WRT family is their dual firmware flash layout, which to the best of my knowledge, makes it practically impossible to permanently brick one of these devices unless the board is physically damaged or fried. It appears that once the command line prompt is accessed, running the Uboot  run update_both_images command will flash both of the flash-partitions via TFTP. A clean slate.


Maybe it has some sort of recovery mode? I remember 'unbricking' a certain modem/router type (forgot which one, it was a couple of years ago). The trick with that device was to set up a small network, your laptop directly connected to the modem with an ethernet cable. You had to have a DHCP service running serving a specific range (10.0.0.0/24 I believe it was). And have a TFTP service running on 10.0.0.1 with the firmware image named in a specific way. You then turn on the device keeping the "factory reset" button pressed continuously. That would put it in recovery mode, get an address from DHCP and TFTP the firmware image automatically. On Windows, tftpd32/tftpd64 is an extremely useful little tool for this. Besides the TFTP service it also has a small DHCP service and syslog.


----------



## justinnoor (Jan 21, 2019)

SirDice said:


> Those ttys(5) settings are terminal settings for the host. They do nothing for the serial device. They allow _incoming_ serial connections to the FreeBSD host.



So if the FreeBSD machine is a client trying to establish a terminal session with another non-FreeBSD machine, there’s no configuration required for /etc/ttys? Or do I need to configure the `ttyu`ports? Thanks.


----------



## justinnoor (Jan 21, 2019)

SirDice said:


> Yes, but you said it yourself, the device is _bricked_. So I guess it's hard bricked. If it's _soft_ bricked you might be able to recover it.
> 
> Maybe it has some sort of recovery mode?



Yes sir, but I do believe it is soft bricked, based on what I’ve read thus far. Today I also found out that the JST connectors on my USB-to-TTL cable are 2.54mm, which is too big. The pins on the WRT3200ACM serial port are 2.0mm. I ordered the correct connectors and will modify the cable when they arrive.

I am unaware of any recovery methods as you described above. I’m about 95% sure that there is not. But I am continuing my research and will update accordingly.


----------



## Phishfry (Jan 21, 2019)

justinnoor said:


> there’s no configuration required for /etc/ttys?


Correct. All settings are done at the `cu` command line. Baud and the such.
You can adjust some settings with stty(1)
These might be needed on oddball devices.


----------



## Phishfry (Jan 21, 2019)

What I worry about is what exactly provides the MARVELL> prompt I see in some literature. Is it a bootstrap env? Maybe uboot.
Even if it has dual "firmware" there can only be one loader right? So if that's hosed what do you do.

Did you notice this part of that dd-wrt command. This means uboot is booting from a NAND device
`ubootenv set altnandboot`


----------



## justinnoor (Jan 23, 2019)

Ah yes, if Uboot is wiped out, the device would have to be recovered with kwboot. There is a Linux wifi distro based on Debian that has a good guide on this. The author did extensive work on the WRT series.

https://github.com/Chadster766/McDebian/wiki/C.-U‐Boot-Recovery


----------



## Phishfry (Jan 23, 2019)

balanga  was messing with that kirkwood port earlier.
https://forums.freebsd.org/threads/marvell-u-boot.63344/#post-367493


----------



## balanga (Jan 23, 2019)

justinnoor said:


> Ah yes, if Uboot is wiped out, the device would have to be recovered with kwboot.



I spent quite some time trying to get kwboot working on FreeBSD but never managed it.

I managed to build an early version of it but it would never send the image.

Later versions introduced various Linuxisms so I couldn't even compile it.

Here are a few links to posts I've made

https://forums.freebsd.org/threads/kwboot-for-freebsd.61765/

https://forums.freebsd.org/threads/need-help-building-kwboot.61777/

https://forums.freebsd.org/threads/building-u-boot.67146/

https://forums.freebsd.org/threads/sending-a-file-via-serial-port.66335/

https://forum.doozan.com/read.php?3,61989,62359

If anyone can help me get this working I'd very much appreciate it.


----------



## justinnoor (Jan 24, 2019)

balanga said:


> If anyone can help me get this working I'd very much appreciate it.



I’ve never actually used kwboot. There’s a chance in the near future I’ll need to look into it. UBoot  may be broken on my wifi router.

A week or so ago I exchanged a couple of brief messages with a gentleman who authored a Debian based wifi distro. He hosts his own kwboot images. Seems like he also had issues, and had to reach out to Denx to make it work.

Sorry I could not be of any help. Here are the images:

https://github.com/Chadster766/McDebian/wiki/C.-U‐Boot-Recovery


----------



## balanga (Jan 24, 2019)

justinnoor said:


> I’ve never actually used kwboot. There’s a chance in the near future I’ll need to look into it. UBoot  may be broken on my wifi router.



kwboot is relatively straightforward to use (once you have connected up everything properly).

It will send the UBoot image specified on the command line using xmodem and boot from that. Once it boots you can try replacing the existing UBoot.


----------



## Phishfry (Jan 24, 2019)

Are you sure the 'stock' firmware has the serial port open? Could be disabled.
Linksys shipped some WRT routers with their own firmware and some with OpenWRT.
Was this one of those OpenWRT routers or was it stock Linksys closed firmware?
Have you flashed it with anything?


----------



## justinnoor (Jan 25, 2019)

balanga said:


> kwboot is relatively straightforward to use (once you have connected up everything properly).



Yeah sounds pretty straight forward, which is comforting.


----------



## justinnoor (Jan 25, 2019)

Phishfry said:


> Are you sure the 'stock' firmware has the serial port open? Have you flashed it with anything?



To the best of my knowledge the serial port is indeed open. I’m currently resolving petty connection issues (pins, connectors, wires, etc.). When I’m 100% sure those issues are resolved, and the port is still unresponsive, the next theory would be that UBoot is wiped, or as you mentioned, the port is closed.

The device came with stock firmware. I flashed OpenWrt on it over the internet.


----------



## balanga (Jan 25, 2019)

justinnoor said:


> Yeah sounds pretty straight forward, which is comforting.



Personally, since you can't use kwboot on FreeBSD, at least not yet, I'd suggest asking on the OpenWrt Forum if anyone has experience of unbricking one of these routers using kwboot. I've always found it to be a very helpful forum. I think I'd abandon the idea of using FreeBSD for this purpose. Just my opinion...


----------



## justinnoor (Jan 25, 2019)

balanga said:


> I think I'd abandon the idea of using FreeBSD for this purpose. Just my opinion...



Yes, if in fact it is confirmed that my UBoot is wiped, I’ll probably use a Linux machine for the kwboot image transfer.


----------



## balanga (Jan 25, 2019)

I'd just add that kwboot does not replace any existing UBoot, it simply boots an alternative UBoot. That's my understanding anyway.

I'd suggest trying kwboot anyway to see if your router is bricked. You have nothing to lose.


----------



## tingo (Jan 26, 2019)

FWIW, software flow control (Xon/Xoff) might need to be tweaked. Hardware flow control (RTS/CTS) is default off for cu, bot software flow control is not. Check the stty(1) man page. Note: stty parameters are (re)set when a port is opened or closed, so you will probably need to run [PMAN=]stty[/PMAN] after cu has opened the port.


----------



## balanga (Jan 27, 2019)

tingo said:


> FWIW, software flow control (Xon/Xoff) might need to be tweaked. Hardware flow control (RTS/CTS) is default off for cu, bot software flow control is not. Check the stty(1) man page. Note: stty parameters are (re)set when a port is opened or closed, so you will probably need to run [PMAN=]stty[/PMAN] after cu has opened the port.



This is what I get when running `stty -e -f /dev/cuaU0`:-


> speed 115200 baud; 0 rows; 0 columns;
> lflags: -icanon -isig -iexten -echo echoe -echok echoke -echonl echoctl
> -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo
> -extproc
> ...



Not sure what any of this means, but could it be that flow control is not set correctly for kwboot to work? And can I set it correctly within the program?


----------



## tingo (Jan 27, 2019)

There is a man page for stty(1). If you want to turn off xon / xoff (to test if that helps in your situation), you want something like `stty -f /dev/cuaU0 -ixon -ixoff`.


----------



## balanga (Jan 27, 2019)

tingo said:


> There is a man page for stty(1). If you want to turn off xon / xoff (to test if that helps in your situation), you want something like `stty -f /dev/cuaU0 -ixon -ixoff`.



Do you know if there is a Linux equivalent for showing the default settings of the comport?  It may well be that they are different under Linux, which may explain why the program works under Linux but doesn't under FreeBSD...

Also if running `stty` to turn off xon / xoff is this setting in effect for the duration of the comport being open? ie on reboot I presume it would revert to its original state.


----------



## tingo (Jan 28, 2019)

Linux have man pages too. And yes, the command is called stty there as well.


----------



## balanga (Jan 30, 2019)

tingo said:


> Linux have man pages too. And yes, the command is called stty there as well.



Running `stty -a -F /dev/ttyUSB0` gives me:-


> speed 9600 baud; rows 0; columns 0; line = 0;
> intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
> eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
> werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
> ...



Am I correct in thinking that this means ixon is on and ixoff is off?

Sorry for the newbie type question. Would these settings account for an xmodem transfer working on Linux and not working on FreeBSD?


----------



## tingo (Jan 30, 2019)

balanga said:


> Am I correct in thinking that this means ixon is on and ixoff is off?


Yes.



			
				balanga said:
			
		

> Sorry for the newbie type question. Would these settings account for an xmodem transfer working on Linux and not working on FreeBSD?



Not sure. xmodem is an old protocol and have many extensions. So a failure could also be caused by sender and reciver using incompatible extensions.
However, if the sender and the receiver have different settings for ixon and / or ixoff, you will have problems.


----------

