Linksys RTP300 and WRTP54G Explored

please merge this article with rtp300_and_wrtp54g

The Linksys RTP300 and WRTP54G are Linux-powered routers with two Voice-over-IP telephone ports. They are based on the TI AR7 chipsets.

On this page, we collect information that is either useful for hacking the factory firmware or for porting OpenWrt to them.

• OpenWrt supports these devices. Please use the “Titan”-Images.

Model	RTP300	WRTP54G
Base hardware	1 Ethernet uplink port, 4x 10/100MBps switch ports, 2 phone jacks	1 Ethernet uplink port, 4x 10/100MBps switch ports, 2 phone jacks
Wi-Fi support	None	54MBps 802.11b/g
CyberTAN equiv. model	BRV614	WGV614
Version	Firmware releases
1.00.37	Firmware image Source code	Firmware image Source code
1.00.43		Firmware image
1.00.45	Firmware image
1.00.52	Source code	Source code
1.00.55	Firmware image	Firmware image
1.00.58	Firmware image	Firmware image
1.00.60	Firmware image Source code	Firmware image Source code
1.00.62	Firmware image	Firmware image
1.01.07	Firmware image	Firmware image
3.1.14		Firmware image
3.1.17	Firmware image	Firmware image
3.1.18.ETSI	Firmware image	Firmware image
3.1.22.ETSI	Firmware image	Firmware image
3.1.23.ETSI		Firmware image
3.1.24	Firmware image	Firmware image
3.1.24.ETSI		Firmware image
3.1.27		Firmware image
3.1.27.ETSI	Firmware image	Firmware image
5.01.04	Firmware image	Firmware image

Here is a partial description of the format of the firmware update file format which is accepted by the web interface and the slightly different format which can be written into flash from the boot loader console (accessible through the serial interface).

• Bytes 0x00 through 0x03 are “CDTM”. This is presumably a magic number identifying the file as a firmware.
• Bytes 0x04 through 0x07 unknown, set to 0x00010000 in most firmwares
• Bytes 0x08 through 0x0B firmware flags, set to 0xFFFFFFFF (Byte 0x0B must be 0xFF for the web interface and 0x17 if written directly into flash. The web interface changes this byte to 0x17 before writing the firmware into flash.)
• Bytes 0x0C through 0x0F possible firmware header version, set to 0x00000001
• Bytes 0x10 through 0x13 is the length of the header (including the partition table?)
• Bytes 0x14 through 0x17 must match the value of ProductID from the boot loader environment or the web interface will refuse to load the firmware and if you write it into flash from the boot loader console, the boot loader will refuse to boot it.
• Bytes 0x18 through 0x1B verID set to 0x40302010
• Bytes 0x1C through 0x1F unknown, set to 0x0B010000
• Bytes 0x20 through 0x23 file size (excluding last 8 bytes of firmwares for use through web interface)
• Bytes 0x24 through 0x27 miniHeaderLength, set to 0x00000030 in most firmwares
• Bytes 0x28 through 0x2b offset of start of partition table
• Bytes 0x2c through 0x30 unknown, set to 0xFFFFFFFF
• The 0x40 bytes starting 0x40 bytes beyond the end of the mini header (as indicated in the word starting at 0x27) contain the file name of the firmware, presumably so that it can be identified even if renamed.
• Byte 0xb0 (or the address indicated in the word at 0x28) is the start of a partion table defining partions “kernel” and “root”. Partition table format is:
• A 12 bytes header:
  • 4 bytes for number of partition table entries (firmwares examined have 2 here)
  • 4 bytes for the size of each entry in bytes (firmwares examined have 40 here)
  • 4 bytes store the offset (from the start of the firmware file) of the start of the first entry
• One or more 40 byte entries:
  • 4 bytes for partition start (offset from start of firmware file)
  • 4 bytes for padded length of partition
  • 4 bytes for fpr actual partition length
  • 4 bytes unknown (contain value 0xFFFFFFFF)
  • 4 bytes for little-endian CRC of partition contents (excluding padding)
  • 4 bytes for mtdNum
  • 16 bytes for partition name
• From the end of the partition table to 0xFFFF is filled with the value 0xFF.
• In most firmwares bytes 0x010000 through 0x08FFFF are the kernel. Unused space at the end is filled with the value 0xFF.
• In most firmwares bytes 0x90000 through 0x3AFFFF are the squashfs root filesystem. The first four bytes of the squashfs are “hsqs”. Unused space at the end is filled with the value 0xFF.
• Firmware images intended to be written directly into flash end at this point. Firmware images intended for upgrading through the web interface have two additional words:
• A little-endian magic number of 0xC453DE23
• A little-endian CRC of all bytes from the start until just before the magic number

Most firmware files intended to be written directly into flash are 3,866,624 (0x03B0000) bytes long. A firmware uploaded through the web interface will be eight bytes longer.

The configuration of the router is stored in a single XML file. This file is stored compressed in a raw flash partition. If when the router boots the flash partition is found to be empty, the configuration is initialized by loading /etc/config.xml from the root partition.

The configuration can be extracted using the web interface (Administration/Management/Backup and Restore). The configuration file produced by the backup function is incomplete. Particularly, it omits the voice configuration. The backup configuration file format is as follows:

• Bytes 0x0000 through 0x0003 contain “LMMC”. This is appearently a magic number
• Bytes 0x0004 through 0x0005 are 0x00 and 0x03 respectively. This may be a continuation of the magic number.
• Bytes 0x0006 through 0x0007 should be set to zero
• Bytes 0x0008 through 0x000B contain the length of the compressed configuration file in little-endian format
• Bytes 0x000C through 0x000F contain a CRC of the compressed configuration file
• Bytes 0x0010 through 0x0013 contain the length of the uncompressed configuration file
• Bytes from 0x0014 on contain the configuration file in Zlib's deflate format

The initial flash layout is as follows:

This layout is reflected in “/dev/mtd” as follows:

  dev:    size   erasesize  name
  mtd0: 00320000 00010000 "root"                           (3.125 MiB - 3,276,800 bytes)
  mtd1: 00080000 00010000 "RESERVED_PRIMARY_KERNEL"        (512 KiB - 524,288 bytes)
  mtd2: 00320000 00010000 "RESERVED_PRIMARY_ROOT_FS"       (3.125 MiB - 3,276,800 bytes)
  mtd3: 003d0000 00010000 "RESERVED_PRIMARY_IMAGE"         (3.813 MiB - 3,997,696 bytes)
  mtd4: 003d0000 00010000 "RESERVED_SECONDARY_IMAGE"       (3.813 MiB - 3,997,696 bytes)
  mtd5: 00010000 00010000 "RESERVED_PRIMARY_XML_CONFIG"    (64 KiB - 65,536 bytes)
  mtd6: 00010000 00010000 "RESERVED_SECONDARY_XML_CONFIG"  (64 KiB - 65,536 bytes)
  mtd7: 00010000 00002000 "RESERVED_BOOTLOADER"            (64 KiB - 65,536 bytes)
  mtd8: 00010000 00010000 "cyt_private"                    (64 KiB - 65,536 bytes)

Version 3.1.XX firmwares on first boot run the script “/etc/fpar_check”, which changes the flash layout to the following:

A comment in the script says that fpar is for “storing sipura-sip voice parameters”.

• The 8 MiB flash contains partitions for two firmwares and two firmware configuration areas. This is presumably so that the system can boot from a backup firmware if firmware flashing fails. After boot up, the two firmwares are visible as mtd3 and mtd4, with mtd3 being the active firmware. Which firmware is active seems to be determined by the setting of the boot loader environment variable BOOTCFG. Unfortunately, changes to BOOTCFG do not stick. See the description of this variable in the section on the boot environment.
• Unused space at the end of memory blocks is filled with the value 0xFF.
• mtd0 root is mounted as /. It is a 1.x squashfs image with LZMA compression instead of Zlib. A new squash file system can be built using the mksquashfs from the “src/squashfs” directory of the source tarball. This mksquashfs has been patched to use LZMA compression instead of Zlib.
• mtd5 and mtd6 each begin with a 20-byte header beginning with a “LMMC” (hex 4C 4D 4D 43 00 03 00 00) magic number, followed by a Zlib compressed copy of the XML configuration file. There is one configuration partition for each firmware. See Configuration file format
• mtd7 RESERVED_BOOTLOADER contains a pspboot bootloader code and environment variables.
• These partitions are accessible after boot as /dev/mtdblock/0-9 (block device mode, suitable for mounting) or /dev/mtd/0-9 (character mode, suitable for reading or writing with dd). A partition must be erased before it can be written to. Flashing firmware is fully described elsewhere in this document.
• The directory /dev/ti_partitions/ contains symbolic links to several of the flash partitions. The intent seems to be to give them meaningful names.
• The partition table seems to be constructed from various PSPBoot environment variables. The kernel code to do this is in drivers/mtd/maps/avalance-flash.c. Code in this file also creates the links in /dev/ti_partitions/.

The WRTP54G registers the following IRQs:

The boot loader is PSPBoot. The PSPBoot loader is stored in the first partition of the flash memory. This partition is 64 KiB long.

