OpenWrt Wiki. Сброс пароля в роутере с openwrt


OpenWrt Failsafe [OpenWrt Wiki]

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/

OpenWrt SquashFS-Images have a built-in failsafe mode. Booting into failsafe mode bypasses all configuration located on the JFFS2 partition (the writable 'overlay' filesystem), and instead uses a basic set of hard coded defaults located on the SquashFS partition (that is the read-only partition containing the router OS).

Failsafe mode can be used to fix a router which cannot be accessed in the usual ways because of a problem with configuration such as locked out users, locked out network connections, broken startup scripts, broken packages or configurations, full JFFS2 storage (or other JFFS2 content). It normally cannot fix more fundamental problems such as 'hard bricking' or issues with the hardware, kernel or squashFS images that prevent the router booting properly or making connections at the hardware level.

Failsafe mode can be triggered using three special procedures while the router boots - waiting for a flashing LED and pressing a button, waiting (with a packet sniffer) for a special broadcast packet and pressing a button, or watching for a boot message (on the serial port) and pressing a key ("f") on the serial keyboard. Usually watching for a flashing LED is easiest. Whichever trigger you use, the router enters failsafe mode and you can access the command line with telnet (always possible) or a serial keyboard. The procedures are described here, as well as useful tips once you get into failsafe mode.

Once failsafe mode is triggered, the router will boot with a network address of 192.168.1.1/24 on the eth0 network interface, and with only essential services running. Note that the router will not respond to network traffic from outside the 192.168.1.1/24, so you may need to set a suitable IP on the device used and/or ensure that routing allows this. If your device has multiple network interfaces (eth0, eth2, …), usually eth0 is the interface connected to the switch (there may be very seldom exceptions). Using telnet or a serial connection you can mount the JFFS2 partition with the command mount_root and diagnose or fix the problems on the JFFS2 partition.

For more information, OpenWrt Flash Layout explains why OpenWrt failsafe is possible, and Boot Process explains how it works (basically OpenWrt contains an additional boot up stage, called preinit).

→ generic.debrick

