WRT54G (Revival)

Aus TippvomTibb
Zur Navigation springen Zur Suche springen

Allgemeines

Wie so oft kann ich mich von alter ausgedienter Hardware nicht trennen und ueberlege was man mit so einem Schaetzchen wie dem WRT54G(L V1.1) noch so tun kann. Die Nutzung als AP ist nicht mehr zeitgemaesz, aber als Client kann ich mir einen Einsatz noch gut vorstellen. Abgesehen von der Tatsache der ein Raspi doch etwas flinker ist, braucht man sich bei einem WRT54G keine Sorgen um sterbende SD-Karten machen. Und um ein paar kleine Routinen und Sensoren im Netzwerk einzubinden reicht die Performance der WRT54G in vielen Faellen.

Durch ein paar kleine Hardwareeingriffe kann man den WRT54G mit einem SD-Kartenleser, mit 2 seriellen Schnittstellen und mit einem USB-Port (V1.1) ausstatten. Ein Variante, die ich im Netz gefunden habe integriert in das Gehäuse noch einen Arduino-MikroPro und eröffnet so ein riesiges Feld an Moeglichkeiten.

DD-WRT vs. OpenWRT

Ich bin hin- und hergerissen. Mit OpenWRT waren die Erfahrungen (Kamikaze, White Russian) aber eher schlecht. Danach habe ich lange Zeit DD-WRT (v3.0-r36247 std (06/29/18) KERNEL 2.4.37) benutzt und es ging so. Aber die 6 APs (mittlerweile durch Ubiquiti-APs ersetzt) im Haus haben immer irgendwie gezickt.

Jetzt wo der AP-Modus keine Rolle mehr spielt und MMC, JFFS, CIFS, USB, TTYSXX und das Aufspielen neuer Software eine groeszere Rolle spielen, war ich mit DD-WRT irgendwie in einer gefuehlten Sackgasse. DD-WRT bietet zum Beispiel Untersutzung von ip (a und r aber nicht n) parallel zu ifconfig, route und arp, aber gibt z.B. keine Fehlermeldungen bei Befehlen wie mount, mkdir. Auch eine Hilfe sucht man vergebens. Da hilft oft nur ein Blick in den SourceCode was die Software tut, oder halt nicht wie gewohnt funktioniert.

Der Support (DD-WRT) fuer CIFS, MMC und JFFS sind zwar in der WebGUI angeboten, lassen sich auch konfigurieren, aber CIFS und MMC lieszen sich nicht mounten und die Unterstuetzung von JFFS war auf der Konsole nicht auffindbar.

Bei OpenWRT Backfire war es mir bisher nicht moeglich den WLAN-Treiber fuer den BCM4306 zum Laufen zu bringen. Um da einen Schritt vorwaerts zu machen muss ich erst eine paar zurueck machen.

Um schneller vergleichen zu koennen habe ich einen Router mit Backfire 10.03.1 und den anderen mit DD-WRT v3.0 36247 laufen.

Aber der Reihe nach.

Hardware

Um sich eine bessers Bild von den Zusammenhaengen zu machen hier nochmal die Hardware im Ueberblick.

CPU

Label: Broadcom BCM5352EKPBG

DD-WRT:~# cat /proc/cpuinfo 
system type             : Broadcom BCM5352 chip rev 0
processor               : 0
cpu model               : BCM3302 V0.8
BogoMIPS                : 199.47
wait instruction        : no
microsecond timers      : yes
tlb_entries             : 32
extra interrupt vector  : no
hardware watchpoint     : no
ASEs implemented        :
VCED exceptions         : not available
VCEI exceptions         : not available

Hinweise:

Die 199.47 BogoMIPS lassen auf 200 MHz und ein Verhältnis von 1 schlieszen.