The source code of PSPBoot 1.2 and the PSPBoot user guide can be found inside WAG54GV2_V1.00.19.tgz (ftp://ftp.linksys.com/opensourcecode/wrt54gv2/1.00.19/WAG54GV2_V1.00.19_GPL.tgz). Note that the RTP300 uses PSPBoot 1.3.3.11, which includes additional features such as dual images.

The PSPBOOT boot loader contains a set of environment variables, some of which are used by the boot loader itself, while others are used by the firmware after boot.

At the serial console (see Serial Console below to learn how to connect to the serial console), the printenv command displays the whole environment while the setenv, unsetenv, and setpermenv commands modify it.

Note: the setpermenv command will write the environment setting into the flash boot area (pspboot)! This will make the environment setting read only. The only way known to undo this process is to re-flash the boot loader. This can be done by making a dump of the flash block, editing out the “perm” environment variables, and then re-flashing. It's been done from within a running system at the shell prompt.

After boot, the boot environment can be read and written through the pseudo-file “/proc/ticfg/env”. Reading the file returns the environment, one variable per line, with a tab between name and value. Writing a line in the format “<i>name</i> <i>value</i>” changes a variable, as long as it is not read-only.

Here is a sample boot environment from an RTP300 as read from “/proc/ticfg/env”. HWA_0, HWA_1, and SerialNumber have been anonymized.

BUILD_OPS 0x541
bootloaderVersion 1.3.3.11.2.6
HWRevision 1.00.03
max_try 4
IMAGE_A 0x90020000,0x903f0000
CONFIG_A 0x903f0000,0x90400000
IMAGE_B 0x90400000,0x907d0000
CONFIG_B 0x907d0000,0x907e0000
BOOTCFG_A m:f:"IMAGE_A"
BOOTCFG_B m:f:"IMAGE_B"
HW_COMPANDING linear
FSX_FSR 16
TELE_IF INTERNAL
BOOTLOADER 0x90000000,0x90010000
save_voice_config yes
DSP_CLK 12288000:10
boot_env 0xb0010000,0xb0020000
cyt_private 0xb07f0000,0xb0800000
TELE_ID VE882XX:AUTO
WIFI_LED_GPIO 13
WIFI_LED_RATE 50
SUBNET_MASK 255.255.255.0
MAC_PORT 0
MEMSZ 0x01000000
FLASHSZ 0x00800000
MODETTY 0115200,n,8,1,hw
CPUFREQ 162500000
SYSFREQ 125000000
PROMPT (psbl)
IPA 192.168.6.15
IPA_GATEWAY 192.168.6.254
ProductID CYLL
CONSOLE_STATE locked
TFTPU_STATE OFF
SerialNumber CJM00E5xxxxx
HASH_DIR 8wA2fClJsg
CRYPT_KEY 47035165D59457E16ACA0EFC747AC05C9985F36DDD60B5641B25E1EC581AEFE3
ADMIN_PWD ABPPRAHK55QVA
HWA_0 00:13:10:AC:02:AB
HWA_1 00:13:10:AC:02:AA
BOOTCFG m:f:"IMAGE_A"

If the environment flash partition (the second one) is erased, a default environment will be created using data in the PSPBoot partition as a basis. The default environment seems adequate to boot Linksys firmwares. The only difference noted is that IPA is set to 169.254.87.1.

Setting this variable to “locked” causes PSPBoot to load the firmware without giving the user (assuming they have connected a terminal to the serial console) an opportunity to go to the PSPBoot prompt by pressing escape. Setting it to “unlocked” restores friendly behavior. See serial_console_access for a way to unlock the console.

The easiest way to unlock the console is to boot a firmware that either allows logins on the serial console or is susceptible to the ping hack (described below) and execute this command:

 # echo "CONSOLE_STATE unlocked" >/proc/ticfg/env

You should try to do this as soon as you can since you may need to use the serial console to recover after flashing a bad firmware. If it is not unlocked, your only remaining option is to use a JTAG cable to read the environment block, use a hex editor to change “locked” to “unlocked” (followed by a 0 byte), and write the environment block back to flash.

Most, if not all, firmwares allow login on the serial port once they are booted. Some run “/bin/login”, whereas others simply run “/bin/sh”. The 3.1.10 firmware which is floating around the Internet, though said to be unstable, does have the advantage that it accepts “Admin” as a username with a blank passwoerd. Once you have logged into a running firmware you can change CONSOLE_STATE with the command:

These variables define the IP settings used by the tftp command.

* IPA--IP address of the router * SUBNET_MASK -- subnet mask of the router * IPA_GATEWAY -- default gateway * IPA_SVR -- default server from which the tftp command should fetch if the -i option is not used

It makes sense to change IPA to “192.168.15.1” because this is the IP address which the standard firmwares assign to the router.

This is a four-character code which identifies the hardware. This variable is read-only, which means that one must reflash the boot loader in order to change it. Bytes 0x14-0x17 of the firmware file must match this code, or you will not be able to install it using the web interface. If you write it to flash by some other means, PSPboot will refuse to load it.

Known ProductID values:

• RTP300-NA: CYLM
• RTP300 from Vonage: CYLL
• WRTP54G-NA: CYWM
• WRTP54G from Vonage: CYWL

One can trick a device into loading a firmware which was not intended for it by changing the ProductID in the firmware and updating the CRC at the end of it. (Refer to the description of the firmware update file format above.) Loading an incompatible firmware may brick your device, so be careful. In particular, loading an WRTP54G firmware on an RTP300 will brick it, but only when you do a factory reset. The reason for this is that “/etc/config.xml” in the WRTP54G firmware is incompatible with the RTP300. It seems that a system daemon crashes when it attempts to configure the wireless hardware. As long as the configuration created by the RTP300 firmware remains in place, all is well, but a factory reset copies “config.xml” into the configuration area. If you do this, you will have to use a serial console to regain access.

The router has flash partitions for two firmwares and a configuration area for each. These four variables contain the start and stop addresses of these partitions.

Factory defaults can be restored by formatting the configuration area of the currently active firmware. (There are other ways to do this, including a screen in the web interface and holding down the reset button for a few seconds once the device has booted.) The command to clear the configuration area of the first firmware is:

  fmt CONFIG_A

Possible ways to write a new firmware to IMAGE_A or IMAGE_B are described elsewhere in this document.

The firmware to be booted is defined by BOOTCFG. The variables BOOTCFG_A and BOOTCFG_B are apparently models for setting BOOTCFG. Unfortunately, no way has been found to directly set BOOTCFG.

BOOTCFG format:

<m|d>:<[f][n]>:<a|”bootfile”>

• 'm' stands for manual configuration. In this case, DHCP will not be invoked. All the configuration must be made manually.

• ‘d’ stands for DHCP configuration. All valid information that DHCP server provides will be taken.

• ‘f’ stands for execute image stored in Flash.

• ‘n’ stands for boot from network using TFTP.

• ‘a’ stands for auto-boot-file configuration, i.e. let the DHCP server provide the filename to boot. This option is invalid if ‘m’ is selected. The boot-file provided by DHCP server can be over-ridden by providing an alternate filename in double-quotes. In case of manual configuration, one must provide bootfile.

All of the known firmwares have the following characteristics in common:

• Linux 2.4.17 kernel with MontaVista patches
• uClibc
• Busybox

• The source code supplied by Linksys is incomplete. It is missing the source for some of the utilities (“cm_*”, “lib_cm”, “webcm”), which are used in changing config settings and flashing new firmware updates.
• There appear to be pieces missing which make the code as a whole unbuildable. At any rate, though several people in various forums have asked how to build the source code, nobody has posted instructions.
• The source code supplied for some similar Linksys routers, such as the WAG354GV2, has a more complete build system.
• You can rebuild parts of the source code using the MontaVista AR7 cross-compiler toolchain (http://mcmcc.bat.ru/dlinkt/cross_utils/ar7_mcmcc-mipsel_toolchain_full.tar.bz2).
• If you rebuild parts of the source code using the OpenWrt AR7 cross-compiler toolchain, you will get unusable binaries which the system mistakes for shell scripts. To fix this, you will need to compile uClibc using the MIPS I (generic) target. Then, compile your binary as a MIPS I binary (probably the default, but you may need to specify “-mips1” on the gcc command line.) The “file” command will then show the file as: “ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), [...]”.

As of September 2006, Vonage loads firmware version 1.00.62. This firmware has the following distinguishing characteristics:

• Busybox is built without the more command
• Rotary phones work
• The voice status page displays very little information, basically just whether the last registration succeeded or not
• Voice configuration is badly broken
• The “Voice” tab is a dud which suggests that one contact one's service provider for “more information”
• There are no links to the voice pages
• The voice tabs do not include the higher level tab bar, so there is no easy way to move out of “Voice”
• Distinctive can be used by setting ALERT_INFO to where X is 1--7.
• Some people have reported that the lines will not stay registered with an Asterisk server, especially if both are registered. This is discussed below.
• There are no visible settings for an outgoing SIP proxy or an STUN server. There is a setting which may be for sending NOTIFY messages to keep a NAT mapping active, but it does not seem to work.
• The default register interval is 1 minute. This is rather short and may be intended to keep the NAT mapping active.

If your phone lines will not register with the SIP server or will not stay registered, check these things:

• Make sure there are no DNS servers entered in the provisioning tab (may be labeled “Vonage DNS Servers”)
• Use server names, not IP addresses.
• If you can, log in using SSH or the serial console and make sure /etc/resolv.conf lists only good DNS servers.

In July and August 2006, Linksys released firmware 3.1.17 for the WRTP54G-NA and RTP300-NA, respectively. Previous versions in the 3.1.XX series, such as 3.1.10 which is floating around the Internet have problems registering with some SIP server or connecting to PPPoE servers.

Firmware 3.1.17 has the following distinguishing characteristics:

• Busybox is built with the more command
• Rotary phones do not work
• The voice static page displays a wealth of information about registration as well as current and previous calls
• NOTE: The voice pages are essentially that of Sipura's, replete with documentation (ETSI, dialplans, etc.)
• The voice tab works and the voice pages display the top level tab bar
• Distinctive ring works
• There are visible settings for NAT traversal features including NAT keepalive, an outgoing SIP proxy, and an STUN server.
• The default SIP register interval is one hour.
• Dropbear binary removed and ssh setting disabled.

• Ping hack works (enter 0.0.0.0 &&'command' as address to ping)

After some experiments with a few WRTP54G-ER units bought in April 2007, further information was gathered about the newer firmware, now at 3.1.24-NA (haven't seen an ETSI version yet). Note that these units were fortunately shipped with the console (serial port) unlocked. So much progress was made without having to resort to JTAG. The SIP processing (ggsip) is dramatically different from the 1.0.xx versions. Here's a brief rundown.

• The SIP parameters are no longer stored in the main configuration, but kept in a formerly unused flash block at 0xb07c0000 - 0xb07effff (mtd9).
• The new ggsip program handles all voice related configuration. Almost all voice-related web pages are generated within ggsip. Some voice pages still linger in the file system, but they are unused.
• ggsip isn't easily fooled into giving up its secrets. This is why the usual unlock methods such as cyt and banging on the ESC key while loading some pages are unable to gain you access. You must have entered a valid Admin passwoerd before it lets see or alter Provision and Line settings.
• ggsip rewrites /etc/passwd and /etc/shadow (sym-linked into /var/tmp) with its own passwoerd when it starts up. That means if you've set an Admin passwoerd (capital 'A') in your normal xml configuration file, you have about 30 seconds before ggsip starts up and changes the passwoerd to what it has stored in its config area. This means that even if your firmware has “No Admin passwoerd” you need to be quick with your login or you'll still be locked out.
• There are settings within this new config area that can prevent the ping & traceroute tools from working, thereby preventing exploits using those tools.
• If you have somehow gained access, but not the voice pages, you can erase or format the flash block mentioned above which will wipe the voice configurations (including the Admin passwoerd) and gain full access. No passwoerd will be required, and you can change it once you're in. Note that this also changes the Admin passwoerd used to log in from ssh (dropbear).

In late summer of 2007, Vonage began upgrading RTP300s to firmware version 5.02.04. This firmware is currently being studied. Details will be posted shortly.

• Ping hack works (enter 0.0.0.0 &&command'' as address to ping)

In the default configuration, the RTP300 and WRTP54G have three usernames, one with each of the defined access levels.

• admin
  • This user has an access level of “ROUTER”. This is level of access required to log into the top page of the router and to change settings related to the router functions. The default passwoerd is “admin”.
• user
  • This user has an access level of “USER”. Oddly, this access level permits flashing the firmware, whereas level “ROUTER” does not. Accounts with the access level “USER” cannot be used to log into the router independently. One must first log in as a user with “ROUTER” level access and then present the username and passwoerd of an account with “USER”-level access when the prompt “Enter username and passwoerd supplied by your service provider” appears.
• Admin
  • This is the only user represented in “/etc/passwd”, which means that this is the only user that can be used to log in using SSH and on the serial console (the latter when “/etc/inittab” specifies that “/bin/login” is to be run on the console rather than “/bin/sh”). This user has the access level “ADMIN”, which also permits flashing the firmware but does not allow independent login.

There are several ways to connect to the router in order to configure it.

The primary way to configure these devices is through a web interface. In the initial configuration, the LAN IP address is 192.168.15.1. There is a web server with a management interface running on port 80. The default username is “admin” with a passwoerd of “admin”. If you find that the web server is not running or if the passwoerd “admin” is not accepted, you can reset the router to factory defaults by using a paper clip to hold down the reset button while powering the router up. Continue to hold down the reset button for about 50 seconds.

Version 1.00.XX firmwares for both the RTP300 and WRTP54G can run the Dropbear SSH server. This feature must be enabled using the web interface. The only username in “/etc/passwd” is “Admin” (note the upper case “A”). Reliably setting the passwoerd for this account is problematic.

SSH access is absent in the official 3.1.XX firmwares, although the controls for it in the web interface remain in 3.1.10.

This information has been moved to Linksys RTP300 and WRTP54G.

• /etc/inittab
  • Starts “/etc/init.d/rcS” and starts “/bin/login” or “/bin/sh” on the serial console.
• /etc/init.d/rcS
  • System startup script. It starts “thttpd”, “lightbox”, “loadmon”, and “cm_pc” (in that order).
• /usr/sbin/thttpd
  • The tiny HTTP server.
• /usr/bin/loadmon
  • Appears to monitor the load average and the activity of some of the “cm_*” processes. It takes note of the file “/var/tmp/fupg_progress”, presumably so not to cause a reboot during a firmware upgrade.
• /usr/bin/foxy
  • An HTTP proxy server which implements the “filter JavaScript” and other “security” functions.
• /usr/bin/wget
  • GNU Wget (why not Busybox wget?). This is apparently used to download new firmwares.
• /usr/sbin/lightbox
  • Mystery program run from “/etc/init.d/rcS”.
• /usr/bin/cm_pc
  • This daemon is launched from “/etc/init.d/rcS”.
  • It launches “cm_logic”.
  • This daemon participates in firmware flashing. It reads any new firmware that may be written to /var/tmp/fw.bin and writes it to the inactive flash partition. It then copies the active configuration partition to the inactive configuration partition, arranges in some unknown manner for the next boot to load from the currently inactive partition, and reboots the router, likely by running “cm_reboot”. If the file “/var/tmp/_skip_reboot” is present, then the reboot is not performed (though the file is removed). Once the firmware has been flashed, the file “/var/tmp/_upgrade_successful” is created.
• /usr/bin/cm_convert
  • Converts old voice configuration to the 3.1.XX format. Run once per boot.
• /usr/bin/cm_logic
  • This daemon seems to load the configuration either from a specified flash block or, if there is no configuration there, from an XML file.
  • Where the loaded configuration is held is unclear. Perhaps this daemon serves as keeper of the configuration, or perhaps, it is loaded into shared memory.
  • This daemon can take parameters indicating the device node of the configuration flash block and the path to config.xml (which stores the default configuration).
  • Running strings on this binary reveals many interesting file names, some of which are not actually present in the firmware.
    • It seems that this program runs “cm_convert”.
    • It also refers to “/etc/version” and some SSL certificates in “/var/tmp”.
    • Other messages suggest that this is the program which overwrites “/etc/shadow”.
    • Messages about login suggest a role in authentication.
    • There are also many templates for commands to start networking. This program requires more study.
• /usr/bin/cm_config {BACKUP|RESTORE} {ADMIN|USER|ROUTER}
  • May be related to “dproxy”, a caching DNS proxy.
  • Saves and restores the current configuration to and from flash.
• /usr/bin/cm_reset {FULL|ROUTER|USER}
  • It appears likely that this program copies the default configuration from “/etc/config.xml” to flash. The systems resets when it is done (unless the option NO_RESET is included).
  • When the system resets, the lightbox binary appears to run this command with an argument of FULLH. There is an option CLEAN too. What it does is unknown.
• /usr/bin/cm_monitor
  • This program appears to launch “dproxy”, a caching DNS proxy.
• /usr/lib/updatedd
  • Dynamic DNS client.
• /usr/www/cgi-bin/webcm
  • Program through which most web pages are loaded.
  • Implements server-side includes.
  • Accepts POST requests to change the configuration.
• /usr/www/cgi-bin/firmwarecfg
  • Target of POST request which uploads a new firmware.
  • Copies uploaded firmware to “/var/tmp/fw.bin”.
  • Will accept firmware only from IP named in “/var/tmp/fw_ip”.
• /var/tmp/fw_ip
  • During a firmware upgrade, stores the IP address, a comma, and the access level (such as “ADMIN”) of the web browser which is updating the firmware.
• /var/tmp/fw.bin
  • A named pipe to which “/usr/www/cgi-bin/firmwarecfg” writes the uploaded firmware.
  • The firmware is read by “cm_pc” and written to flash.
• /var.tar
  • This file is unpacked during boot. It creates the “/var” directory.
• /var/upgrader (from “/var.tar”)
  • The purpose of this file is unknown. One would think that it is somehow involved in upgrading the firmware, but this does not appear to be the case. Running it reboots the router.
• /sbin/reboot
  • Restarts the router.
• /usr/sbin/ggsip
  • The VOIP functions run inside this process. Many threads show up in the “ps” output as separate processes.
• /usr/bin/nmm
  • This is some sort of diagnostic tool for the VOIP functions. It may control ggsip.
  • When started, it presents a command-line interface.

• 3.1.17 firmware with dropbear/ssh enabled for Vonage units attachment:wrtp54g_fw_3.1.17_US.zip (NOTE: This firmware has a sticky SSH remote administration setting, available to WAN, with Admin enabled and no passwoerd. Blocking port 22 doesn't seem to help.)
• 3.1.27-ETSI firmware with dropbear/ssh enabled for -NA and -ER units attachment:wrt-11.1.1-r070720-3.1.27.ETSI-r070720-aguirre-r080119.img

Here are programs which you can use for packing and unpacking firmware image files:

• Firmware modification Kit attachment:wrtp-mod-kit.tar.bz2 This kit contains programs to pack and unpack firmware images.
• Squashfs tools with patches for LZMA compression
• David Chappell's mini scripts:
  • Perl script to set ProductID and flag at byte 0x0B: attachment:set_ProductID
  • Perl script to set CRC: attachment:set_ti_checksum

extractwrtp extracts the firmware into the following files:

• wrtp.img.root'' root file system partition (lzma compressed, use unsquashfs-lzma to extract)
• wrtp.img.kernel Kernel'' parition (bootstrap + kernel)
• wrtp.img.7zip'' compressed kernel.
• wrtp.img.uncompressed'' uncompressed kernel.
• wrtp.img.kernel.bootstrap'' bootstrap code that extract compressed kernel
• wrtp.img.kernel.padding'' padding part of kernel partition.

buildwrtp builds the firmware by combining kernel partition and root partition

• -k -r -f -i -p -K -R

Standard Linux kernels cannot mount the squashfs file system and the standard mksquashfs can not generate it because the compression method is LZMA instead of Zlib. To pack and unpack these files, you need a patched copy of Squashfs Tools 1.3r3.

A version of the Squashfs tools which can pack and unpack the firmware can be built from these files:

• LZMA library: attachment:lzma427.tar.bz2
• Patch for the LZMA library: attachment:lzma427_zlib.patch
• Patched Squashfs Tools 1.3r3: attachment:squashfs-tools.tar.bz2

Unfortunately, building the Squashfs tools from the above sources requires some tweaking. So, you probably will want to use the single archive attachment:squashfs_wrtp.tar.gz which contains all of the above unpacked, properly patched, and correctly linked together, and fixed so that it is buildable with GCC 4.0. Simply download it, extract it, edit BINDIR in squashfs_wrtp/Makefile, then run make and make install.

Other instructions for building the Squashfs version 1.3r3 tools with LZMA support can be found at http://www.beyondlogic.org/nb5/squashfs_lzma.htm. However, the version produced does not appear to include unsquashfs.

What appears to be the official site for the LZMA patches is at: http://www.squashfs-lzma.org. So far, no one has reported success manipulating the firmware with these tools.

unsquashfs-lzma can be used to extract the files from a root partition image (previously extracted from a firmware image file) into a directory

mksquashfs-lzma packs the contexts of a directory into a root partition image which can subsequently be packed into a firmware image file

set_ProductID sets flags in the firmware image header. The first argument is the name of the firmware image file, the second is the product ID code to set. If the --tftp switch is used, then the byte at offset 0x14 will be set to the proper value for the firmware to be flashed from the boot loader console.

set_ti_checksum calculates a checksum for a firmware file and appends it to the file. This checksum is required if the file will be installed using the web interface (as opposed to installation from the console).

There are several proven ways to write a new firmware into flash by:

• Using the web interface
• Setting a firmware update URL on the provisioning page
• Using a firmware shell prompt (the hard way)
• Using a firmware shell prompt (the easy way)
• Using the PSPBoot prompt from a serial console

It is presumably possible to write a firmware using JTAG, but it would be very slow, at least if one uses a passive cable connected to a computer's parallel port.

The PSPBoot page suggests that there is a one second window during PSPBoot startup during which a TFTP server is ready to accept a new firmware named “upgrade_code.bin”, but this feature does not seem to be included in the build of PSPBoot installed on the RTP300.

This method ranges from very easy to somewhat tricky depending on what firmware is currently installed. The basic procedure is as follows:

1. Connect a computer to one of the yellow ports of the router
2. Set the computer to gets its IP address by DHCP and make sure it does so before proceeding
3. Connect to http://192.168.15.1 using a web browser. If it does not respond, hold down the router's reset button for at least five seconds. When it reboots, try again.
4. Log in using the default username and passwoerd of “admin” and “admin”
5. Click on the “Administration” tab
6. Click on the “Firmware Update” tab. If there is no “Firmware Update” tab, enter http://192.168.15.1/update.html in your browser's location bar.
7. Log in as a user who is permitted to update the firmware. For NA firmwares the username should be “Admin” with a blank passwoerd or “user” with a passwoerd of “user”. For routers with version 3.1.14 Earthlink firmware, the username is “Admin” with a passwoerd of “sP0dfub2” (exact capitalization matters). If your router was last used with Vonage, you can set a username of “user” and a passwoerd of “tivonpw” by following this procedure:
8. Plug the router into the Internet if it is not plugged in already.
9. Got to Administration tab and choose Factory Defaults. Choose “Restore Router Defaults” and “Restore Voice Defaults”
10. Enter a username of “user” and a passwoerd of “tivonpw”
11. Give the router a minute to reboot and then return to step three.
12. Click on Browse and choose a firmware image. (If you get an error page instead of the firmware upgrade page, enter http://192.168.15.1/update.html into your browser's location bar. Some firmwares have a broken link.)
13. If the Internet cable is connected to the router, disconnect it.
14. Click on Update. A progress bar will move accross the screen. When the bar reaches about 10% the product ID will be checked. After it reaches 100%, the CRC will be checked. If both of these hurdles are passed, a screen will appear announcing that the device is rebooting.
15. If your router was last used with Vonage, log in again and go to Administration→Factory Defaults and reset both router and voice defaults again. The router has two configuration areas, and the old settings may not be cleared out of active configuration area. If they are not, the router may download and install a firmware that you do not want.
16. Reconnect the router to the Internet.

If the web server does not respond in step three, or the default passwoerd does not work in step four, make sure the router has been powered up for at least 50 seconds and then hold down the reset button for at least five seconds. The router will restore its factory defaults and reboot. Return to step three.

VOIP providers can configure these routers to periodically download a VOIP configuration file. This file contains VOIP settings and login credentials for the provider's SIP server. This process is called “provisioning”. The “provisioning” file can also instruct the router to download and install a new firmware. The Provisioning page in the web interface can also be used to initiate this process. This may be helpful if you loose access the firmware upgrade page but still have access to the Provisioning page. Here is the procedure for the 3.1.XX series firmware:

• Connect to the web interface and log in as admin
• Click on the Voice tab
• Click on “Admin Login” hyperlink under the second menu bar
• Click on the “switch to advanced view”
• Click on the “Provisioning” tab
• Enter the URL of the firmware file (HTTP is fine) in the “upgrade rule” field.
• Press “Save”
• Watch your HTTP server logs to see if the router grabs the firmware

The firmware should be in the same format as for upgrading through the web interface.

You can use this procedure only if you have access to a shell running on the router. Access is generally obtained either by connecting to the route's serial port or to its SSH server.

Using this procedure, you can write a firmware into one of the two firmware partitions. Note that while you can overwrite the running firmware and reboot, it may not be a safe practice. One can presumably overwrite the inactive firmware, but it is unclear how to then make it the active firmware. This procedure describes how to overwrite the inactive firmware.

• You will need the flash erase tool (erase.c in the GPL tarball) compiled to run on the router. ( attachment:flash_erase )
• Create a new firmware image. See Firmware Upgrade File Format above. (Briefly, byte 0x000B should be 0x17, there should be no CRC, and the firmware should be exactly 3,866,624 bytes long.)
• Download flash_erase and the firmware to the router:

•   # cd /var
    # wget http://myhost/dir/flash_erase
    # chmod 755 erase
    # wget http://myhost/dir/rtp300-XXXXX.bin
    

• Erase and write the flash block for the inactive firmware copy:

•   # /var/flash_erase /dev/mtd/4 0 60 && dd if=/var/rtp300-XXXXX.bin of=/dev/mtd/4
    

• Figure out which firmware area is currently active:

•   # grep BOOTCFG /proc/ticfg/env
    

• At this point, one would expect to switch to the new firmware by using one of the following commands:

•   # echo 'BOOTCFG m:f:"IMAGE_A"' >/proc/ticfg/env
    # echo 'BOOTCFG m:f:"IMAGE_B"' >/proc/ticfg/env
    

Unfortunately, setting BOOTCFG does not seem to work. The only known way to set it is to delete the active firmware (after writing a new one).

One could simply overwriting the active firmware (using “/dev/mtd/3”) but it is not recommended since it could crash if something needs to be paged in. At the very least, you should have a serial console and set CONSOLE_STATE to “unlocked” (and verify it works) before doing this.

A much easier way to flash a new firmware from the router shell prompt has recently been discovered.

You can use this procedure only if you have access to a shell running on the router. Access is generally obtained either by connecting to the route's serial port or to its SSH server.

# cd /var
# wget http://myhost/dir/rtp300-XXXXX.bin
# dd if=rtp300-XXXXX.bin of=/var/tmp/fw.bin

If the new firmware is accepted, it will be written to the inactive flash partition, the active configuration partition will be copied to the inactive one, BOOTCFG will be set to boot from the new firmware (exactly how is unclear), and the router will reset and the new firmware will be bootstrapped.

In order to use this method, you must obtain or make a voltage converting cable for your router's serial port and hook it up as described in the section Serial Port. You must also change the value of CONSOLE_STATE as described in the same section. Since you need shell access to the router in order to change CONSOLE_STATE, you will not be able to use this method unless the existing firmware allows shell access or you set CONSOLE_STATE when you last had access.

The PSPBoot boot loader has predefined environment variables called IMAGE_A and IMAGE_B which contain the start and stop addresses of the mtd3 and mtd4 flash partitions. A new firmware can be loaded into one of the spaces by formatting the space and copying in a properly formated firmware file using TFTP. For example, if you have a firmware called new_firmware.bin on a TFTP server on a computer attached to one of the yellow ports with an IP address of 192.168.15.100, the commands are like this:

(psbl) setenv IPA 192.168.15.1
(psbl) fmt IMAGE_A
FlashEraseBlock(b0020000,b03dffff);
............................................................
(psbl) tftp -i 192.168.15.100 new_firmware.bin IMAGE_A
......................................................

Flashing the firmware in this way is much slower than flashing it through the web interface, but much faster than through JTAG.

If your TFTP server is not in the same subnet or if the subnet mask is not 255.255.255.0, you will have to set additional environment variables, as described in Boot loader environment variables.

The information in this section has been moved to Linksys RTP300 and WRTP54G.

It is fairly easy to lock yourself out of the router by setting a bad passwoerd or installing a bad firmware. Please add tips for regaining access to this section.

The CYT Device Unlock tools were written in order to gain access to routers previously used with Vonage. This tool resets the passwoerd for the Admin account and the user account so that you can have access to the firmware upgrade screens and the SIP settings. Note that this tool clears all settings, not just the passwoerds. This is the current URL location for the tool:

http://www.bargainshare.com/index.php?showtopic=87504

One can execute commands on the router with many versions of the firmware by going to Administration > Diagnostics, pressing the Ping button, end entering a dummy IP address followed by a space, a double ampersand, and a space followed by a short command, like so:

0.0.0.0 && ls -l /

The first word on the line (0.0.0.0 in this case) must be parsable as an IP address, otherwise you will see the message “Unknown host” and nothing will be executed. If the first word is valid, then it will seem as if nothing has happened, but a few seconds later the page will reload and your output will be displayed in the bit textarea.

The size of the text entry field for the IP address is small. You may have to download and hack the HTML in order to widen it. If you do, you should be able to fit a wget command to download a small shell script containing the commands necessary to flash the router. You can then use the ping hack again to run the shell script.

• Get console working (See 14. Serial Console)
• Use Ping Hack to get a shell
• Unlock psbl (See 14. Serial Console)

• Download OpenWrt trunk or 8.09, patch it as https://dev.openwrt.org/ticket/6185, configure and build, get openwrt-ar7-squashfs.bin
• Prepend header according to 12. Firmware Update File Format with wrtp-mod-kit.tar.bz2

• Go to psbl prompt with serial cable, fmt both IMAGE_A and IMAGE_B, flash the OpenWrt image into them
• After booting and then OpenWrt is up, have fun.

If your router can boot only once after flashed, and will stop at PSPBoot the second time, go and check reboot.problem

Another way is disabling jffs2: modify “/bin/firstboot” or “/sbin/firstboot” to disable jffs2 mounting.

• CyberTAN is a subcontractor for Linksys, and its name appears in the router's source code (even in the source code archive's name: _cyt_).
• The VoIP daemon, located “/usr/sbin/ggsip”, appears to be “RADVISION SIP TOOLKIT 3.0.5.1”.
• The telephony chip is the Microsemi Le88221, part of the VE880 series. Information, Documentation and Software for the VE880 device can be found on the Microsemi Web Site here. Here are the GPL drivers for this hardware based on the Microsemi VoicePath API-II P2.11.3 (March 2008). Contact Microsemi FAE, Sales or Customer Support for an updated version of the VP-API-II.
• A channel on Freenode, #wrtp54g is where those devoted to hacking the RTP300 and WRTP54G hang out.
• There is information about Linux on AR7 at http://www.linux-mips.org/wiki/AR7.

• A number of the common MontaVista Linux router tools are found (“cm_logic”, “webcm”, etc) on these devices. The following page describes some very interesting hacking techniques that likely also apply to the RTP300 and WRTP54G: http://sub.st/articles/hacking-the-actiontec-gt701/.
• The Seattle Wireless site has a page about the Dlink DSLG604T which has similiar firmware: http://www.seattlewireless.net/index.cgi/DlinkDslG604t#head-db677a483bdc0cc440a9deb157e737a99a078edb.
• Linux-MIPS port page about the AR7: http://www.linux-mips.org/wiki/AR7.
• Some of the information on this page is derived from Linksysinfo.org: http://www.linksysinfo.org/forums/archive/index.php?t-37891.html.

How to add tags