Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revisionBoth sides next revision | ||
| toh:linksys:rtp300 [2011/11/05 10:34] – optimization orca | toh:linksys:rtp300 [2018/02/20 18:52] – ↷ Links adapted because of a move operation bobafetthotmail | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Linksys RTP300 and WRTP54G Explored ====== | ||
| + | | FIXME please merge this article with [[toh/ | ||
| + | |||
| + | The Linksys RTP300 and WRTP54G are Linux-powered routers with two Voice-over-IP telephone ports. | ||
| + | |||
| + | 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 " | ||
| + | |||
| + | |||
| + | ^ 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 | [[http:// | ||
| + | ^ Version ^ Firmware releases ^^ | ||
| + | | 1.00.37 | [[http:// | ||
| + | | 1.00.43 | | [[http:// | ||
| + | | 1.00.45 | [[http:// | ||
| + | | 1.00.52 | [[ftp:// | ||
| + | | 1.00.55 | [[http:// | ||
| + | | 1.00.58 | [[http:// | ||
| + | | 1.00.60 | [[http:// | ||
| + | | 1.00.62 | [[http:// | ||
| + | | 1.01.07 | [[http:// | ||
| + | | 3.1.14 | | [[http:// | ||
| + | | 3.1.17 | [[http:// | ||
| + | | 3.1.18.ETSI | [[http:// | ||
| + | | 3.1.22.ETSI | [[http:// | ||
| + | | 3.1.23.ETSI | | [[http:// | ||
| + | | 3.1.24 | [[http:// | ||
| + | | 3.1.24.ETSI | | [[http:// | ||
| + | | 3.1.27 | | [[http:// | ||
| + | | 3.1.27.ETSI | [[http:// | ||
| + | | 5.01.04 | [[http:// | ||
| + | |||
| + | |||
| + | ===== File format descriptions ===== | ||
| + | ---- | ||
| + | ==== Firmware update file format ==== | ||
| + | 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 " | ||
| + | * Bytes 0x04 through 0x07 unknown, set to 0x00010000 in most firmwares | ||
| + | * Bytes 0x08 through 0x0B firmware flags, set to 0xFFFFFFFF | ||
| + | * 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, | ||
| + | * 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 " | ||
| + | * 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 " | ||
| + | * Firmware images intended to be written directly into flash end at this point. | ||
| + | * 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. | ||
| + | |||
| + | ==== Configuration file format ==== | ||
| + | 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 / | ||
| + | |||
| + | The configuration can be extracted using the web interface (Administration/ | ||
| + | |||
| + | * Bytes 0x0000 through 0x0003 contain " | ||
| + | * 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 | ||
| + | |||
| + | ===== Flash layout ===== | ||
| + | ---- | ||
| + | ==== Flash memory layout of RTP300 ==== | ||
| + | The initial flash layout is as follows: | ||
| + | ^ PSPBoot name ^ Start ^ End ^ Size ^ | ||
| + | | BOOTLOADER | 0xB0000000 | 0xB0010000 | 0x010000 (64 KiB) | | ||
| + | | boot_env | 0xB0010000 | 0xB0020000 | 0x010000 (64 KiB) | | ||
| + | | IMAGE_A | 0xB0020000 | 0xB03F0000 | 0x3D0000 | | ||
| + | | CONFIG_A | 0xB03f0000 | 0xB0400000 | 0x010000 (64 KiB) | | ||
| + | | IMAGE_B | 0xB0400000 | 0xB07d0000 | 0x3D0000 | | ||
| + | | CONFIG_B | 0xB07d0000 | 0xB07e0000 | 0x010000 (64 KiB) | | ||
| + | | | 0xB07e0000 | 0xB00f0000 | 0x010000 (64 KiB) | | ||
| + | | cyt_private | 0xb07f0000 | 0xb0800000 | 0x010000 (64 KiB) | | ||
| + | |||
| + | This layout is reflected in "/ | ||
| + | |||
| + | < | ||
| + | dev: size | ||
| + | mtd0: 00320000 00010000 " | ||
| + | mtd1: 00080000 00010000 " | ||
| + | mtd2: 00320000 00010000 " | ||
| + | mtd3: 003d0000 00010000 " | ||
| + | mtd4: 003d0000 00010000 " | ||
| + | mtd5: 00010000 00010000 " | ||
| + | mtd6: 00010000 00010000 " | ||
| + | mtd7: 00010000 00002000 " | ||
| + | mtd8: 00010000 00010000 " | ||
| + | </ | ||
| + | |||
| + | Version 3.1.XX firmwares on first boot run the script "/ | ||
| + | ^ PSPBoot name ^ Start ^ End ^ Size ^ | ||
| + | | BOOTLOADER | 0xB0000000 | 0xB0010000 | 0x010000 (64 KiB) | | ||
| + | | boot_env | 0xB0010000 | 0xB0020000 | 0x010000 (64 KiB) | | ||
| + | | IMAGE_A | 0xB0020000 | 0xB03E0000 | 0x3C0000 | | ||
| + | | CONFIG_B | 0xB03E0000 | 0xB03F0000 | 0x010000 (64 KiB) | | ||
| + | | CONFIG_A | 0xB03f0000 | 0xB0400000 | 0x010000 (64 KiB) | | ||
| + | | IMAGE_B | 0xB0400000 | 0xB07c0000 | 0x3C0000 | | ||
| + | | fpar | 0xB07c0000 | 0xB07f0000 | 0x010000 (192 KiB) | | ||
| + | | cyt_private | 0xb07f0000 | 0xb0800000 | 0x010000 (64 KiB) | | ||
| + | |||
| + | A comment in the script says that //fpar// is for " | ||
| + | |||
| + | ==== Additional notes about firmware blocks ==== | ||
| + | * 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. | ||
| + | * 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 " | ||
| + | * mtd5 and mtd6 each begin with a 20-byte header beginning with a " | ||
| + | * mtd7 // | ||
| + | * These partitions are accessible after boot as / | ||
| + | * The directory / | ||
| + | * The partition table seems to be constructed from various PSPBoot environment variables. | ||
| + | |||
| + | ===== Interrupts ===== | ||
| + | ---- | ||
| + | /* Must have newline after horizontal rule with no immediate subheader. Otherwise, subsequent text does not get a paragraph. */ | ||
| + | |||
| + | The WRTP54G registers the following IRQs: | ||
| + | ^ IRQ ^ Acronym ^ Source ^ Function ^ | ||
| + | | 15 | INT_7 | UART interrupt | Console serial port | | ||
| + | | 27 | INT_19 | Ethernet MAC 0 interrupt | LAN | | ||
| + | | 33 | INT_25 | VLYNQ 5-pin interrupt | Expansion slot (vlynq0) | | ||
| + | | 40 | INT_32 | Telephony interface, internal serial port | Phone port | | ||
| + | | 41 | INT_33 | Ethernet MAC 1 interrupt | WAN | | ||
| + | | 80 | | Low Vlynq Interrupts (Vlynq0) | WLAN on the expansion card (TNETW1130) | | ||
| + | |||
| + | ===== Boot loader ===== | ||
| + | ---- | ||
| + | The boot loader is PSPBoot. | ||
| + | The PSPBoot loader is stored in the first partition of the flash memory. | ||
| + | |||
| + | ==== Source code ==== | ||
| + | The source code of PSPBoot 1.2 and the PSPBoot user guide can be found inside WAG54GV2_V1.00.19.tgz (ftp:// | ||
| + | |||
| + | ==== Environment variables ==== | ||
| + | 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 // | ||
| + | |||
| + | After boot, the boot environment can be read and written through the pseudo-file "/ | ||
| + | |||
| + | //Here is a sample boot environment from an RTP300 as read from "/ | ||
| + | |||
| + | < | ||
| + | BUILD_OPS 0x541 | ||
| + | bootloaderVersion 1.3.3.11.2.6 | ||
| + | HWRevision 1.00.03 | ||
| + | max_try 4 | ||
| + | IMAGE_A 0x90020000, | ||
| + | CONFIG_A 0x903f0000, | ||
| + | IMAGE_B 0x90400000, | ||
| + | CONFIG_B 0x907d0000, | ||
| + | BOOTCFG_A m: | ||
| + | BOOTCFG_B m: | ||
| + | HW_COMPANDING linear | ||
| + | FSX_FSR 16 | ||
| + | TELE_IF INTERNAL | ||
| + | BOOTLOADER 0x90000000, | ||
| + | save_voice_config yes | ||
| + | DSP_CLK 12288000:10 | ||
| + | boot_env 0xb0010000, | ||
| + | cyt_private 0xb07f0000, | ||
| + | TELE_ID VE882XX: | ||
| + | WIFI_LED_GPIO 13 | ||
| + | WIFI_LED_RATE 50 | ||
| + | SUBNET_MASK 255.255.255.0 | ||
| + | MAC_PORT 0 | ||
| + | MEMSZ 0x01000000 | ||
| + | FLASHSZ 0x00800000 | ||
| + | MODETTY 0115200, | ||
| + | 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: | ||
| + | HWA_1 00: | ||
| + | BOOTCFG m: | ||
| + | |||
| + | 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. | ||
| + | |||
| + | === CONSOLE_STATE === | ||
| + | Setting this variable to " | ||
| + | |||
| + | 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 " | ||
| + | </ | ||
| + | |||
| + | 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. | ||
| + | |||
| + | Most, if not all, firmwares allow login on the serial port once they are booted. Some run "/ | ||
| + | |||
| + | === IPA, IPA_GATEWAY, | ||
| + | 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 " | ||
| + | |||
| + | === ProductID === | ||
| + | This is a four-character code which identifies the hardware. | ||
| + | |||
| + | 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 "/ | ||
| + | |||
| + | === IMAGE_A, CONFIG_A, IMAGE_B, CONFIG_B === | ||
| + | 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. | ||
| + | |||
| + | === BOOTCFG_A, BOOTCFG_B, BOOTCFG === | ||
| + | The firmware to be booted is defined by BOOTCFG. The variables BOOTCFG_A and BOOTCFG_B are apparently models for setting BOOTCFG. | ||
| + | |||
| + | BOOTCFG format: | ||
| + | |||
| + | < | ||
| + | |||
| + | * ' | ||
| + | |||
| + | * ‘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, | ||
| + | |||
| + | ===== Firmware ===== | ||
| + | ---- | ||
| + | ==== About firmwares supplied by Linksys ==== | ||
| + | All of the known firmwares have the following characteristics in common: | ||
| + | |||
| + | * Linux 2.4.17 kernel with MontaVista patches | ||
| + | * uClibc | ||
| + | * Busybox | ||
| + | |||
| + | === About source code === | ||
| + | * The source code supplied by Linksys is incomplete. It is missing the source for some of the utilities (" | ||
| + | * 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:// | ||
| + | * 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. | ||
| + | |||
| + | ==== Version characteristics ==== | ||
| + | === 1.00.XX === | ||
| + | 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, | ||
| + | * Voice configuration is badly broken | ||
| + | * The " | ||
| + | * 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 " | ||
| + | * 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 " | ||
| + | * Use server names, not IP addresses. | ||
| + | * If you can, log in using SSH or the serial console and make sure / | ||
| + | |||
| + | === 3.1.XX === | ||
| + | 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' | ||
| + | * 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. | ||
| + | |||
| + | === 3.1.22 === | ||
| + | * Ping hack works (enter **0.0.0.0 && | ||
| + | |||
| + | === 3.1.24-NA === | ||
| + | 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' | ||
| + | |||
| + | * The SIP parameters are no longer stored in the main configuration, | ||
| + | * The new ggsip program handles **all** voice related configuration. | ||
| + | * ggsip isn't easily fooled into giving up its secrets. | ||
| + | * 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 ' | ||
| + | * 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. | ||
| + | |||
| + | === 5.02.04 === | ||
| + | In late summer of 2007, Vonage began upgrading RTP300s to firmware version 5.02.04. | ||
| + | |||
| + | * Ping hack works (enter **0.0.0.0 && | ||
| + | |||
| + | ===== Default user accounts ===== | ||
| + | ---- | ||
| + | In the default configuration, | ||
| + | |||
| + | * admin | ||
| + | * This user has an access level of " | ||
| + | * user | ||
| + | * This user has an access level of " | ||
| + | * Admin | ||
| + | * This is the only user represented in "/ | ||
| + | |||
| + | ===== Access methods ===== | ||
| + | ---- | ||
| + | There are several ways to connect to the router in order to configure it. | ||
| + | |||
| + | ==== Web access ==== | ||
| + | The primary way to configure these devices is through a web interface. In the initial configuration, | ||
| + | |||
| + | ==== SSH access ==== | ||
| + | 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 "/ | ||
| + | |||
| + | 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. | ||
| + | |||
| + | ==== Serial console access ==== | ||
| + | This information has been moved to [[rtp300_and_wrtp54g|Linksys RTP300 and WRTP54G]]. | ||
| + | |||
| + | ===== Noteworthy programs and files in version 3.1.XX ===== | ||
| + | ---- | ||
| + | * / | ||
| + | * Starts "/ | ||
| + | * / | ||
| + | * System startup script. It starts " | ||
| + | * / | ||
| + | * The tiny HTTP server. | ||
| + | * / | ||
| + | * Appears to monitor the load average and the activity of some of the " | ||
| + | * / | ||
| + | * An HTTP proxy server which implements the " | ||
| + | * / | ||
| + | * GNU Wget (why not Busybox wget?). This is apparently used to download new firmwares. | ||
| + | * / | ||
| + | * Mystery program run from "/ | ||
| + | * / | ||
| + | * This daemon is launched from "/ | ||
| + | * It launches " | ||
| + | * This daemon participates in firmware flashing. | ||
| + | * / | ||
| + | * Converts old voice configuration to the 3.1.XX format. Run once per boot. | ||
| + | * / | ||
| + | * 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. | ||
| + | * 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 " | ||
| + | * It also refers to "/ | ||
| + | * Other messages suggest that this is the program which overwrites "/ | ||
| + | * Messages about login suggest a role in authentication. | ||
| + | * There are also many templates for commands to start networking. | ||
| + | * / | ||
| + | * May be related to " | ||
| + | * Saves and restores the current configuration to and from flash. | ||
| + | * / | ||
| + | * It appears likely that this program copies the default configuration from "/ | ||
| + | * When the system resets, the lightbox binary appears to run this command with an argument of FULLH. | ||
| + | * / | ||
| + | * This program appears to launch " | ||
| + | * / | ||
| + | * Dynamic DNS client. | ||
| + | * / | ||
| + | * Program through which most web pages are loaded. | ||
| + | * Implements server-side includes. | ||
| + | * Accepts POST requests to change the configuration. | ||
| + | * / | ||
| + | * Target of POST request which uploads a new firmware. | ||
| + | * Copies uploaded firmware to "/ | ||
| + | * Will accept firmware only from IP named in "/ | ||
| + | * / | ||
| + | * During a firmware upgrade, stores the IP address, a comma, and the access level (such as " | ||
| + | * / | ||
| + | * A named pipe to which "/ | ||
| + | * The firmware is read by " | ||
| + | * /var.tar | ||
| + | * This file is unpacked during boot. It creates the "/ | ||
| + | * / | ||
| + | * The purpose of this file is unknown. | ||
| + | * / | ||
| + | * Restarts the router. | ||
| + | * / | ||
| + | * The VOIP functions run inside this process. | ||
| + | * / | ||
| + | * This is some sort of diagnostic tool for the VOIP functions. | ||
| + | * When started, it presents a command-line interface. | ||
| + | |||
| + | ===== Firmware modification ===== | ||
| + | ---- | ||
| + | ==== Customized firmwares ==== | ||
| + | * 3.1.17 firmware with dropbear/ | ||
| + | * 3.1.27-ETSI firmware with dropbear/ | ||
| + | |||
| + | ==== Working with firmware files ==== | ||
| + | Here are programs which you can use for packing and unpacking firmware image files: | ||
| + | |||
| + | * Firmware modification Kit attachment: | ||
| + | * Squashfs tools with patches for LZMA compression | ||
| + | * David Chappell' | ||
| + | * Perl script to set ProductID and flag at byte 0x0B: attachment: | ||
| + | * Perl script to set CRC: attachment: | ||
| + | |||
| + | === Firmware modification kit === | ||
| + | **extractwrtp** extracts the firmware into the following files: | ||
| + | |||
| + | * **// | ||
| + | * **wrtp.img.kernel Kernel**//'//' | ||
| + | * **wrtp.img.7zip**//'//' | ||
| + | * **wrtp.img.uncompressed**//'//' | ||
| + | * **wrtp.img.kernel.bootstrap**//'//' | ||
| + | * **wrtp.img.kernel.padding**//'//' | ||
| + | **buildwrtp** builds the firmware by combining kernel partition and root partition | ||
| + | |||
| + | * -k -r -f -i -p -K -R | ||
| + | |||
| + | === Squashfs tools === | ||
| + | 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. | ||
| + | |||
| + | == Obtaining the squashfs tools == | ||
| + | A version of the Squashfs tools which can pack and unpack the firmware can be built from these files: | ||
| + | |||
| + | * LZMA library: attachment: | ||
| + | * Patch for the LZMA library: attachment: | ||
| + | * Patched Squashfs Tools 1.3r3: attachment: | ||
| + | |||
| + | Unfortunately, | ||
| + | |||
| + | Other instructions for building the Squashfs version 1.3r3 tools with LZMA support can be found at http:// | ||
| + | |||
| + | What appears to be the official site for the LZMA patches is at: http:// | ||
| + | |||
| + | == Using the Squashfs 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 | ||
| + | |||
| + | === David Chappell' | ||
| + | set_ProductID sets flags in the firmware image header. | ||
| + | |||
| + | 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). | ||
| + | |||
| + | ===== Firmware flashing ===== | ||
| + | ---- | ||
| + | There are several proven ways to write a new firmware into flash by: | ||
| + | * [[rtp300# | ||
| + | * [[rtp300# | ||
| + | * [[rtp300# | ||
| + | * [[rtp300# | ||
| + | * [[rtp300# | ||
| + | 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' | ||
| + | |||
| + | 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 " | ||
| + | |||
| + | ==== Using the web interface ==== | ||
| + | This method ranges from very easy to somewhat tricky depending on what firmware is currently installed. The basic procedure is as follows: | ||
| + | |||
| + | - Connect a computer to one of the yellow ports of the router | ||
| + | - Set the computer to gets its IP address by DHCP and make sure it does so before proceeding | ||
| + | - Connect to http:// | ||
| + | - Log in using the default username and passwoerd of " | ||
| + | - Click on the " | ||
| + | - Click on the " | ||
| + | - Log in as a user who is permitted to update the firmware. For NA firmwares the username should be " | ||
| + | - Plug the router into the Internet if it is not plugged in already. | ||
| + | - Got to Administration tab and choose Factory Defaults. Choose " | ||
| + | - Enter a username of " | ||
| + | - Give the router a minute to reboot and then return to step three. | ||
| + | - Click on Browse and choose a firmware image. (If you get an error page instead of the firmware upgrade page, enter http:// | ||
| + | - If the Internet cable is connected to the router, disconnect it. | ||
| + | - 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. | ||
| + | - If your router was last used with Vonage, log in again and go to Administration-> | ||
| + | - 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. | ||
| + | |||
| + | ==== Setting a firmware update URL on the provisioning page ==== | ||
| + | VOIP providers can configure these routers to periodically download a VOIP configuration file. This file contains VOIP settings and login credentials for the provider' | ||
| + | |||
| + | * 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 " | ||
| + | * Click on the " | ||
| + | * Enter the URL of the firmware file (HTTP is fine) in the " | ||
| + | * Press " | ||
| + | * 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. | ||
| + | |||
| + | ==== Using a firmware shell prompt (the hard way) ==== | ||
| + | You can use this procedure only if you have access to a shell running on the router. | ||
| + | |||
| + | 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: | ||
| + | * 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:// | ||
| + | # chmod 755 erase | ||
| + | # wget http:// | ||
| + | </ | ||
| + | |||
| + | * Erase and write the flash block for the inactive firmware copy: | ||
| + | * < | ||
| + | # / | ||
| + | </ | ||
| + | |||
| + | * Figure out which firmware area is currently active: | ||
| + | * < | ||
| + | # grep BOOTCFG / | ||
| + | </ | ||
| + | |||
| + | * At this point, one would expect to switch to the new firmware by using one of the following commands: | ||
| + | * < | ||
| + | # echo ' | ||
| + | # echo ' | ||
| + | </ | ||
| + | |||
| + | Unfortunately, | ||
| + | |||
| + | One could simply overwriting the active firmware (using "/ | ||
| + | |||
| + | ==== Using a firmware shell prompt (the easy way) ==== | ||
| + | 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. | ||
| + | |||
| + | < | ||
| + | # cd /var | ||
| + | # wget http:// | ||
| + | # dd if=rtp300-XXXXX.bin of=/ | ||
| + | </ | ||
| + | |||
| + | |||
| + | 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. | ||
| + | |||
| + | ==== Using the PSPBoot prompt ==== | ||
| + | In order to use this method, you must obtain or make a voltage converting cable for your router' | ||
| + | |||
| + | 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, | ||
| + | |||
| + | < | ||
| + | (psbl) setenv IPA 192.168.15.1 | ||
| + | (psbl) fmt IMAGE_A | ||
| + | FlashEraseBlock(b0020000, | ||
| + | ............................................................ | ||
| + | (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, | ||
| + | |||
| + | ===== Recovery ===== | ||
| + | ---- | ||
| + | ==== Hardware recovery ==== | ||
| + | === JTAG === | ||
| + | The information in this section has been moved to [[rtp300_and_wrtp54g|Linksys RTP300 and WRTP54G]]. | ||
| + | |||
| + | ==== Software recovery ==== | ||
| + | It is fairly easy to lock yourself out of the router by setting a bad passwoerd or installing a bad firmware. | ||
| + | |||
| + | === Unlocking tools === | ||
| + | The CYT Device Unlock tools were written in order to gain access to routers previously used with Vonage. | ||
| + | |||
| + | [[http:// | ||
| + | |||
| + | === Ping hack === | ||
| + | One can execute commands on the router with many versions of the firmware by going to Administration > Diagnostics, | ||
| + | |||
| + | | ||
| + | |||
| + | 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 " | ||
| + | |||
| + | The size of the text entry field for the IP address is small. | ||
| + | |||
| + | ===== OpenWrt ===== | ||
| + | * 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:// | ||
| + | * 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 [[inbox: | ||
| + | |||
| + | Another way is disabling jffs2: modify "/ | ||
| + | |||
| + | |||
| + | ===== Notes ===== | ||
| + | ==== Miscellaneous notes ==== | ||
| + | * CyberTAN is a subcontractor for Linksys, and its name appears in the router' | ||
| + | * The VoIP daemon, located "/ | ||
| + | * The telephony chip is the Microsemi Le88221, part of the VE880 series. Information, | ||
| + | * A channel on Freenode, [[irc:// | ||
| + | * There is information about Linux on AR7 at [[http:// | ||
| + | |||
| + | ==== External links ==== | ||
| + | * A number of the common [[http:// | ||
| + | * The Seattle Wireless site has a page about the Dlink DSLG604T which has similiar firmware: [[http:// | ||
| + | * Linux-MIPS port page about the AR7: [[http:// | ||
| + | * Some of the information on this page is derived from Linksysinfo.org: | ||
| + | |||
| + | ===== Tags ===== | ||
| + | {{tag> | ||