Der CPU-Kern BCM3302 findet auch in den SoC BCM4712, BCM53xx und BCM5836 Verwendung (siehe dazu http://oleg.wl500g.info/sdram.html)

SDRAM

Label: Winbond W9412G6JH-5

Size: 2M x 4 BANKS * 16 BITS DDR SDRAM => 16 MebiByte

CELL-Array (Bank) Konfiguration: 4096 * 512 * 16 = 33.554.432 Bit mal 4 Baenke = 134.217.728 Bit = 16.777.216 Byte

Adressraum: 0x000000 - 0xFFFFFF

DD_WRT:~# nvram show|grep sdram
sdram_config=0x0062
sdram_refresh=0x0000
sdram_ncdl=0xfe0008
sdram_init=0x010b

DD-WRT:~# free
             total       used       free     shared    buffers     cached
Mem:         13004      11808       1196          0       1452       5180
-/+ buffers/cache:       5176       7828
Swap:            0          0          0

Flash

Label: MXIC (Macronix) MX29LV320EBTI-70G

Size: 4 MebiByte of 8 Bits each or 2 MebiBytes of 16

Adressierung: 0x000000 bis 0x3FFFFF

Sector Structure - 8K-Byte x 8 and 64K-Byte x 63• Extra 256-Byte sector for securit

DD-WRT:

Flash device: 0x400000 at 0x1c000000
bootloader size: 262144
Physically mapped flash: Filesystem type: squashfs, size=0x2c8102
partition size = 2930688
Creating 4 MTD partitions on "Physically mapped flash":
0x00000000-0x00040000 : "cfe"
0x00040000-0x003f0000 : "linux"
0x00124800-0x003f0000 : "rootfs"
mtd: partition "rootfs" doesn't start on an erase block boundary -- force read-only
0x003f0000-0x00400000 : "nvram"
sflash not supported on this router

Label cfe: 256 MebiByte (262.144 Byte) Bootloader Label linux: 3.776 MebiByte (3.866.624) darin enthalten (am Ende) 2.862 MebiByte (2.930.688) rootfs Label nvram: 64 KibiByte (65536) Configvariablen

Was man hier jetzt erkennen kann, dass das eigentliche Image (.bin,.trx) sich im MTD-Device mit dem Label linux (inkl. dem Device rootfs) befindet. Fuer das Image bleiben 4 MebiByte minus 256 MebiByte (CFE Bootloader) minus 64 KibiByte (nvram) uebrig. Die Squashfs-Size (s.o.) 0x2c8102 (2.916.610 Byte) ist vermutlich die belegte Groesze in der linux-Partition.


Mit dem Programm mtd (http://www.linux-mtd.infradead.org/archive/tech/faq.html memory technology device) werden die Partitionen gemountet/administriert/...

DD-WRT:~# ls -l /dev/mtd/ crw-rw-rw- 1 root root 90, 0 Jan 1 01:00 0 cr--r--r-- 1 root root 90, 1 Jan 1 01:00 0ro crw-rw-rw- 1 root root 90, 2 Jan 1 01:00 1 cr--r--r-- 1 root root 90, 3 Jan 1 01:00 1ro crw-rw-rw- 1 root root 90, 4 Jan 1 01:00 2 cr--r--r-- 1 root root 90, 5 Jan 1 01:00 2ro crw-rw-rw- 1 root root 90, 6 Jan 1 01:00 3 cr--r--r-- 1 root root 90, 7 Jan 1 01:00 3ro DD-WRT:~# ls -l /dev/mtdblock/ 0 1 2 3 DD-WRT:~# ls -l /dev/mtdblock/ brw-rw-rw- 1 root root 31, 0 Jan 1 01:00 0 brw-rw-rw- 1 root root 31, 1 Jan 1 01:00 1 brw-rw-rw- 1 root root 31, 2 Jan 1 01:00 2 brw-rw-rw- 1 root root 31, 3 Jan 1 01:00 3 DD-WRT:~# mtd Usage: mtd [<options> ...] <command> [<arguments> ...] <device> The device is in the format of mtdX (eg: mtd4) or its label. mtd recognizes these commands: unlock unlock the device resetbc reset bootcounter for WRT1900AC/WRT1200AC/WRT1900ACv2 erase erase all data on device write <imagefile>|- write <imagefile> (use - for stdin) to device Following options are available: -q quiet mode (once: no [w] on writing, twice: no status messages) -r reboot after successful command -f force write without trx checks -e <device> erase <device> before executing the command Example: To write linux.trx to mtd4 labeled as linux and reboot afterwards mtd -r write linux.trx linux