Prerequisites

  • Your device must have at least one configurable hardware button to use flashing LED or broadcast packet triggering. Any configurable button will work (except the main power on/off!), even if it is labelled as a "reset" button or a "wifi on/off" or something else. If your router has any button that you can physically press and release, it's likely to be configurable. Check if there's specific info about failsafe mode for your device and make sure everything still works as expected everytime you update!
  • Your device must have an OpenWrt firmware with a SquashFS-Image partition flashed to it. Failsafe cannot be implemented on a system based on JFFS2-Images
  • The hardware ports you will use for commands when you are in failsafe mode must work (either a valid ethernet port or valid serial connection)

  • Of course you must have a networked or serial-connected device (PC, notepad etc) and for serial connection, you must be able to send key-strokes to the router, to use in failsafe mode!

  • The boot process must be able to succeed. Failsafe mode can be used to fix any problem in the JFFS2 partition (because it doesn't need this to enter failsafe mode), but it needs the kernel partition and the SquashFS partition to be able to support the boot process, so that…
    • …the boot process is able to get as far as required to register the pressing of the button

    • …the minimal required binaries and the firmware's default configuration files are available and the boot process can successfully enter failsafe mode (these are all on the SquashFS)

How to trigger failsafe mode

You can trigger failsafe mode in three ways:

  1. Pressing any button at the appropriate time during the router's boot process. You can determine when to press by:

    1. Watching the router LEDs for flashing during boot, and pressing any hardware button when seen (standard and often easiest)

    2. Using a packet sniffer to watch for a special broadcast packet during boot, and pressing any hardware button when seen

  2. Using a serial connection, watching for a message during boot, then pressing the "f" key on your serial keyboard

Add by MrGenie: Although pressing the reset button the moment the first LED starts to blink works on most of my routers, I did encounter a few (all by Linksys) that made me pull out my hair before I had figured it out. The Linksys of mine boot with all lights up, then the LAN/WAN which are connected start blinking. DO NOT PRESS RESET HERE! wait it out. All lights go off. Now after they went off a 2nd time, the moment the first LED starts to blink:"PRESS ENTER RIGHT NOW!" now you're in failsafe mode.

Triggering by pressing any hardware button during boot

Stage 1: Router and Computer preparation

  • Power off the router

  • Unplug the WAN port, and in some cases if needed any other ports (if the WAN IP address and LAN IP address are the same or two LAN ports (an address collision), you would not be able to enter failsafe mode unless you unplug the other port(s) which are colliding)
  • Set your computer's IP to 192.168.1.2, subnet mask 255.255.255.0. The router will be reached at 192.168.1.1 when failsafe mode is running. (You may also use any other IP in the range 192.168.1.2-254.)

  • Connect the computer to the router. You may need to check which port to use, especially if you plan to watch for a broadcast packet to trigger failsafe (see below)

Stage 2: Enter failsafe mode

Immediately when the LED blink pattern or the network broadcast message is seen, click the device button. If your device has multiple buttons, any button should work. OpenWrt is configured in a way, that pressing of any button during preinit will trigger booting into failsafe mode. But in case a button should not work, try another. It can also help to press the button repeatedly until the blink speeds up or the "success" broadcast packet or other evidence of triggering failsafe mode successfully, is seen.

See ADD by MrGenie for several Linksys routers where this doesn't work

Stage 2 option 1: Entering failsafe mode using a blinking LED on the router

On many routers, OpenWrt will start to blink a "SYS" LED (may be "Power", may be other) on the front of the router when it is in its early boot cycle. Since r44056 there are three different LED blinking speeds for most of the routers (in trunk and CC15.05):

Steps:

Some routers only have one hardware button, the reset button, which is often on the back of the unit (often labeled "Reset" or "WPS/Reset"). It may have a visible (external) button, or may be behind a hole (with button in the depth). If it is in a hole, you require a paper clip or similar tool to operate it. Please no not use a nail to press the button in the hole!

Stage 2 option 2: Entering failsafe using the broadcast packet

The exact steps will depend on the device you are using to watch for the broadcast packet. Details are given below for Linux and Windows. Most *nix/BSD/OS X/Android/Mac should be very similar to Linux (often identical). For many other devices and systems the same steps should be possible (but details not provided).

You will need to be sure the router is connected to the device/PC, the cable is working, the device's firewall will not block the packet, and that network LEDs or other diagnostics you may have, show the connection is working. You may also need to temporarily disable the firewall on your device or open a port on it - take care and secure it again after!

Steps:

  • You will need some packet sniffing/packet capture software:

    • Linux (also most *nix/BSD/OS X/Android/Mac): Software is often built in or very easy to download. GUI wireshark or console tcpdump or cshark or other. If you do not have any, then these are all very common open source ports and available + free on most platforms. Y you should be able to download one of these for your device easily in the usual way (or any other packet sniffer you like).
    • Windows: You can use the recvudp.exe utility software, or any other packet sniffer. There are also Windows versions of some of the above software as well.
  • Start watching for packets. The exact commands or menu options are different for each sniffer, so you need to find how to do this on your software. The packet will be sent to destination address 192.168.1.255 port UDP 4919. So for example, in a terminal and using tcpdump, with the router connected to port eth0, you would enter the command tcpdump -Ani eth0 port 4919 and udp

  • Turn the router power off, wait a few seconds, and then back on.

  • Look in the sniffer for the early boot network broadcast packet to be shown (Could take up to 30-40 seconds on some routers). The packet will also show the message that it is waiting for your click on a button. The screenshots below show what this can look like.

  • When you see the packet/message, press any configurable hardware key on the router. If needed press several times. Often you will know you have succeeded because the router will send a second broadcast "success" packet when failsafe mode is triggered, and you will see this in the packet sniffer as well (also shown in the screenshots below). But not all versions do this.

Unverified Information!Up to today (Jan 11, 2013) this page didn't precise on which port to listen. In the case of TL-WR1043ND, it's the WAN port. If you find a contradictory example, it will be necessarry to remove or adapt this note.
Screenshots of typical packet sniffer using broadcast packet method

'Broadcast packet and success packet under Linux (broadcast packet is the first part only!):'

Run wireshark, cshark or tcpdump

'Broadcast packet and success packet under Windows (broadcast packet is the first line only!):'

Monitoring the special packet in a program recvudp.exe.

Stage 3: Log into the router when has booted into failsafe mode

Important notes and troubleshooting for failsafe mode login:

  1. In failsafe mode, the router will not respond to network traffic from outside the 192.168.1.0/24 subnet, so you cannot telnet or ping it unless the source is also in this range of IP addresses. You may need to temporarily set a suitable IP on the device used and/or ensure that any routing and firewalls will allow packets if accessed across a network.

  2. If your device has multiple network interfaces (eth0, eth2, …), usually eth0 is the interface connected to the switch (there may be very seldom exceptions).
  3. If the router does not boot in safe mode despite clicking the button, it may be a timing problem, missing the brief window when OpenWrt is looking for a button press. If so, immediately after turning the router on, rapidly click and keep clicking the button on the router for about 60 seconds to try to not miss the safe mode boot window.

  4. If your router has a ridiculously long boot time (such as DIR-300 A), then you may do this for a longer time.

How to tell when failsafe mode is active:

  • Once in failsafe mode, a network broadcast confirmation message appears (not always, for the TL-WR1043ND no message comes).

  • On some router models (e.g. TP-LINK models), the SYS led blinks very quickly

If you are using a trunk snapshot, revision 46809 or newer, ssh to 192.168.1.1 from the computer and log in as root (no password required). The host key will be randomly generated. You can pass -o "UserKnownHostsFile /dev/null" -o "StrictHostKeyChecking no" to ssh if you want to allow a different host key temporarily.

If you are using a release image, telnet (not SSH) to 192.168.1.1 from the computer. There is no username or password required.

Now go to section When you are in failsafe mode

Serial connection triggering by keyboard key combination in a serial console

  1. Unplug the router's power cord.

  2. Connect the router's WAN port directly to your PC.

  3. Configure your PC with a static IP address between 192.168.1.2 and 192.168.1.254. E. g. 192.168.1.2 (gateway and DNS is not required).
  4. Plugin the power.

  5. Connect via serial

  6. Wait until the following messages is passing: Press the [f] key and hit [enter] to enter failsafe mode

  7. Press "f" and the "enter" key

  8. You should be able to telnet (not SSH) to the router at 192.168.1.1 now (no username and password)

When you are in failsafe mode

Login message

You get a message similar or same like this (using OpenWrt 12.09):

=== IMPORTANT ============================ Use 'passwd' to set your login password this will disable telnet and enable SSH ------------------------------------------ BusyBox v1.19.4 (2013-03-14 11:28:31 UTC) built-in shell (ash) Enter 'help' for a list of built-in commands. _______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- ATTITUDE ADJUSTMENT (12.09, r36088) ----------------------------------------------------- * 1/4 oz Vodka Pour all ingredients into mixing * 1/4 oz Gin tin with ice, strain into glass. * 1/4 oz Amaretto * 1/4 oz Triple sec * 1/4 oz Peach schnapps * 1/4 oz Sour mix * 1 splash Cranberry juice ----------------------------------------------------- [email protected](none):/#

Additional note (r42985):

================= FAILSAFE MODE active ================ special commands: firstboot reset settings to factory defaults mount_root mount root-partition with config files after mount_root: passwd change root's password /etc/config directory with config files for more help see: ​http://wiki.openwrt.org/doc/howto/generic.failsafe =======================================================

The file systems in failsafe mode

OpenWrt uses an overlay file system (JFFS2) which overlays the default router files on the SquashFS partition. JFFS2 contains all config, all packages, and any temp or other files which are not part of the default OpenWrt. Deleting a file from the JFFS2 effectively "resets" the JFFS2 file version back to default, because the original file will be seen on the SquashFS (if it existed). Deleting the entire contents of the JFFS2 will effective resets the router to OpenWrt default settings and packages.

The root file system in failsafe mode is the only the SquashFS partition and the JFFS2 is not present. To mount (access) the JFFS2 as read/write in failsafe mode you must manually mount it. Enter the command mount_root to do this.

Once the JFFS2 file system is mounted read/write, you can view/edit/delete/fix the files which are changed from the default firmware. Any files that are changed will be accessible at /overlay/* (or /overlay/upper/* on some routers).

The core config files are usually at /overlay/etc/config/* (or /overlay/upper/etc/config/*) and have names such as "network", "firewall" etc. Other copies may exist in the /rom subdirectory and the router's UI code may exist in subdirectories such as /lua

Useful commands and procedures

General:

  • The UCI command reads and writes the router's main configuration files, and is also the main command line tool for modifying the configuration. So it has a lot of helpful commands for troubleshooting and fixing config-related problems. (You can also edit the config files directly using any text editor). See The UCI System.
  • If you are not very familiar with Linux, many commands have a --help option (for example: grep --help) which can suggest the options you need. Often you only need basic commands to get started, such as mv (move/rename), cp (copy), rm (remove/delete), find -name *XYZ* (find all files from the current dir with XYZ in the name), cd and ls (change and list current directory), cat (view file), less (view file with page up/down, use "q" to finish), grep (show matching lines/text only), and so on. If a command "hangs" or takes too long, ctrl-C will often kill it and return to a command line.

Specific commands and procedures:

  • Forgot password - In case you forgot your password, you need to set a new one. Type: passwd

  • Forgot IP address - In case you forgot the IP address for the router, get it with uci get network.lan.ipaddr

  • Bad switch/bridge/firewall settings/cannot reach webUI/cannot SSH - In case you have settings that stop you reaching the webUI/SSH, you can use uci (see above) or manually edit the relevant config files to fix the problem. If you are not confident of the correct settings, it's safe and easy to rename (mv) the relevant file to some temporary name, which will cause OpenWrt to use its defaults for that file. Then after reboot you can compare the default and your problem settings file, fix the problem, and restore the other settings which were OK. The most likely files for this are the 'network' and 'firewall' config files.

  • Storage (JFFS2) full - If the JFFS2 file system is full, maybe because you installed too big/too many packages, or it contains some big logs/dumps/cache/other files, or any other reason, either find & delete some files or packages which you don't need, or you can clear the entire JFFS2 partition (see below).

  • Finished/reboot - If you are done with failsafe mode use reboot to reboot.

Changing or resetting some config by editing files

Run the command mount_root and then edit or delete such files as you need. To reset all of the JFFS2 (OpenWrt version of "factory reset") see the next section.

The core config files are usually at /overlay/etc/config/* (or /overlay/upper/etc/config/*) and have names such as "network", "firewall" etc which you can search using the find -name command (see below). If you know your error is (say) some network switch or VLAN issue, then you can edit/delete the network config file and reboot. The router will keep all settings except the settings of the file you changed/deleted which will go back to default.

Wiping JFFS2 file system ('Factory reset' to default config)

  1. This procedure is safe (it will restore the default setup and not brick your router).

  2. It will clear the JFFS2 partition, resetting all custom settings and removing all installed packages, logs, dumps, and temp files, the OpenWrt equivalent of a factory reset. If you need any of these, take a backup to some other device in failsafe mode before doing this.

Run mount_root first (see above) to mount the JFFS2 partition. Once the JFFS2 partition is mounted for read/write, use any of these commands to erase the files on it, which resets the router:

NOTE: there is a bug report that sometimes firstboot or mtd-r erase rootfs_data may not work and "hangs". If that happens then the files can be deleted using the "rm…" method. The overlay is "on top" of the SquashFS so deleting overlay files just leaves the original SquashFS files showing.

Flash new firmware in failsafe mode

Steps (overview):

  1. Prepare your local desktop with netcat to listen to tcp/ip connections on port 3333 and feed any incoming connection with the firmware file you want to flash.

  2. On the router with netcat connect to your local desktop ipaddress on port 3333 and pipe the recieved data to a file.

  3. On the router perform a sysupgrade with the receieved file.

Let us assume the following:

  • Your desktop is on ipaddress 192.168.1.123

  • the router is on default 192.168.1.1

  • the name of the firmware file to flash has been renamed (for simplicity reasons) to nxtfw.bin

Windows Desktop

  • Copy the firmware you intend to flash to the directory where you have unzipped/installed netcat

  • Open an command prompt window, navigate to the directory where netcat is installed:

nc -l -p 3333 < flash.bin

Cygwin Desktop

$ cat nxtfw.bin | pv -b | nc -l 3333

Linux Desktop

cat nxtfw.bin | pv -b | nc -l -p 3333

Failsafed device

nc 192.168.1.123 3333 > /tmp/nxtfw.bin [email protected](none):/# sysupgrade /tmp/nxtfw.bin Saving config files... killall: watchdog: no process killed Failed to connect to ubus Switching to ramdisk... Performing system upgrade... Unlocking firmware ... Writing from <stdin> to firmware ... Appending jffs2 data from /tmp/sysupgrade.tgz to firmware... Writing from <stdin> to firmware ... Upgrade completed Rebooting system... [217.460000] reboot: Restarting system

Notes

  • the article process.boot may help you better understand when failsafe "kicks in" once activated

wiki.openwrt.org

Secure your router's access [OpenWrt Wiki]

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/

There are some possibilities to grant access to the router (or to any PC/Server):

  1. ask for nothing: anybody who can establish a connection gets access

  2. ask for username and password on an unsecured connection (e.g. telnet)

  3. ask for username and password on an encrypted connection (e.g. SSH) (e.g. by following firstlogin)

If you ask for username/password, an attacker has to guess the combination. If you use an unencrypted connection, he could eavesdrop on you and obtain them.

If you use an encrypted connection, any eavesdropper would have to decrypt the packets first. This is always possible. How long it takes to decrypt the content, depends on the algorithm and key length you used.

Also, as long as an attacker has network access to the console, he can always run a brute-force attack to find out username and password. He does not have to do that himself: he can let his computer(s) do the guessing. To render this option improbable or even impossible you can:

  1. not offer access from the Internet at all, or restrict it to certain IP addresses or IP address ranges

    1. by letting the SSH server dropbear and the web-Server uhttpd not listen on the external/WAN port
    2. by blocking incoming connections to those ports (TCP 22, 80 and 443 by default) in your firewall

  2. make it more difficult to guess:

    1. don't use the username root

    2. don't use a weak password with 8 or less characters

    3. don't let the SSH server dropbear listen on the default port (22)
  3. use the combination of

    1. username different than root

    2. tell dropbear to listen on a random port (should be >1024): System → Administration → Dropbear Instance → PortSSH Port
    3. public key authentication. Your public keys can be specified in Administation → System → SSH-keys. An older guide to DropBear SSH public key authentication has detailed information on generating SSH keypairs which include the public key(s) you should upload to your configuration.

SSH Keys

System Hardening

If you have an external disk you may want to encrypt it.

Network hardening

  1. Fwknop (FireWall KNock OPerator) implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based around a default-drop packet filter and libpcap. SPA is essentially next generation port knocking. For example: it can open the port for SSH on WAN, but just for a short period of time, until you can establish a new connection through that port.
    • See detailed instructions at: Fwknop
  2. Ostiary, like port knocking, adds an additional layer of security. It can be used to simply initiate a script or task remotely (without needing SSH access). See detailed instructions for configuring Server or Client by going to the corresponding links below.
  3. To protect open ports against brute force attack, the attacker ip address can be banned via iptables configuration:

Create a non-privileged user in OpenWrt

Example that adds a user called nicolaus:

opkg update opkg install shadow-useradd useradd nicolaus Or add the user by hand (Take care that uid/gid (e.g.=1000) are not already in use!) /etc/passwd: USER:x:1000:1000:GROUP:/mnt/usb:/bin/false /etc/group: GROUP:x:1000: /etc/shadow: USER:RANDOMSTUFWillBeUpdatedWithPasswd:16666:0:99999:7::: passwd USER However, you can't ssh to this user yet. To enable ssh access, you should make a password for that user, create his home folder and most importantly indicate the shell of that user: passwd nicolaus mkdir /home mkdir /home/nicolaus chown nicolaus /home/nicolaus vi /etc/passwd nicolaus:x:1000:1000:nicolaus:/home/nicolaus:/bin/ash

Allow temporary privileged access using sudo

First, you should install sudo:

opkg install sudo Additionally, you must allow your desired user by manipulating '/etc/sudoers' by tool visudo. Now you can follow ONE of the methods below to choose how the user should be able to run commands as root:
Method 1: 'sudo'ing by any user with root password (more secure)

In this method any user can temporarily run commands as root only if he knows the root password. This way when the user runs a command with sudo he should enter root's password instead of his password.

For enabling this method you should open the file '/etc/sudoers' by entering the command

visudo Then uncomment the 2 lines below in that file and then save ## Uncomment to allow any user to run sudo if they know the password ## of the user they are running the command as (root by default). Defaults targetpw # Ask for the password of the target user ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw' This method is more secure because you don't need to protect both root and privileged (sudoer) users to keep the whole system safe.

One usecase can be allowing remote ssh with password from WAN: For more security (still less than RSA key) you can only allow users other than root to ssh with their password (optionally on a custom port) from WAN. And for even more security you can request root's password after running sudo. Therefor in this scenario a hacker should find 3 different strings user's username, user's password and root's password to get full access to the system. Even if the user's account get compromised, then the intruder still can't damage your system because he doesn't have root password yet.

Method 2: 'sudo'ing with the user's password

In this method, after logging in by the desired user, when you enter sudo you should enter the user's password again. The end result is similar to how you use sudo in Ubuntu or other popular Linux disros, but this method doesn't utilize group 'sudo' for this purpose.

For enabling this method you should also enter the command

visudo And then add a line allowing your user, under comment "## User privilege specification": ## ## User privilege specification ## root ALL=(ALL) ALL nicolaus ALL=(ALL) ALL
Method 3: 'sudo'ing with the user's password if he is member of group 'sudo' (needs installing some packages)

This method is very similar to Method 2, except that it allows any member of group 'sudo' to use sudo with their own password. This method is exactly the same one used in Ubuntu and other popular Linux distros to allow 'sudo' access for a user.

For activating this method first you should allow group 'sudo' to use command sudo by entering

visudo

And then uncomment the line below:

## Uncomment to allow members of group sudo to execute any command %sudo ALL=(ALL) ALL

Second you should create group 'sudo'. You can do it by manually editing '/etc/group' but it's more standard to install and use tools for this purpose:

opkg install shadow-groupadd groupadd --system sudo

And finally add your current user to the group 'sudo'. You can directly append your user to '/etc/group' but again it's better to use usermod:

opkg install shadow-usermod usermod -a -G sudo nicolaus

This method is more convenient because you can simply allow sudo access for any user you want, just by usermod -a -G sudo <USER> but takes more space (for installing new packages) than method 2 which may be more suitable for systems with very limited space.

ppp

If you are using ppp in the default configuration with username and password in /etc/config/network, then the unprivileged user can read it from pppd's command line (with e.g. ps w). To prevent that, you can add "user <username>" to /etc/ppp/options and "<username> * <password>" to /etc/ppp/{chap|pap}-secrets and then remove the username / password options from uci configuration.

Of course /etc/ppp/{chap|pap}-secrets should not be world readable:

chmod go-rw /etc/ppp/chap-secrets

WebUI

For secure web access, OpenWrt can be accessed via HTTPS (TLS) instead of the unencrypted HTTP protocol. If HTTP is not secure enough for you, you can disable the existing (unencrypted) web access and either

OR Rebind to LAN only and redirect all http requests to https:

  1. uci set uhttpd.main.listen_http=192.168.1.1:80 uci set uhttpd.main.listen_https='192.168.1.1:443' uci set uhttpd.main.redirect_https='1' uci commit
    1. Restart the web server to trigger certificate generation:/etc/init.d/uhttpd restart
    2. Optionally remove the key generator:opkg remove px5g

Can mandatory client certificate checking be set up with uhttpd? → not possible with uhttpd

If you require remote SSH access, follow the hardening instructions on SSH mentioned above.

wiki.openwrt.org

TP-Link TL-WDR4300 [OpenWrt Wiki]

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/

TP-Link TL-WDR4300 has 802.11n Dual Band (concurrent) and Gigabit Ethernet. Advertised as 750 Mbps it is Dual-Stream (2x2) on the 2.4 Ghz Band and Triple-Stream (3x3) on the 5 Ghz Band. Same as the TL-WDR4310 Released earlier this year in China. FCC ID = TE7WDR4300.

Related to TL-WDR3600, which has only two instead of three antennas.

Manufacturer product page is here, while the support download page is here.

Warning!WARNING: Security warning: unpatched http/tftp backdoor in original firmware: http://sekurak.pl/tp-link-httptftp-backdoor/

Supported Versions

The latest firmware available is the release build of Chaos Calmer 15.05, with working ethernet and dual-band wireless (disabled by default), webUI. I can just report it works pretty good for my version of the router (1.7).

The previous firmware available is the release build of Barrier Breaker 14.07, with working ethernet and dual-band wireless (disabled by default), webUI, and support for all hardware revisions through at least 1.7.

NOTE: The Ethernet switch in this device, AR8327N, is working fine with the OpenWRT default configuration. Some of the more advanced functions of the switch are is not yet fully supported by the driver in 12.09.

ALSO NOTE: The Ethernet switch lets WAN traffic through for a few seconds on bootup. This can be a problem.

If your wireless cannot be enabled when using wide channel modes, this may be due to the friendly neighbor "feature" that prohibits operation of such a mode and you may have to use the standard modes before wireless can be enabled.

Quick Start Guide

Barrier Breaker 14.07 provides full support for this router and has Luci (webUI) built-in.

  • Rename it to the format that the original firmware expects. Something like: wdr4300v1_en_3_14_3_up_boot(150518).bin. Otherwise the page will show error messages like "please select a file to upgrade".

  • Connect your PC to a LAN port of the TP-link via ethernet.
  • Login to the TP-link web administration webpage. (Default address is 192.168.0.1)

  • Under 'System Tools' select 'Firmware Upgrade'. Browse to the previously downloaded *.bin file. Click Upgrade.

  • Set your password and configure the router through the web UI. Basic Config

Note: Factory default IP address range is 192.168.0.1 while OpenWrt uses 192.168.1.1 by default. If you have trouble accessing your router after initial flash, check that you have a 192.168.1.x IP address on your PC.

Hardware Highlights

CPU Flash RAM Network WAN USB Serial JTag VLANs
Atheros [email protected] 8MB 128MB 4x1 GigE 1x1 GigE WAN x2 v2.0 Yes Yes 128

Initial Installation

  1. Obtain Firmware: Download a pre-compiled release image using one of the links in this list
    1. You can always build your own image based on Chaos Calmer / trunk. Choose Atheros AR71xx/AT7240/AR913x platform and use the "TP-LINK TL-WDR4300 board support" profile.
  2. Look for openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin, unless your device was purchased in Israel. In that case, look for openwrt-ar71xx-generic-tl-wdr4300-v1-il-squashfs-factory.bin.

  3. Rename the file (original firmware expects a specific format)

    1. The following filename will please the vendor's web UI firmware update tool: wdr4300v1_en_3_14_3_up_boot(150518).bin

    2. Otherwise the page will show error messages like "please select a file to upgrade," or will not respond to clicking the upgrade firmware button.

Once installed, in order to use wifi, you need to activate wifi in the configuration, see wireless configuration.

NOTES

  1. Recent (2016+) TP-Link firmware in the USA may be locked to prevent re-flashing. If you have such locked firmware, you can downgrade to use the original TP-Link firmware and flash OpenWRT from the web interface. You will need tools from dd-wrt to effect the downgrade: go to dd-wrt website and search the router database for wdr4300, then download the TL-WDR4300v1-webrevert.rar file from the router database page. Unrar the file to extract the binary. Next, from https://dd-wrt.com/site/support/other-downloads, select betas for the WDR4300, then select the most recent date (e.g.2016), then find the latest wdr4300v1. Your path is reported as something like: Downloads › betas › 2016 › 08-24-2016-r30471 › tplink_tl-wdr4300v1. Download the file factory-to-ddwrt.bin. This tool will install dd-wrt, and the revert tool will then install the original unlocked TP-Link firmware. To flash dd-wrt (dd-wrt reccomends IE/windows for this), login to the locked TP-Link router (admin/admin), and then use the "System Tool Update Firmware" to flash the factory-to-ddwrt.bin file. After the router has finished rebooting, the router has dd-wrt running at http://192.168.1.1, and you are ready to revert to the unlocked TP-Link firmware. Browse to 192.168.1.1, assign an ID/PW, then navigate to Administration → Firmware Upgrade. Select the extracted tl-wdr4300v1-webrevert.bin from your host's download directory and click the Upgrade button, dd-wrt will be replaced with the original unlocked TP-Link firmware. Now browse to http://192.168.1.1, hit reset on the router for 5+ seconds to revert the ID to admin/admin and reboot. The router is now running the old TP-Link unlocked firmware at the IP address 192.168.0.1, after the router reboots, browse to http://192.168.0.1 and login with admin/admin. To install Openwrt firmware, browse to System Tools → Firmware Upgrade and select the new firmware file of your choice (e.g.: OpenWRT Designated Driver) and click Upgrade to flash the WDR4300 with OpenWRT.
  2. TP-Link's firmware defaults to 192.168.0.1 with username "admin" and password "admin". After installation, OpenWRT defaults to 192.168.1.1 and no assigned password.

  3. Precompiled images do not activate the wireless feature by default (you will have to use Ethernet for the initial configuration).

  4. Trunk images don't have luci, you must install it manually, see luci.essentials
  5. For devices in Israel, try flashing the original image first, in most cases it will work just fine. Devices that require the Israeli firmware will show a warning on the Firmware Update page. If you see this warning, fallback to the "-il-" image. The Israeli firmware differs only in the Hardware ID, in order to enable flashing from the original firmware interface. There is no difference between the images otherwise. See this thread for details.
  6. Images for the TP-Link 3600 are largely compatible with a simple modification to the header of the firmware image. The PCB for both models is identical, or close to identical. The third external antenna on the 4300 is on the PCB of the 3600, but not connected to an external antenna.

WARNING: Do not flash the sysupgrade firmware via the vendor firmware web interface. Only the 'factory' images should be flashed from the vendor firmware.

Flashing via TFTP

Pressing the WPS/Reset button during powerup makes the bootstrap loader enter the TFTP recovery mode. The procedure can be used to transfer a firmware image:

  1. assign 192.168.0.66 to your local network interface (the router uses 192.168.0.86)

  2. publish a firmware image via tftp: cp openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin /srv/tftp/wdr4300v1_tp_recovery.bin

  3. configure your tftp server

  4. wait for the firmware transfer (about 20s), firmware flash (about 90s) and subsequent reboot (about 30s)

Upgrading OpenWrt

If OpenWrt is already installed and you wish to upgrade to a newer version, you have two methods available:

  1. Flash Overwrite

  2. Generic Sysupgrade

(prior to actual flashing given availability of a serial console it's a nice idea to do dry runs, by ad-hoc RAM booting a factory.bin from a TFTP host server, via uboot "tftp" + "bootm", served via WDR3600's default 6F01A8C0.img filename).

Flash Overwrite
  • Login as root via SSH

  • Check memory usage with the free or top commands. The image can be up to 8MB, so only proceed if you have as much free RAM as the image size plus 6-8MB; this should not be a problem on a device with 128 MB RAM.
  • An easy way to free up some RAM is to delete the symlinks to /etc/modules.d/20-cfg80211, /etc/modules.d/21-mac80211, /etc/modules.d/2*-ath* and /etc/modules.d/[4-9]*-* and reboot. Drop caches can be useful too:

echo 3 > /proc/sys/vm/drop_caches cd /tmp wget http://domain.tld/openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin mtd -r write /tmp/openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin firmware
Generic Sysupgrade

Alternately, you can follow the generic.sysupgrade procedure. Don't forget to populate your /etc/sysupgrade.conf first.

mtd-utils

For systems where OpenWrt mtd is not available, mtd-utils commands need to be used (subsequent commands boldly assume that it's mtd5 which equals the "firmware" mtd partition name - cat /proc/mtd to verify!!):

flash_eraseall /dev/mtd5 nandwrite /dev/mtd5 /tmp/openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin (write operation will take about 5 minutes to complete)

Note that output of newer mtd-utils flash_eraseall recommends using "flash_erase <dev> 0 0" instead (did not test it).

Flash Layout

Please read the article Flash.Layout for a better understanding. It contains a couple of explanations. Then let's have a quick view at flash layout of this particular device:

TP-Link WDR4300 Flash Layout stock firmware Layer0 Layer1 Size in KiB Name mountpoint filesystem TP-Link WDR4300 Flash Layout Layer0 Layer1 Layer2 mountpoint filesystem Layer3 Size in KiB Name mountpoint filesystem
m25p80 spi0.0: s25fl064k 8192KiB
mtd0 mtd1 mtd3
128KiB 8000KiB 64KiB
u-boot firmware art
none / none
none SquashFS-LZMA 4.0 none
m25p80 spi0.0: s25fl064k 8192KiB
mtd0 u-boot 128KiB mtd5 firmware 8000KiB mtd4 art 64KiB
mtd1 kernel mtd2 rootfs
/
overlayfs
mtd3 rootfs_data
128KiB 64KiB
u-boot kernel rootfs_data art
none none /rom /overlay none
none none SquashFS JFFS2 none

ART = Atheros Radio Test - it contains mac addresses and calibration data for the wifi (EEPROM). If it is missing or corrupt, ath9k won't come up anymore.

Failsafe mode

Power up your router. When the 'SYS' light (asterisk symbol right of the power light) starts to blink, immediately push the WPS/Reset button on the back-left of the router for a short time (>1 sec). The 'SYS' light should now start to blink very fast.

On a TL-WDR4300 Ver 1.6 and Barrier Breaker Bleeding Edge, r39211, the above instructions were not terribly successful. The only way that I was able to get the router into failsafe mode was to quickly and repeatedly press the WPS/Reset button starting before the front panel "star" LED started flashing. When that LED finally lit, it appeared to go directly into the rapid-flashing "failsafe" indication. If the WPS LED lights (rightmost, "yin-yang arrows"), it may be that you started clicking the button a little early in the boot sequence.

For what you can do in failsafe, go to the OpenWrt Failsafe Mode page.

Back to original firmware

DON'T TRY to flash wdr4300 with wdr4310 firmware and vice-versa!

The stock firmware is obtained from the OEM: http://www.tplink.com/en/support/download/?model=TL-WDR4300 As with the WR1043ND router, there is a also a catch with the WDR4300!!

  • in case the file name of this firmware file does not contain the word "boot" in it, you can simply revert back to original firmware. → generic.uninstall
  • in case the file name of this firmware file does contain the word "boot" in it, you need to cut off parts of the image file before flashing it

An example of an image file with the word "boot" in it is wdr4300v1_en_3_13_17_up_boot(120426).bin or wdr4300v1_en_3_14_3_up_boot(150518).

Cut the first 0x20200 (that is 131,584 = 257*512) Bytes from original firmware: (1*512 Vendor-info + 256*512 U-Boot)

If you want to find an image that does not contain the word "boot" from the OEM, try downloading smaller zip-files first. With status 12th October 2016 no such zip-files can be downloaded from the vendor's website…

Update: I found one of them without boot and uploaded to dropbox. Its for WDR4300 v1.x Link: https://www.dropbox.com/s/mdcodngo0agkqj6/TL-WDR4300_V1_130319.zip

wget or scp the stock firmware file to /tmp/ cd /tmp dd if=orig.bin of=tplink.bin skip=257 bs=512 (Note: For 3_13_17 the File size should now be exactly: 8,126,464 Bytes, for 3_14_3 the File size should be exactly 8,060,928).

Now the resulting file can be flashed via MDT or web interface (web interface-method is tested 12 Oct 2016, works with 3_14_3)

Other caveats (from vendor web UI):

  • If the firmware path is too short, it will fail with the incorrect error 'firmware path too long'. For instance, flashing c:\openwrt.bin will not work.

  • If the firmware path is too long, it will fail with the error 'firmware path too long'.

Now follow → generic.uninstall

de-brick or OEM installation using the TFTP recovery

The stock firware (3.13.33(130617)) features a TFTP recovery client in bootloader. To activate it press and hold WPS/Reset Button during powering on until WPS LED turns on. Connect computer to LAN1. Using TCPdump, you should see ARP requests from router having address 192.168.0.86 looking for address 192.168.0.66.

# tcpdump -ni eth0 arp ARP, Request who-has 192.168.0.66 tell 192.168.0.86, length 46

Set up your computer to address 192.168.0.66, netmask /24 (255.255.255.0).

# ip addr add dev eth0 192.168.0.66/24

Using TCPdump, you should now see request for new firmware image:

# tcpdump -npi eth0 udp IP 192.168.0.86.2195 > 192.168.0.66.69: 44 RRQ "wdr4300v1_tp_recovery.bin" octet timeout 5

Rename factory image to given name and put it into TFTP server root. → generic.flashing.tftp

:!: In case you are flashing back original firmware, make sure original firmware image name does not contain word boot → back.to.original.firmware.

# cp openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin wdr4300v1_tp_recovery.bin # atftpd --no-fork --daemon .

After downloading, the flashing starts immediately. After cca. 1 minute, the router reboots automatically.

de-brick or OEM installation using the TFTP and RS232 (serial) method

If you want to de-brick/upgrade your router using TFTP you follow these steps:

Pre-requisits:

  • serial RS232 connected from your machine to TL-WDR4300 & terminal program (e.g. minicom, screen) set to 115200 8N1, no flow control, 3,3V

  • copy a working & full OpenWrt firmware image into your tftp server folder (e.g: openwrt-ar71xx-generic-tl-wdr4300-v1-squashfs-factory.bin)

(in case you want to flash the original TPLink firmware it migth needed to delete the first 200 Bytes from this firmware bevor flashing, plz check Video Flash Steps!)

  • start a tftpd server on your local machine on LAN address 192.168.1.100/24 and connect your LAN-port to one of the routers LAN ports

Video Flash Procedure: How to debrick TL-WDR4300

Written Flash Procedure:

  1. router should be unplugged & your serial line connected & terminal open & tftp server installed not yet running

  2. copy your desired openwrt image for the tplink-4300 into your tftp server folder and rename it into openwrt.bin (to save some typing within the flash procedure)

  3. first goal is to get the command prompt from the u-boot bootloader on your router

  4. you should only plug in the serial into the router's serial port AFTER it initialises for a split second after powering on BUT BEFORE Autobooting starts otherwise it might hang at the initialisation process

  5. plug in your router and be ready to type tpl & hit ENTER after you see the line Autobooting in 1 seconds:

U-Boot 1.1.4 (Apr 25 2012 - 18:29:12) U-boot DB120 DRAM: 128 MB id read 0x100000ff flash size 8MB, sector count = 128 Flash: 8 MB Using default environment In: serial Out: serial Err: serial Net: ag934x_enet_initialize... No valid address in Flash. Using fixed address wasp reset mask:c03300 WASP ----> S17 PHY * : cfg1 0x7 cfg2 0x7114 eth0: ba:be:fa:ce:08:41 athrs17_reg_init: complete eth0 up eth0 Autobooting in 1 seconds
  1. in case you failed the right timing just reboot again until the prompt appears

db12x>
  1. now lets check what kind of parameters the u-boot loader expects (e.g file name of firmware via TFPT & Load Adress)

  2. type tftpboot & press ENTER …

db12x> tftpboot dup 1 speed 1000 Warning: no boot file name; using '6F01A8C0.img' Using eth0 device TFTP from server 192.168.1.100; our IP address is 192.168.1.111 Filename '6F01A8C0.img'. Load address: 0x81000000 Log: * TFTP error: 'Access violation' (2) Starting again
  1. as you can see, uboot expects a firmware image file name "6F01A8C0.img" at tftp server address 192.168.1.100

  2. just change you local ip into 192.168.1.100 and start your tftp server

  3. start the uboots tftpclient to download the image from your local machine by typing: tftpboot 0x81000000 openwrt.bin + ENTER

db12x> tftpboot 0x81000000 openwrt.bin Using eth0 device TFTP from server 192.168.1.100; our IP address is 192.168.1.111 Filename 'openwrt.bin'. Load address: 0x81000000 Lg: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############################ done Bytes transferred = 8126464 (7c0000 hex)
  1. the last line needs to show a size of 7c0000 hex otherwise your image is unsuitable

  2. now we need to erase parts of the flash memory to be able to copy your fresh loaded firmware into it

  3. just type in the promt erase 0x9f020000 +7c0000 and wait for the promt to come back

db12x> erase 0x9f020000 +7c0000 First 0x2 last 0x7d sector size 0x10000 125 Erased 124 sectors
  1. now just copy the image to the rigth place by typing cp.b 0x81000000 0x9f020000 0x7c0000

db12x> cp.b 0x81000000 0x9f020000 0x7c0000 Copy to Flash... write addr: 9f020000 done
  1. so .. you, in case your image is the correct one, your are just a single reboot away from having a working TL-WRD4300 back on your desk

  2. type reset or just un-plug and re-plug the power of your router and watch the boot process

db12x> reset

Specific Configuration

Interfaces

The default network configuration is:

Interface Name Description Default configuration
br-lan LAN & WiFi 192.168.1.1/24
vlan0 (eth0.0) LAN ports (1 to 4) None
vlan1 (eth0.1) WAN port DHCP
? WiFi Disabled

Switch Ports (for VLANs)

Numbers 2-5 are Ports 1-4 as labeled on the unit, number 1 is the Internet (WAN) on the unit, 0 is the internal connection to the router itself.

Port Switch port
CPU 0
WAN 1
LAN 1 2
LAN 2 3
LAN 3 4
LAN 4 5
(not used) 6

The switch ports may turn out to be not properly bridged in a default bootup config, causing connection failure. In this case you need to setup /etc/config/network or do manual swconfig setup - see wired.stations.cannot.ping.each.other and switch for advice.

Every port a vlan

config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config switch option name 'eth0' option reset '1' option enable_vlan '1' ## Port: internet config switch_vlan option device 'eth0' option vlan '1' option ports '0t 1' list comment 'port internet, eth0.1' ## Port LAN1 config switch_vlan option device 'eth0' option vlan '2' option ports '0t 2' list comment 'port lan1, eth0.2' ## Port LAN2 config switch_vlan option device 'eth0' option vlan '3' option ports '0t 3' list comment 'port lan2, eth0.3' ## Port LAN3 config switch_vlan option device 'eth0' option vlan '4' option ports '0t 4' list comment 'port lan3, eth0.4' ## Port LAN4 config switch_vlan option device 'eth0' option vlan '5' option ports '0t 5' list comment 'port lan4, eth0.5' config interface 'lan' option type 'bridge' option proto 'static' option ifname 'eth0.2 eth0.3 eth0.4 eth0.5' option ipaddr '192.168.1.5' option netmask '255.255.255.0' config interface 'setup' option ifname 'br-lan' option proto static option ipaddr '192.168.1.1' option netmask '255.255.255.0' #notes # - this is an alias interface, that will let us continue # the setup. config interface 'wan' option ifname 'eth0.1' option proto 'dhcp' option type 'bridge' option metric 10

Every port a separate network

I ordered the switch ports to make it in order. port 1 is eth0.1 and wan port is eth0.5, which is just another network

config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd9e:344e:c4fd::/48' config interface 'lan' option ifname 'eth0.1' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' config interface 'lan2' option ifname 'eth0.2' option proto 'static' option ipaddr '192.168.2.1' option netmask '255.255.255.0' config interface 'lan3' option ifname 'eth0.3' option proto 'static' option ipaddr '192.168.3.1' option netmask '255.255.255.0' config interface 'lan4' option ifname 'eth0.4' option proto 'static' option ipaddr '192.168.4.1' option netmask '255.255.255.0' config interface 'lan5' option ifname 'eth0.5' option proto 'static' option ipaddr '192.168.5.1' option netmask '255.255.255.0' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '2 0t' config switch_vlan option device 'switch0' option vlan '2' option ports '3 0t' config switch_vlan option device 'switch0' option vlan '3' option ports '4 0t' config switch_vlan option device 'switch0' option vlan '4' option ports '5 0t' config switch_vlan option device 'switch0' option vlan '5' option ports '1 0t'

Bootloader Mods

U-Boot 1.1.4 modification for routers

Forum member pepe2k made a modification of U-Boot 1.1.4 for Qualcomm Atheros SoCs based devices (the project is still being developed, so new devices and SoCs will be supported in the future). Up to date information, binary images and sources can be found on official GitHub repository.

This modification started from wr703n-uboot-with-web-failsafe project, but supports more devices, all modern web browsers, has a lot of improvements and other modifications (like U-Boot NetConsole, custom commands, overclocking possibilities etc.).

More information:

Original bootloader settings

(for 1.7, at least)

db12x> printenv bootargs=console=ttyS0,115200 root=31:02 rootfstype=squashfs init=/sbin/init mtdparts=ath-nor0:256k(u-boot),64k(u-boot-env),6336k(rootfs),1408k(uImage),64k(mib0),64k(ART) bootcmd=bootm 0x9f020000 bootdelay=1 baudrate=115200 ethaddr=0xXX:0xXX:0xXX:0xXX:0xXX:0xXX ipaddr=192.168.1.111 serverip=192.168.1.100 dir= lu=tftp 0x80060000 ${dir}u-boot.bin&&erase 0x9f000000 +$filesize;cp.b $fileaddr 0x9f000000 $filesize lf=tftp 0x80060000 ${dir}db12x${bc}-jffs2&&erase 0x9f050000 +0x630000;cp.b $fileaddr 0x9f050000 $filesize lk=tftp 0x80060000 ${dir}vmlinux${bc}.lzma.uImage&&erase 0x9f680000 +$filesize;cp.b $fileaddr 0x9f680000 $filesize stdin=serial stdout=serial stderr=serial ethact=eth0 Environment size: 686/65532 bytes db12x>

Changing variables through 'setenv' doesn't seem to make the changes stick, unfortunately.

Hardware

Info

Power

PSU (power supply)

The TL-WDR4300 DE (v1.1) comes bundled with the following PSU:

tl-wr1043nd_dev10_psu.jpg

Specifications:

Brand/Model Leader Electronics Inc / LEI F7
Input 100-240V~ (50/60Hz, 0.6A)
Output 12.0V 1.5A
Measured output 12.15V
The plug (on the router side) has the following specifications:
Outer diameter 5.5mm
Inner diameter 2.1mm
Length of the shaft 9.5mm
Power consumption

The WDR4300/3600 consume about 3 W with both radios enabled and idle. Each connected ethernet cable adds about 0.3 W.

GPIO

→ port.GPIO The AR933x platform provides 30 GPIOs. Some of them are used by the router for status LEDs, buttons and other stuff. The table below shows the results of some investigation:

Voltage level at GPIO in output-mode gpioX/value in input-mode when GPIO is: GPIO Common Name PCB Name gpioX/value=1 gpioX/value=0 Floating Pulled to GND Pulled to Vcc
0 JP1-9
1 JP1-3
2 JP1-5
3 JP1-7
4
5
6
7
8
9
10
11 LED USB1 DS8,R313
12 LED USB2 DS8,R314
13 LED WLAN2G DS6
14 LED System DS4
15 LED QSS DS5
16 WPS Button
17 WiFi Switch
18 External LNA0
19 External LNA1
20
21 USB2 Power
22 USB1 Power

To make the GPIOs available via sysfs, the required ones have to be exported to userspace, as it is explained on a page of the Squidge-Project. Kernel modules occupying that resource need to be removed before (e.g. "leds-gpio" and "gpio-buttons"). In output-mode, voltage levels of the GPIOs were measured against GND, after the value 1 or 0 had been written to /sys/class/gpio/gpioX/value. In input-mode, the value of the file /sys/class/gpio/gpioX/value was read when the GPIO was floating (initial state), pulled to GND or pulled to Vcc.

The 5GHz LED seems not to be controlled via GPIO.

Hardware Modifications

USB Modification

Warning!WARNING: risk of frying your hardware. only do this when you understand basic electric engineering.

The task was to make ext-root without using the default ports.

It turns out that the GL850G chipset used by the TP-Link in WDR3600/4300/4900 models can handle up to four ports.

Analysing the router's PCB it appears that pins 8(D-), 9(D+), 11(D-) and 12(D+) are unused. Aditionaly each factory USB port has separate power section.

GND is at the TP7 pin point. +5 V was taken directly from the MOSFET.

tl-wdr3600_usbmod-small.jpg tl-wdr3600_usbmod1-small.jpg

5 V (USB powered) compatibility

Internally, the device generates +1.2 V, +3.3 V and +5.0 V (just for USB). All voltage regulators will work from 4.5 V - 13.4 V. This makes the device capable of running from USB power (e.g. a power bank).

You have to open the case and remove (bridge) the input diode, which you will find directly in between the power connector and the input capacitors. Care: There are no thermal reliefs so you need a quite powerful soldering station. Unsolder the SMD diode, place a wire across the pads and solder that.

As the 3.3 V regulator is only specified for 13.4 V (with absolute maximum of 16 V), you will lower the allowed input voltage by this modification. Running directly of the car 12 V (up to 14.4 V while charging) is outside the limits when the diode is removed and on the edge when diode is in place.

USB devices connected to the USB port on the WDR4300/3600 may not work when the device is powered with less than 5.5 V.

Photos

Opening The Case (V 1.1)

Remove the 4 screws on the bottom of the case.

The top is clipped to the bottom of the case at 9 attachment points: 3 on each side of the case, 1 on the back, and 2 on the front. Each attachment point consists of two pins which fit into holes in tabs which protrude from the other half of the case. All of the tabs are on the bottom of the case, with the exception of the case back, where the single tab is in the center of the top of the case.

One method known to work, once, is to start at one of the rear corners. The corner by the ethernet ports seems to work best. Gently flex the case and slightly separate the top from the bottom at the corner by lifting on, or inserting a fingernail or other thin object into, the crack above the antenna. While doing this insert the tip of a knife blade (upward, given the geometry as the unit normally sits) into the crack between the two halves along the side of the case toward the rear. This will force the pins in the top of the case outward, flex the tab protruding from the bottom of the case inward, and free the pins from the tab. If necessary the knife tip may be levered slightly toward the case interior after insertion. Due to the force separating the top of the case from the bottom near the antenna, the pins should pop out of the tab located on the case side near the rear, lift slightly upward, and remain free.

Continue to free the other tabs, first working from the rear corner toward the front of the case, then across the front of the case, and finally from the front of the case toward the rear along the opposite side. The two halves of the case will then separate without having to work at freeing the last attachment point at the rear of the case.

With care, this method leaves no marks on the case.

de-brick using in-system-programming

Warning!WARNING: risk of frying your hardware. only do this when you understand basic electric engineering.

When the bootloader was trashed as well, and none of the above recovery methods work, you can de-brick the thing using flashrom, see http://flashrom.org/ISP.

If you don't have one of those fancy SOIC clips, desolder the flash chip (google for SOIC desoldering for your favorite method)

Serial console

Serial console is available on the J1 (1.7) connector, 3.3v signals.

1 = TX out 2 = RX in 3 = GND 4 = VCC 3.3VDO NOT CONNECT VCC. Use only TX/RX/GND.

Baud Rate: 115200 Data Bits: 8 Parity : No Stop Bits: 1

To break bootstrap sequence, type 'tpl' during the 1-second boot delay.

Factory firmware login credentials are not known at this time (it's not root/5up as with other tp-link models).

Below is an image of the PCB with the serial TTY console shown, in addition the JTAG pin location is shown as well. Both has all its pins labled as well.

TP-Link TL-WDR4310 Version 1.0 forum thread

Add-ons of the Router TL-WDR4300

Performance test with trunk/r35995

Tested with |http over nginx|←wan-|wdr4300|←lan-|Client|

Mode Mbit
switched ~880
routed ~400
nat ~300

Performance test with trunk/r35995

Tested with |http over nginx|←wan-|wdr4300|←lan-|Client|

Mode Mbit
switched ~880
routed ~400
nat ~300

Kernel Log from Device Boot

The following kernel log was capture on a WDR4300 running OpenWrt Designated Driver r48648 (trunk):

[ 0.000000] Linux version 4.1.16 ([email protected]) (gcc version 5.2.0 (OpenWrt GCC 5.2.0 r48648) ) #1 Mon Feb 8 05:09:23 UTC 2016 [ 0.000000] MyLoader: sysp=84c31530, boardp=0065cbe4, parts=195ef6a4 [ 0.000000] bootconsole [early0] enabled [ 0.000000] CPU0 revision is: 0001974c (MIPS 74Kc) [ 0.000000] SoC: Atheros AR9344 rev 2 [ 0.000000] Determined physical RAM map: [ 0.000000] memory: 08000000 @ 00000000 (usable) [ 0.000000] Initrd not found or empty - disabling initrd [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff] [ 0.000000] On node 0 totalpages: 32768 [ 0.000000] free_area_init_node: node 0, pgdat 803d3fc0, node_mem_map 81000000 [ 0.000000] Normal zone: 256 pages used for memmap [ 0.000000] Normal zone: 0 pages reserved [ 0.000000] Normal zone: 32768 pages, LIFO batch:7 [ 0.000000] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [ 0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 [ 0.000000] Kernel command line: board=TL-WDR4300 console=ttyS0,115200 rootfstype=squashfs,jffs2 noinitrd [ 0.000000] PID hash table entries: 512 (order: -1, 2048 bytes) [ 0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) [ 0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) [ 0.000000] Writing ErrCtl register=00000000 [ 0.000000] Readback ErrCtl register=00000000 [ 0.000000] Memory: 125396K/131072K available (2910K kernel code, 143K rwdata, 592K rodata, 248K init, 200K bss, 5676K reserved, 0K cma-reserved) [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS:83 [ 0.000000] Clocks: CPU:560.000MHz, DDR:450.000MHz, AHB:225.000MHz, Ref:40.000MHz [ 0.000000] clocksource MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6825930166 ns [ 0.000008] sched_clock: 32 bits at 280MHz, resolution 3ns, wraps every 7669584382ns [ 0.007504] Calibrating delay loop... 278.93 BogoMIPS (lpj=1394688) [ 0.080011] pid_max: default: 32768 minimum: 301 [ 0.084579] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.090914] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [ 0.100281] clocksource jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns [ 0.110819] NET: Registered protocol family 16 [ 0.116318] MIPS: machine is TP-LINK TL-WDR3600/4300/4310 [ 0.124799] registering PCI controller with io_map_base unset [ 0.355004] PCI host bridge to bus 0000:00 [ 0.358908] pci_bus 0000:00: root bus resource [mem 0x10000000-0x13ffffff] [ 0.365577] pci_bus 0000:00: root bus resource [io 0x0000] [ 0.370913] pci_bus 0000:00: root bus resource [??? 0x00000000 flags 0x0] [ 0.377473] pci_bus 0000:00: No busn resource found for root bus, will use [bus 00-ff] [ 0.385152] pci 0000:00:00.0: [168c:0033] type 00 class 0x028000 [ 0.385169] pci 0000:00:00.0: invalid calibration data [ 0.390101] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] [ 0.390161] pci 0000:00:00.0: reg 0x30: [mem 0x00000000-0x0000ffff pref] [ 0.390226] pci 0000:00:00.0: supports D1 [ 0.390242] pci 0000:00:00.0: PME# supported from D0 D1 D3hot [ 0.390478] pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00 [ 0.390513] pci 0000:00:00.0: BAR 0: assigned [mem 0x10000000-0x1001ffff 64bit] [ 0.397524] pci 0000:00:00.0: BAR 6: assigned [mem 0x10020000-0x1002ffff pref] [ 0.404509] pci 0000:00:00.0: using irq 40 for pin 1 [ 0.410029] Switched to clocksource MIPS [ 0.415063] NET: Registered protocol family 2 [ 0.420220] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [ 0.426902] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [ 0.433067] TCP: Hash tables configured (established 1024 bind 1024) [ 0.439232] UDP hash table entries: 256 (order: 0, 4096 bytes) [ 0.444843] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [ 0.451127] NET: Registered protocol family 1 [ 0.455346] PCI: CLS 0 bytes, default 32 [ 0.456358] futex hash table entries: 256 (order: -1, 3072 bytes) [ 0.479129] squashfs: version 4.0 (2009/01/31) Phillip Lougher [ 0.484760] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [ 0.496446] io scheduler noop registered [ 0.500227] io scheduler deadline registered (default) [ 0.505398] Serial: 8250/16550 driver, 16 ports, IRQ sharing enabled [ 0.514288] console [ttyS0] disabled [ 0.537749] serial8250.0: ttyS0 at MMIO 0x18020000 (irq = 11, base_baud = 2500000) is a 16550A [ 0.546032] console [ttyS0] enabled [ 0.553059] bootconsole [early0] disabled [ 0.565691] m25p80 spi0.0: found s25fl064k, expected m25p80 [ 0.571414] m25p80 spi0.0: s25fl064k (8192 Kbytes) [ 0.577240] 5 tp-link partitions found on MTD device spi0.0 [ 0.582940] Creating 5 MTD partitions on "spi0.0": [ 0.587816] 0x000000000000-0x000000020000 : "u-boot" [ 0.593733] 0x000000020000-0x00000015e38c : "kernel" [ 0.599556] 0x00000015e38c-0x0000007f0000 : "rootfs" [ 0.605412] mtd: device 2 (rootfs) set to be root filesystem [ 0.611233] 1 squashfs-split partitions found on MTD device rootfs [ 0.617518] 0x000000340000-0x0000007f0000 : "rootfs_data" [ 0.623817] 0x0000007f0000-0x000000800000 : "art" [ 0.629399] 0x000000020000-0x0000007f0000 : "firmware" [ 0.647823] switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 [ 0.717193] libphy: ag71xx_mdio: probed [ 1.311422] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] [ 1.322903] eth0: Atheros AG71xx at 0xb9000000, irq 4, mode:RGMII [ 1.331285] NET: Registered protocol family 10 [ 1.339246] NET: Registered protocol family 17 [ 1.343895] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this. [ 1.356763] Bridge firewalling registered [ 1.360992] 8021q: 802.1Q VLAN Support v1.8 [ 1.371902] VFS: Mounted root (squashfs filesystem) readonly on device 31:2. [ 1.380232] Freeing unused kernel memory: 248K (803f2000 - 80430000) [ 2.299162] init: Console is alive [ 2.302870] init: - watchdog - [ 3.246099] usbcore: registered new interface driver usbfs [ 3.251807] usbcore: registered new interface driver hub [ 3.257301] usbcore: registered new device driver usb [ 3.267468] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 3.275555] ehci-platform: EHCI generic platform driver [ 3.281013] ehci-platform ehci-platform: EHCI Host Controller [ 3.286873] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1 [ 3.297011] ehci-platform ehci-platform: irq 3, io mem 0x1b000000 [ 3.320062] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00 [ 3.327294] hub 1-0:1.0: USB hub found [ 3.331462] hub 1-0:1.0: 1 port detected [ 3.338335] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [ 3.346007] ohci-platform: OHCI generic platform driver [ 3.650051] usb 1-1: new high-speed USB device number 2 using ehci-platform [ 3.802494] hub 1-1:1.0: USB hub found [ 3.806672] hub 1-1:1.0: 4 ports detected [ 4.306780] init: - preinit - [ 4.935659] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 4.961548] random: procd urandom read with 8 bits of entropy available [ 6.311286] eth0: link up (1000Mbps/Full duplex) [ 6.316055] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 8.105107] jffs2_scan_eraseblock(): End of filesystem marker found at 0x10000 [ 8.112483] jffs2_build_filesystem(): unlocking the mtd device... done. [ 8.119216] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 8.310376] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 1 is up [ 8.317429] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is up [ 24.273288] done. [ 24.275283] jffs2: notice: (412) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found. [ 24.292428] mount_root: overlay filesystem has not been fully initialized yet [ 24.306352] mount_root: switching to jffs2 overlay [ 24.821552] eth0: link down [ 24.835284] procd: - early - [ 24.838319] procd: - watchdog - [ 25.557513] procd: - ubus - [ 26.564948] procd: - init - [ 27.342369] ip6_tables: (C) 2000-2006 Netfilter Core Team [ 27.361800] Loading modules backported from Linux version v4.4-rc5-1913-gc8fdf68 [ 27.369305] Backport generated by backports.git backports-20151218-0-g2f58d9d [ 27.379795] ip_tables: (C) 2000-2006 Netfilter Core Team [ 27.395866] nf_conntrack version 0.5.0 (1963 buckets, 7852 max) [ 27.434799] xt_time: kernel timezone is -0000 [ 27.513609] PPP generic driver version 2.4.2 [ 27.520573] NET: Registered protocol family 24 [ 27.568983] ath: EEPROM regdomain: 0x0 [ 27.569003] ath: EEPROM indicates default country code should be used [ 27.569013] ath: doing EEPROM country->regdmn map search [ 27.569033] ath: country maps to regdmn code: 0x3a [ 27.569045] ath: Country alpha2 being used: US [ 27.569054] ath: Regpair used: 0x3a [ 27.580256] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [ 27.583349] ieee80211 phy0: Atheros AR9340 Rev:2 mem=0xb8100000, irq=47 [ 27.590302] PCI: Enabling device 0000:00:00.0 (0000 -> 0002) [ 27.601550] ath: EEPROM regdomain: 0x0 [ 27.601567] ath: EEPROM indicates default country code should be used [ 27.601577] ath: doing EEPROM country->regdmn map search [ 27.601598] ath: country maps to regdmn code: 0x3a [ 27.601609] ath: Country alpha2 being used: US [ 27.601618] ath: Regpair used: 0x3a [ 27.610247] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht' [ 27.613386] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0xb0000000, irq=40

wiki.openwrt.org

OpenWrt OS upgrade procedure (LuCI or sysupgrade) [OpenWrt Wiki]

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/

An OpenWrt upgrade will replace the entire current OpenWrt installation with a new version. This includes the Linux kernel, the SquashFS partition and the JFFS2 partition.

The common upgrade paths below will automatically preserve much of the OpenWrt OS configuration by saving and then restoring configuration files in specific common locations (including /etc/config). This will preserve things like OpenWrt network settings, WiFi settings, the device hostname, and so on.

The first part of the upgrade process is to prepare for the upgrade. This includes documenting programs and settings that will need to be re-installed or restored after the upgrade, locating and downloading the correct OpenWrt upgrade image for your hardware.

Next is the actual upgrade. There are two common upgrade paths to actually perform the upgrade. One uses the LuCI web interface "Flash new firmware image" command and one uses the command-line sysupgrade command. You can use either approach.

After the OS upgrade, there are usually some additional configuration steps required to re-install additional packages not part of the base OpenWrt install, to configure new OpenWrt functionality or to update configuration files to reflect new settings or updated packages. Please see the section below with more details.

Preparing for an OpenWrt upgrade

How the OpenWrt OS upgrade works

Both the LuCI and sysupgrade upgrade procedures work by saving specified configuration files, wiping the entire file system, installing the new version of OpenWrt and then restoring back the saved configuration files. This means that any parts of the file system that are not specifically saved will be lost.

In particular, any manually installed software packages you may have installed after the initial OpenWrt installation have to be reinstalled after an OpenWrt upgrade. That way everything will match, e.g. the updated Linux kernel and any installed kernel modules.

Any configuration files or data files placed in locations not specifically listed as being preserved below will also be lost in an OpenWrt upgrade. Be sure to check any files you have added or customized from a default OpenWrt install to back up these items before an upgrade.

Identifying customizations

List user-installed packages identified in the opkg package database

This script is from forum member gsenna and was originally posted in the forum discussion "Default packages attitude 12.09rc2 tplink 1043nd" at https://forum.openwrt.org/viewtopic.php?id=43480

vi /tmp/listuserpackages.sh #!/bin/ash echo >&2 User-installed packages are the following: sed -ne '/^Package:[[:blank:]]*/ { s/// h } /user installed/ { g p }' /usr/lib/opkg/status /bin/ash /tmp/listuserpackages.sh User-installed packages are the following: snmpd-static

Note that the script may list several packages that are part of the default OpenWrt install and will have their changed configuration files automatically backed up and restored. In addition, packages installed as dependences of other packages may show here. It is only important to note the names of packages that you directly installed manually. Any dependencies of these packages will automatically be reinstalled when the primary package is reinstalled.

An alternative script, that uses awk instead of sed/grep and is much shorter (provided by user valentijn):

vi /tmp/listuserpackages.awk /^Package:/{PKG= $2} /^Status: .*user installed/{print PKG} awk -f /tmp/listuserpackages.awk /usr/lib/opkg/status

This script will only output a list of user (and default) installed packages.

List all packages associated with any user-modified file

This is an alternative to the script above. This command will list all packages related to any file in the whole file system that has changed from the default OpenWrt default version.

Note that the script may list several packages that are part of the default OpenWrt install and will have their changed configuration files automatically backed up and restored. In addition, packages installed as dependences of other packages may show here. It is only important to note the names of packages that you directly installed manually. Any dependencies of these packages will automatically be reinstalled when the primary package is reinstalled.

# this version is for OpenWrt 14.07 "Barrier Breaker" or earlier find /overlay/ | sed s:/overlay::g | while read file; do opkg search $file; done | awk '{print $1}' | sort | uniq   # this command is for OpenWrt 15.05 find /overlay/upper/ | sed s:/overlay/upper::g | while read file; do opkg search $file; done | awk '{print $1}' | sort | uniq

Ensure desired configuration files will be saved

The LuCI and sysupgrade upgrades will preserve configuration files:

opkg list-changed-conffiles
  • files listed within the text files in /lib/upgrade/keep.d/ (for example, /lib/upgrade/keep.d/base-file-essential)

  • files listed in /etc/sysupgrade.conf

Based on the list of user-installed packages identified above, you may know that you have other configuration or data files that need to be preserved and that are not included in the default set of files to save. Your new files should be added to /etc/sysupgrade.conf. By default, this file just has comments in it.

LuCI method

Go to System > Backup/Flash Firmware > Configuration tab. This will display the current contents of /etc/sysupgrade.conf file and the edit window can be used to add additional lines to the file. Click "Submit" when done editing.

To view all the configuration files that will be saved on an upgrade, click the "Open list…" button.

Command-line method

Edit /etc/sysupgrade.conf with an editor. For example:

vi /etc/sysupgrade.conf ## This file contains files and directories that should ## be preserved during an upgrade. # /etc/example.conf # /etc/openvpn/ ## customization: preserve sudo files /etc/sudoers /etc/sudoers.d/

Legacy: LuCI flash_keep section of /etc/config/luci

Luci has a separate set of settings in the "config extern 'flash_keep'" section of the file /etc/config/luci relating to configuration files that should be preserved.

In the past, it appears this list was used by LuCI (see https://forum.openwrt.org/viewtopic.php?pid=100739#p100739). However, at least as of OpenWrt 14.07, the LuCI OpenWrt upgrade procedure actually calls the sysupgrade script and so it appears the flash_keep settings in /etc/config/luci are now ignored.

Identifying the OpenWrt upgrade image

  • Only the "…-sysupgrade.bin" version of the OpenWrt download image should be used for OpenWrt upgrades. The "…-factory.bin" file is for switching from the vendor-default firmware to OpenWrt and is not used for OpenWrt-to-OpenWrt upgrades.

  • Locate the correct "…-sysupgrade.bin" upgrade file for your particular device hardware in the OpenWrt download area

OpenWrt on x86

:!: For x86 systems there is no "sysupgrade" image, just be sure to use the new firmware image has the same family of filesystem (if the current firmware uses squashfs then the new will use squashfs as well and if the current has ext the new will use ext filesystem. Note that an upgrade from ext2 [10.03.1] to ext4 [12.09] seems not working. Tested 10.03.1 squashfs to 12.09 squashfs, working ; 10.03.1 squashfs to 12.09 ext4 failed; 10.03.1 ext2 to 12.09 ext4 failed)

Downloading the OpenWrt upgrade image

For LuCI-based upgrades
  • Download the desired upgrade file to your PC using a web browser

  • Proceed to the LuCI upgrade procedure, below

For sysupgrade-based upgrades
  • Download the desired upgrade file to the local /tmp RAM drive on your OpenWrt system. The /tmp directory is stored in RAM (using tmpfs), not in the permanent flash storage.
# example downloading the OpenWrt 15.05 upgrade image for a TP-LINK TL-WR1043ND ver. 1.x router cd /tmp wget http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-tl-wr1043nd-v1-squashfs-sysupgrade.bin   # check the integrity of the image file wget http://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/md5sums # the desired result is that the downloaded firmware filename is listed with "OK" afterwards md5sum -c md5sums 2> /dev/null | grep OK
Troubleshooting: /tmp is too small to hold the downloaded file

If your device's /tmp filesystem is not large enough to store the OpenWrt upgrade image, this section provides tips to temporarily free up RAM.

First check memory usage with the free or top or cat /proc/meminfo commands; proceed if you have as much free RAM as the image is in size plus an some additional MiB of free memory.

[email protected]:/$ free total used free shared buffers Mem: 29540 18124 11416 0 1248 -/+ buffers: 16876 12664 Swap: 0 0 0

In this example there are precisely 11416 KiB of RAM unused. All the rest 32768 - 11416 = 21352 KiB are used somehow and a portion of it can and will be made available by the kernel, if it be needed, the problem is, we do not know how much exactly that is. Make sure enough is available. Free space in /tmp also counts towards free memory. Therefore with:

[email protected]:/$ free Mem: 13388 12636 752 0 1292 Swap: 0 0 0 Total: 13388 12636 752
[email protected]:/$ df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 2304 2304 0 100% /rom tmpfs 6696 60 6636 1% /tmp tmpfs 512 0 512 0% /dev /dev/mtdblock3 576 288 288 50% /overlay mini_fo:/overlay 2304 2304 0 100% /

One has actually 752+6636 KiB of free memory available.

  • quickest and safest way to free up, some RAM is to delete the opkg packages file:
rm -r /tmp/opkg-lists/ sync && echo 3 > /proc/sys/vm/drop_caches rm /etc/modules.d/*80211* rm /etc/modules.d/*ath9k* rm /etc/modules.d/b43* reboot

The wireless drivers, usually take up quite some amount of RAM and are not required (unless you are connected via wireless of course ;-)), so an easy way to free up some RAM is to delete the symlinks in etc/modules.d so these are not loaded into memory at the next reboot.

LuCI web interface upgrade procedure

  • Select System ⇒ Backup / Flash Firmware ⇒ Configuration to edit /etc/sysupgrade.conf (Attitude Adjustment)

  • Select System ⇒ Backup / Flash Firmware ⇒ Actions (Attitude Adjustment)

  • Upload the OpenWrt upgrade image file you downloaded

  • LuCI will calculate the MD5 checksum of the file, if it's correct, you are green to go

  • Wait until the router comes back online

  • After the automatic reboot, the system should come up the same configuration settings as before: the same network IP addresses, same SSH password, etc.

  • Proceed to the "Additional configuration after an OpenWrt upgrade" section, below

sysupgrade SSH/terminal upgrade procedure

sysupgrade -v /tmp/filename-of-downloaded-sysupgrade.bin
  • The verbose-option should give some output similar to this. The list of configuration files saved will change depending on what packages you have installed and which files you have configured to be saved, as per above.

Saving config files... etc/config/dhcp etc/config/dropbear etc/config/firewall etc/config/luci etc/config/network etc/config/snmpd etc/config/system etc/config/ubootenv etc/config/ucitrack etc/config/uhttpd etc/config/wireless etc/dropbear/authorized_keys etc/dropbear/dropbear_dss_host_key etc/dropbear/dropbear_rsa_host_key etc/firewall.user etc/group etc/hosts etc/inittab etc/passwd etc/profile etc/rc.local etc/shadow etc/shells etc/sudoers etc/sudoers.d/custom etc/sysctl.conf etc/sysupgrade.conf killall: watchdog: no process killed Sending TERM to remaining processes ... ubusd askfirst logd logread netifd odhcpd snmpd uhttpd ntpd dnsmasq Sending KILL to remaining processes ... askfirst Switching to ramdisk... Performing system upgrade... Unlocking firmware ... Writing from <stdin> to firmware ... [w] Appending jffs2 data from /tmp/sysupgrade.tgz to firmware...TRX header not found Error fixing up TRX header Upgrade completed Rebooting system...

Note: The "TRX header not found" and "Error fixing up TRX header" errors are not a problem as per OpenWrt developer jow's post at https://dev.openwrt.org/ticket/8623

  • Wait until the router comes back online

  • After the automatic reboot, the system should come up the same configuration settings as before: the same network IP addresses, same SSH password, etc.

  • Proceed to the "Additional configuration after an OpenWrt upgrade" section, below

Troubleshooting

  • In case it does not, try a cold reset (= interrupt the electrical current to the device, wait a couple of seconds and then connect it again).
For unknown reasons such a cold reset has often been reported to be necessary after a sysupgrade. This is very very bad in case you performed this remotely!

Additional configuration after an OpenWrt upgrade

Verify the new OS version

  • In LuCI, go to Status > Overview to verify you are running the new OpenWrt release

  • In SSH, the login banner has the release information

Check for any upgradable packages

After the initial update, it is good to check for any updated packages released after the base OS firmware image was built.

opkg update opkg list-upgradable opkg upgrade luci-lib-ip luci-theme-bootstrap luci-app-firewall luci-proto-ppp luci-mod-admin-full luci-base luci-proto-ipv6 luci-lib-nixio luci opkg list-upgradable

Reinstall user-installed packages

After a successful upgrade, you will need to reinstall all previously installed packages. You made a list of these above. Package configuration files should have been preserved due to steps above, but not the actual packages themselves.

opkg update opkg install snmpd-static

Configure user-installed packages

The new package installations will have installed new, default versions of package configuration files. As your existing configuration files were already in place, opkg would have displayed a warning about this and saved the new configuration file versions under …-opkg filenames.

The new package-provided configuration files should be compared with your older customized files to merge in any new options or changes of syntax in these files.

The diffutils program is helpful for this.

For example:

# install diffutils opkg install diffutils   # locate all -opkg files find /etc -name *-opkg   # compare old customized /etc/config/snmpd with new generic file /etc/config/snmpd-opkg diff /etc/config/snmpd /etc/config/snmpd-opkg   # merge in any needed changes to the active version of the configuration file vi /etc/config/snmpd # and clean up by removing the package manager-version of the configuration file rm /etc/config/snmpd-opkg   # or if the new version provided by the package maintainer should just replace the old config file then just swap it in mv /etc/config/snmpd-opkg /etc/config/snmpd

Enable and start user-installed packages

/etc/init.d/snmpd enable /etc/init.d/snmpd start

Do a test reboot

The upgrade is fully complete now. It is a good idea to do a test reboot and ensure all expected functionality is working as before.

reboot

Alternative OS upgrade procedures to LuCI or sysupgrade

The OS upgrade options are much more manual than using either LuCI or sysupgrade. They are only needed in unusual circumstances.

mtd

  1. If sysupgrade is not supported for your embedded device, you should use mtd instead:mtd -r write /tmp/openwrt-ar71xx-generic-wzr-hp-ag300h-squashfs-sysupgrade.bin firmware

netcat

Direct method

Netcat could be employed if you cannot free enough RAM. See netcat. Netcat needs to be installed first.

This method is NOT recommended!
  1. On your Linux PC run:nc -q0 192.168.1.1 1234 < openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin
  2. On the router run:nc -l -p 1234 | mtd write - firmware
Indirect method
This method is much SAFER if you have enough RAM.

This method is fine for self built firmwares.

You should check how much RAM you have currently available.(In case you do not have enough left, consult Free up RAM.)

free
Transferring image file to a temporary location
  1. On your Linux PC run:cat [specified firmware].bin | pv -b | nc -l -p 3333
  2. On the router run:nc 192.168.1.111 3333 > /tmp/[specified firmware].bin

The port 3333 an IP address 192.168.1.111 are just examples. The command 'pv -b' is optional for tracking progress but maybe you have to install pv to your system previously.

Write it to flash
  • sysupgrade:sysupgrade -v /tmp/[specified firmware].bin
  • mtd:mtd -r write /tmp/[specified firmware].bin firmware

I have tested under Ubuntu 11.10.

Some useful links for netcat

scp

Make sure your router has enough memory.

[email protected]:/# free

Make sure you have set the password for your router (you must set a password for your router to enable the SSH). See First Login for more details.

Copy your firmware to your router

On your Linux PC run:

linux$ scp openwrt-ar71xx-tl-wr1043nd-v1-squashfs-sysupgrade.bin [email protected]:/tmp Input 'yes' to estabilish authenticity, then input the password of your router. Wait scp command finished. Now you can see your firmware in /tmp directory.
Write the firmware to your router
[email protected]:/# sysupgrade -v /tmp/[specified firmware].bin
Note

192.168.1.1 is the ip address(may be called GateWay) of your router. Check by run:

linux$ ip r or you can check the the /etc/config/network file, 127.0.0.1 is the loopback ipaddress, the other one is the ip address of your router. [email protected]:/# grep ipaddr /etc/config/network

wiki.openwrt.org

Защита доступа маршрутизатора [OpenWrt Wiki]

This wiki is read only and for archival purposes only. >>>>>>>>>> Please use the new OpenWrt wiki at https://openwrt.org/

Есть некоторые возможности предоставить доступ к маршрутизатору (или любому ПК/Серверу):

  1. ничего не прошу: кто может установить подключение получает доступ к

  2. запрос имени пользователя и пароля для незащищенного соединения (например, telnet)

  3. задать имя пользователя и пароль по зашифрованному соединению (например, SSH) (например, следуя firstlogin)

При запросе имени пользователя/пароля злоумышленник должен угадать комбинацию. Если вы используете незашифрованное соединение, он может подслушать вас и получить их.

При использовании зашифрованного соединения любой подслушиватель сначала должен расшифровать пакеты. Это всегда возможно. Сколько времени требуется для расшифровки содержимого, зависит от используемого алгоритма и длины ключа.

Кроме того, пока злоумышленник имеет сетевой доступ к консоли, он всегда может запустить грубую атаку, чтобы узнать имя пользователя и пароль. Он не должен делать это сам: он может позволить его компьютер(ы) делать гадания. Чтобы сделать эту опцию невероятной или даже невозможной, вы можете:

  1. не предоставлять доступ из Интернета вообще, или ограничить его определенными IP-адресами или диапазонами IP-адресов

  2. by letting the SSH server dropbear and the web-Server uhttpd not listen on the external/WAN port
  3. блокируя входящие соединения на эти порты (TCP-порт 22, 80 и 443 по умолчанию) в брандмауэре

  4. сделать его труднее догадаться:

  5. не используйте имя пользователя "root"

  6. не использовать слабый пароль с 8 или менее символов

  7. не позволяйте SSH-серверу dropbear прослушивать порт по умолчанию (22)
  8. но с помощью комбинации

  9. имя пользователя отличается от "корня"

  10. сказать "пакет dropbear" слушать на случайный порт (должен быть >1024): система → Администрирование → например → пакет dropbear порт

SSH Port

  1. проверка подлинности открытого ключа. Ваш публичный ключ может быть указан в система → Управление → SSH-ключей. Старый путеводитель пакет dropbear SSH аутентификации по публичному ключу содержит подробную информацию о генерации пар ключей SSH, которые включают в себя открытый ключ(s). вы должны загрузить в конфигурацию.

SSH Keys

Закалка системы

Закаливание сети

  1. https://www.cipherdyne.org/fwknop//Fwknop (НОК Оператор брандмауэра) реализует схему авторизации под названием wр>один пакет авторизации (СПА). Этот способ авторизации по умолчанию-сбросить фильтр пакетов и libpcap. Спа-центр-это порт следующего поколения, стучащий. Например: он может открыть порт SSH на глобальной сети, но только в течение короткого периода времени, пока вы не можете установить новое подключение через этот порт.
  • Ознакомиться с подробными инструкциями по: Fwknop
  1. Ostiary, как и стук порта, добавляет дополнительный слой безопасности. Он может быть использован, чтобы просто запустить скрипт или удаленно (без доступа по SSH). Ознакомиться с подробными инструкциями по настройке сервера или клиента, перейдя на соответствующую ссылку ниже.
  1. Чтобы защитить открытые порты от атаки грубой силы, IP-адрес злоумышленника может быть запрещен через iptables конфигурации:

Создание пользователя без привилегий в OpenWrt

Пример, который добавляет пользователя с именем Николай:

opkg update opkg install shadow-useradd useradd nicolaus Или добавить пользователя вручную (заботиться, что uid/gid (e.g.=1000) еще не используются!) /etc/passwd: USER:x:1000:1000:GROUP:/mnt/usb:/bin/false /etc/group: GROUP:x:1000: /etc/shadow: USER:RANDOMSTUFWillBeUpdatedWithPasswd:16666:0:99999:7::: passwd USER Однако этот пользователь пока не может использовать ssh. Чтобы включить доступ к ssh, необходимо ввести пароль для этого пользователя, создать его домашнюю папку и, что самое главное, * * указать оболочку* * этого пользователя: passwd nicolaus mkdir /home mkdir /home/nicolaus chown nicolaus /home/nicolaus vi /etc/passwd nicolaus:x:1000:1000:nicolaus:/home/nicolaus:/bin/ash

Разрешить временный привилегированный доступ с помощью sudo

Во-первых, необходимо установить sudo:

opkg install sudo Кроме того, необходимо разрешить желаемому пользователю манипулировать "'в/etc/пользователям использовать sudo?"' с помощью инструмента "visudo". Теперь вы можете следовать * * один* * из методов ниже, чтобы выбрать, как пользователь должен быть в состоянии выполнять команды как "корень":
Способ 1: 'sudo' вычислить любого пользователя с паролем (более безопасный)

В этом методе любой пользователь может временно выполнять команды от имени root только в том случае, если ему известен пароль root. Таким образом, когда пользователь выполняет команду "sudo", он должен ввести пароль root вместо своего пароля.

Для включения этого метода вы должны открыть файл '/etc/sudoers'введя команду

visudo Затем распакуйте 2 строки ниже в этом файле, а затем сохраните ## Uncomment to allow any user to run sudo if they know the password ## of the user they are running the command as (root by default). Defaults targetpw # Ask for the password of the target user ALL ALL=(ALL) ALL # WARNING: only use this together with 'Defaults targetpw' Этот метод более безопасен, потому что вам не нужно защищать как корневых, так и привилегированных (sudoer) пользователей, чтобы сохранить всю систему в безопасности.

Один usecase может быть позволяет удаленным SSH с паролем от глобальной сети: для большей безопасности (все-таки меньше, чем RSA ключом) вы можете только позволить пользователям другой пользователь, кроме root по SSH с паролем (опционально на заказ) порт из WAN. И для еще большей безопасности вы можете запросить пароль администратора после команды "sudo". В этом случае хакер должен найти 3 различных строки имя пользователя, пароль пользователя и пароль корня, чтобы получить полный доступ к системе. Даже если учетная запись пользователя скомпрометирована, злоумышленник все еще не может повредить вашу систему, потому что у него еще нет пароля root.

Способ 2: 'sudo'ing с паролем пользователя

В этом методе, после входа в пользователя, когда вы входите "sudo", вы должны снова ввести пароль пользователя. Конечный результат аналогичен тому, как вы используете "sudo" в Ubuntu или других популярных дистрибутивах Linux, но этот метод не использует группу "sudo" для этой цели.

Для включения этого метода необходимо также ввести команду

visudo А затем добавьте строку, позволяющую пользователю, под комментарием " ## Спецификация привилегий пользователя": ## ## User privilege specification ## root ALL=(ALL) ALL nicolaus ALL=(ALL) ALL
Способ 3: 'sudo' с паролем пользователя, если он является членом группы 'sudo' (необходимо установить некоторые пакеты)

Этот метод очень похож на метод 2, за исключением того, что она позволяет любому члену группы 'sudo' использовать "sudo" со своим паролем. Этот метод точно такой же, который используется в Ubuntu и других популярных дистрибутивах Linux, чтобы разрешить доступ пользователя к "sudo".

Для активации этот способ сначала вы должны позволить группе 'судо' использовать команду "sudo", введя

visudo А затем раскомментируйте строку ниже: ## Uncomment to allow members of group sudo to execute any command %sudo ALL=(ALL) ALL Во-вторых, вы должны создать группу 'sudo'. Вы можете сделать это путем редактирования вручную /etc/group - но это скорее стандарт для того чтобы установить и использовать инструменты для достижения этой цели: opkg install shadow-groupadd groupadd --system sudo Этот метод является более удобным, потому что вы можете просто позволить "sudo" доступ для любого пользователя вы хотите, просто usermod -a -G sudo <USER> но занимает больше места (для установки новых пакетов), чем метод 2, который может быть более подходящим для систем с очень ограниченным пространством.

ppp

Если вы используете PPP в конфигурации по умолчанию имя пользователя и пароль в /etc/config/network,потом непривилегированный пользователь может читать его из командной строки pppd не (с например,ps w).Чтобы предотвратить это, можно добавить "пользователя "<имя_пользователя>"" в "в/etc/ррр/Options" и /etc/ppp/{chap|pap}-secretsа затем удалить логин / пароль, параметры от UCI конфигурации.

Конечно в/etc/ppp/{chap|pap}-secretsне следует читать:

chmod go-rw /etc/ppp/chap-secrets

WebUI

Для secure web access, позже можно получить доступ через https (TLS) вместо незашифрованный протокол http. Если HTTP недостаточно безопасен для вас, вы можете отключить существующий (незашифрованный) веб-доступ и либо

  • Настройте защищенный SSL доступ с помощью uhttpd, выполнив следующие действия (проверено с 15.05)

    1. Установите генератор cert и плагин веб-сервера TLS:opkg install luci-ssl
    2. В то время как Luci SSL-шифрования автоматически устанавливает px5g, которые могут быть использованы,Вы также можете использовать openssl для создания собственного центра сертификации и сертификаты, а затем использовать этот сертификат, чтобы подписать сертификат, который вы используете для uhttpd, сохраним изменения.. Сертификаты можно также назвать или поместить в любой каталог, редактируя /etc/config/uhttpd

    3. Обратите внимание, что uhttpd, сохраним изменения.-мод-TLS не нужны после r35295 в Jan2013. Но вам нужно юстрим-библиотекой SSL wrapper на высоком библиотекой SSL (polarssl, mbedtls, cyassl, в openssl). Luci-SSL включает по libustream-mbedtls по умолчанию (с Dec2016).

    4. При необходимости укажите серверу, чтобы он больше не слушал обычный HTTP:uci delete uhttpd.main.listen_http ; uci commit

ИЛИ только переадресация на локальную сеть и перенаправление всех HTTP-запросов на https:

  1. uci set uhttpd.main.listen_http=192.168.1.1:80 uci set uhttpd.main.listen_https='192.168.1.1:443' uci set uhttpd.main.redirect_https='1' uci commit
    1. Перезапустите веб-сервер для запуска создания сертификатов:/etc/init.d/uhttpd restart
    2. При необходимости удалите генератор ключей:opkg remove px5g

Может ли обязательная проверка сертификата клиента быть настроена с помощью uhttpd? → not possible with uhttpd

Если требуется удаленный доступ к SSH, следуйте инструкциям по упрочнению на SSH, упомянутых выше.

wiki.openwrt.org


Смотрите также