Linksys/cisco wrt 160nl flashed with 18.06.2 install version - device rebooting permanently

My first try today with OpenWRT (familiar with tomato and dd-wrt) unfortunately seems to have gone wrong - router is rebooting permanently, cannot access interface. Flashed from original cisco fw interface with firmware upgrade function. Device is alive (rebooting) - how can I get access to either revert to linksys/cisco original fw or retry the flash?

Most likely you can revive the router using TFTP recovery.
See under 'unbricking via tftp.'

1 Like

thx - does it matter if the switch is active or passive? Got an active at hand - have a passive one, too - but would have to search for it in my equipment store

The reason for using a switch is so that the PC gets a steady Ethernet carrier and won't start/stop/reconfigure its port while the router is off or rebooting. I don't know what a "passive switch" is, if you mean a hub that will work.


"Active" has own power supply - "passive" does not - I understand the reason why to use a switch - maybe a passive one is not considered a switch but a hub?

Your semantics on the definitions are not related to your need here. "Active" just means a Layer 2 switch that stays online. Some devices reset the internal switch in the router at some point during power on - that could cause you to miss the opportunity for accessing the TFTP with your PC/laptop while it re-established Ethernet. Use of the switch helps with that issue.

1 Like

If, by chance, the "active" switch is a router or a managed switch, make sure its DHCP server is off.

1 Like

TL-.SF1005D (TP-Link) is an unmanaged switch - all tftp procedures terminate with a "time out" or a "network unreachable".
A case for a serial console or even JTag? I'm not eager to learn none of these - never did one of them

Just opened the router - as there is a serial connection for JTag - so, at least, no solduring necessary. Will get me a serial-to-usb-cable and try to flash with putty and tftp - unless someone here's got an easier way to debrick

Yes, in the picture below, it appears that there is a serial header populated already. If you go go serial, make sure you get a 3.3V TTL adapter, not a regular USB to RS232, as that latter could damage your router.

1 Like

Read elsewhere from someone who had done the same procedure with the same router for the same reason that it wasn't even necessary to connect the vcc pin of the router.


Correct. Even though, you should use a TTL device. A regular USB to RS232 would likely give you gibberish, and might damage your RX.

When unbicking my Archer C7, I made the same mistake and got gibberish. Luckily the router wasn't damaged, but I read that it could have.

1 Like

Thx for sharing your experience - unfortunately in my location (Santiago/Chile) I cannot find another cable, and will have to cross fingers.
How did you revive your C7 finally?

Using a TTL adapter, TFTP and PuTTY, essentially as per the procedure on the device page. Though, I would recommend doing own research, search the forum and also the web to see if people had different experience.

You could get one form ebay for for couple of dollars (that would not be the original, but you could do some research to make sure the chip is supported for your PC operating system. It would take a few weeks to arrive, but I would think that's better than risking damaging your router beyond repair.

But, FYI, I'm sure that you can fin a TTL adapter where you are. It's used for Arduino, so electronics students and hobbyists will certainly have it. If it's over priced, you could even try to borrow one.

Ok, back again - could find a USB-to-TTL Adapter, bought even 2 - which was a good idea as one overheated NOT using the 3,3 V connection (confirming what mhegab anticipated).
Both resulted to be PL 2303 HX (had to find out myself), need PROLIFIC driver but latest prolific drivers (that are "embedded" in Win 10) do not support the HX-version of PL 2303 - support only up to Win 7. After long search found an old driver supporting the 2303 HX - but each time one uninstalls (this is general rule) the useless new driver (uninstall device + driver from device manager) when rebooting WIN re-installs the same one - after other long search found the way how to disable this function (automatic reinstalling and updating drivers that come with the OS) and finally could install permanently the old prolific driver - the TTL is recognized by my system, can connect PC with PuTTy to the serial console of the Linksys WRT160NL, data flows from console to PC, and is shown on PuTTy terminal.

BUT: still didn't find a method to STOP the U-BOOT process to enable the FTPT file transfer to the serial console. There are many ways described but none of them works for me. Router continues to reboot endless, and I can see the output on PuTTy terminal - HOW CAN I really STOP the u-boot before it reboots again?

This is my personal million dollar question at this point - hope to find the answer here

  • Try the advice here: TP-Link RE450 bootloop
  • Also, make sure that your flow controls are set properly, this could cause an inability to transmit commands to the console
1 Like

ok, thx - meanwhile I could stop the u-boot with ctr+C command - I try to follow this guide [] - the endless reboot has stopped, and prompt stands as described there (ar7100>)
But after entering the command "ugrade code.bin" I do not get the same echo as described there. This is my echo:

upgrade- upgrade bootcode, code.bin, rom.bin and mfg.bin via using TFTP protocol
upgrade <boot.bin|code.bin|rom.bin|mfg.bin>

Running tftp2 or ftp says "cannot get response from the server"

Sorry for all my newbie questions - never had to debrick a router and have no experience using FTP for file transfer o ver a serial connection.
My next newbie question: how can I now flash the firmware (renamed as "code.bin") on the router that does not yet have an IP adress?

You have to set up a TFTP server on your PC, and place the file there. Then the router can read the file from your server when you run the upgrade script.

Run help and printenv on u-boot and post the results here.

Be very careful entering commands to u-boot because you can erase vital parts of the flash and it won't boot at all again.


ar7100> printenv

bootargs=console=ttyS0,115200 root=31:04 rootfstype=squashfs init=/sbin/init mtdparts=ar7100-nor0:256k(u-boot),7808k(linux),64k(nvram),64k(ART),64k(filesystem) bootver=1.1.6
mfgboot=tftp 0x81800000 mfg.bin
bootcmd=bootwrt 0xbf040020
Environment size: 394/65532 bytes

?       - alias for 'help'
autoscr - run script from memory
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootelf - Boot from an ELF image in memory
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
bootvx  - Boot vxWorks from an ELF image
bootwrt   - boot WRT160NL application image from memory
chpart  - change active partition
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - invoke DHCP client to obtain IP/boot params
echo    - echo args to console
erase   - erase FLASH memory
exit    - exit script
flinfo  - print FLASH memory information
fsinfo  - print information about filesystems
fsload  - load binary file from a filesystem image
go      - boot default, i.e., run 'bootcmd'
help    - print online help
iminfo  - print header information for application image
imls    - list all images found in flash
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
md      - memory display
mii     - MII utility commands
mm      - memory modify (auto-incrementing)
mtdparts- define flash/nand partitions
mtest   - simple RAM test
mw      - memory write (fill)
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reboot   - reboot the device
run     - run commands in an environment variable
setenv  - set environment variables
sleep   - delay execution for some time
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
upgrade- upgrade bootcode, code.bin, rom.bin and mfg.bin via using TFTP protocol
upgrade <boot.bin|code.bin|rom.bin|mfg.bin>
version - print monitor version
?       - alias for 'help'ryleo obtain IP/boot paramsrycol
Unknown command '-' - try 'help' without arguments for list of all known commands

Questions: fsload? setenv? tftpboot? loadb? loady?