2010-09-17

Die Leiden des jungen DIR-300 ... oder das OpenWRT-Feuer am Hintern.

(Installation von Piratenfreifunk auf DIR-300: Timestamp-Version 'Backfire' vom 2010-09-14.)

Ich habe dann doch noch den Mut gefunden, den mit @Maltis Hilfe mühsam erflashten DIR-300 einfach nochmal neu anzusetzen ... mit der aktuellen Test-Version der OpenWRT-Firmware 'Backfire'. Was dabei alles so passiert, steht in dem folgenden 'Live'-Mitschnitt ...

... ich weiß natürlich, daß die momentane Version noch nicht fertig ist ... aber ... ich fang einfach mal an ...

Ist der DIR-300 bereits 'befreit' (suche im Netz nach RedBoot), einfach die Firmware draufbügeln (alle Voreinstellungen gehen verloren - hätte aber auch keinen Sinn ... zumindest sind bei mir die Konfigurationen der letzten regulären Version von Februar SO dermaßen anders, daß nach Wiederherstellung der alten Konfigurationsdaten im Router, daß 'luci'-Interface die kryptische Grätsche feilbietet ... also, frisch ans Werk:

$ sudo open-mesh-flash openwrt-atheros-root.squashfs openwrt-atheros-vmlinux.lzma

Klappte nach dem 'üblichen' Prozedere erstaunlich gut ... falls er nach angekündigtem Reboot noch ein- zweimal rebootet (habe nicht genau mitgezählt ;-), soll vorkommen. Ich glaube, das wird erstmal ein Standard-Config-Set ausgepackt.

Per Luci also auf eine frische interne Adresse (am Switch angeschlossen) auf 192.168.1.1 ... Nanu? Es fehlt die Piratenoptik? Na gut ... Ok. Erstmal weiter.

Direkt in den Konfigurationsassistenten - uh! Das sieht deutlich unübersichtlicher aus als früher. Die Original Standardwerte, die auch 'grob' vorhanden sind, werden leider nicht mehr vorweg angezeigt. Gut, wenn man einen Ausdruck der alten Werte parat hat.

Alles einzeln neu einrichten - die Angaben der Freifunk Community sind zwar noch vorhanden, aber irgendwie komplett useless, da alle anderen Felder trotzdem händisch eingegeben werden müssen?
  • Freifunk-Community: (auswählen)
  • Netzwerk einrichten: Häkchen (logo?)
  • Drahtloses Netzwerk "WIFI0": Häkchen (logo?)
  • Freifunk Kanal einrichten: 'default' (ich versuch's mal)
  • Mesh IP Adresse einrichten: 10.40.. . (Hallo? Preset?)
  • DHCP anbieten: Häkchen (von HAND? Früher automatisch!)
  • Mesh DHCP anbieten: 10.104.10.1/28 (Nanu? Manuelle Rotation?)
MOMENT MAL!

Ich muß hier mal kurz unterbrechen, mir kommt das alles SEHR unhandlich vor ... die bisherige Doku, die ja gerade erst frisch geschrieben wird, besagt folgendes:
"Wenn das Feld leer bleibt wird ein Netzwerk automatisch nach den vorgaben aus dem Feld "Freifunk Comunity" erstellt. Dieses Netzwerk wird dann Maskiert. Klient Geräte können dann keine Punkt zu Punkt Verbindungen aufbauen. Besser bei der IP Vergabe einen ganzen Block anmelden. Zum ausrechnen kann man einen Neztwerkrechner nehmen."
Liebe Programmierer, liebe Freifunk-Community - es geht nicht darum, den Leuten einen Stealth-Bomber in die Hand zu drücken und zu sagen, schau selber, wie das Ding fliegt!!! KISS! Keep It Simple, STUPID! ;-) Wenn also alle Felder leer bleiben MÜSSEN, damit die Standardwerte geladen werden - sowas schreckt doch nur ab. Die paar Kilobyte für eine kurze Erklärung sollten doch wohl drin sein, oder? Die Leute, die später, wenn sie gelernt haben wie OLSRD überhaupt funzt (auch ich habe es noch nicht ganz verstanden, btw.), selber anfangen mit Netzwerkmasken um sich zu schmeissen ... wenn sich da mal keine 'schwarzen Löcher' auftun *hust*.

ALSO NOCHMAL ...
  • Freifunk-Community: (auswählen)
  • Netzwerk einrichten: Häkchen (logo?)
  • Drahtloses Netzwerk "WIFI0": Häkchen (logo?)
  • Freifunk Kanal einrichten: 'default' (ich versuch's mal)
  • Mesh IP Adresse einrichten: 10.40.. . (Hallo? Preset? Für den ersten Teil?)
  • DHCP anbieten: Häkchen (na gut ...)
  • Mesh DHCP anbieten: (Das lasse ich mal LEER)
  • Drahtgebundenes Netzwerk "LAN": Häkchen (logo?)
  • Mesh IP Adresse anbieten: (Boah! Was zum ... ? Hallo? Keine interne IP-Rotation? Testhalber mal LEER - das ging mal automatisch)
  • DHCP anbieten: Häkchen (wie immer eigentlich ... grmpf ...)
  • Mesh DHCP anbieten: (wieder lasse ich das mal LEER)
(Dieses kleine sinnlose Fragezeichen regt mich auf ... sieht aus wie ein Mouse-Over oder 'Klick-hier-für-Info-Du-Depp', kann aber nix. Also weiter ...)
  • Drahtgebundenes Netzwerk "WAN": KEIN Häkchen (Äh? Bitte? Sonst Uplink von Hand oder wie?)
Mal ausprobieren, wenn man es NICHT konfiguriert ... der soll sich doch gefälligst die Adresse selber ziehen ... der Punkt erscheint mir mehr als schleierhaft - vor allem, wenn bei einer Aktivierung steht "DHCP anbieten" - oha ...
  • OLSR einrichten: Häkchen (WAS DENN AUCH SONST, bitte)
  • Latitude: Zahlen (Länge? Breite? Was war nochmal was?)
  • Longitude: Zahlen (Berlin ... der Nabel der Welt ...)
  • Geokoordinaten mit OpenStreetMap ermitteln: (ohne Zugang? Ach, was soll's - wie immer ignoriert)
  • Eigenen Internetzugang freigeben: Häkchen (Ick trau mir ... wie immer)
Geile Anmerkung in der bisherigen Doku dazu:
"Wenn eine Verbindung zum Internet über den wan Anschluss festgestellt werden kann kündigt der olsr einen HNA (Host and Network Association), also Internet an"
Steht irgendwie etwas diametral zum obigen Punkt "Drahtgebundenes Netzwerk 'WAN'", wo man aus Versehen als Anfänger evtl. auch mal selber DHCP drauf ankündigen könnte ...
  • WAN-Zugriff auf Gateway beschränken: Häkchen (keine Ahnung - steht auch nicht in der Doku, was dann passiert - muß ich mal nachschauen, wenn's läuft)
  • Heartbeat aktivieren: KEIN Häkchen (wie 'anonym' die Statistiken sind, kann man sich irgendwo(?) im Netz anschauen - es ist aber KEINE Piratenseite, soviel weiß ich noch - die alte Testversion läuft evtl. noch hier: http://heartbeat.piratenfreifunk.de/)
Und los ...
"Ungültige Eingabe: Bitte die Formularfelder auf Fehler prüfen."
Und alles ist Blanko ... ah OK! Wenn man das Häkchen bei "Netzwerk einrichten" wieder setzt, sind die alten Felder noch so beschrieben, bzw. leer wie vorher. Spannend ist übrigens rechts oben der Zähler mit den noch nicht gespeicherten Änderungen (164 Stück), obwohl die Eingaben ja falsch sein sollen?

Ich vermute mal, daß das mit den leeren Feldern nicht klappt - vielleicht MUSS man sich eine manuelle Adresse für das "LAN" aus den Fingern saugen, wenn es automatisch maskiert werden soll, oder so ... das ging in der alten Version automatisch, so mit Semi-Zufallszahlen, reichte vollkommen aus.
  • Mesh IP Adresse einrichten: 10.104.254.1 (so ganz klassisch mit 'ner 1 hinten)
"Ungültige Eingabe: Bitte die Formularfelder auf Fehler prüfen."
HUNDERTTAUSEND HÖLLENHUNDE!

  • WAN-Zugriff auf Gateway beschränken: KEIN Häkchen (einfach mal so ...)
REBOOT

Äh, ne. is klar ... wenn ich nicht den WAN-Zugriff auf ALLES freigebe, ist das ungültig, oder wie? Na ja, mal schauen, wie es weitergeht ...

Die WLAN-Lampe fängt jetzt schon mal an zu blinken ... ein gutes Zeichen. Ich bekomme aber keine neue Adresse per DHCP? Moment ... was hatte ich intern für LAN nochmal definiert?
"Mesh IP Adresse einrichten: 10.104.254.1 (so ganz klassisch mit 'ner 1 hinten)"
Ein Blick auf meinen Monitor erklärt mir ... der Router meldet sich per DHCP-Anfrage mit "192.168.1.1" und Du gehörst da auch irgendwo mit rein. Warum also überhaupt die interne Adresse für's LAN eingeben?!?
Und wieso stelle ich in meinem eigenen Blog fragen? Ach ja!

FAZIT an die Programmierer:
  • Denkt bitte an normale Menschen, die den Freifunk-Gedanken unterstützen möchten.
  • Einfache, kurze Erklärungen im Interface können hilfreich sein.
  • Was keine Hilfe ist, hat kein Fragezeichen verdient.
  • Baut bitte die Essentials wieder ein.
  • Passt bitte diese Geokoordinatensache mal an (Kontakt/Assistent) Breite, Länge, Longitude, Latitude, leere Felder, voreingestellte Felder, Kraut, Rüben, Berlin.
  • Fügt bitte das Feld "Hostname" wieder ein - das ist verloren gegangen.
  • Die Time-Server fehlen noch
  • Wofür muß man erst den Assistenten umkonfigurieren, wenn er eigentlich alles enthält? Oder auch nicht. Denn wenn ich die Freifunkdaten erst eingeben muß, aber obendrein auch noch die Community, obwohl die im Preset stehen - das schließt sich doch gegenseitig aus.
  • Unter 'Netzwerk/Schnittstellen' steht 'wireless0' unter 'Netzwerk/Drahtlos' steht 'wifi0' - das zieht sich durch alles durch (also auch bei DHCP ...)
  • Das 'LAN'-Interface wird nicht mehr 'gebridged' - steht trotz anderer Definition der LAN-IP im eigenen '.1.1'er Netz.
  • In den 'WIFI0'-Voreinstellungen steht "Scan-Anforderungen nicht beantworten' und ist aktiviert. Unter anderem haben Atheros-Clients öfters Probleme, sich Ad-Hoc zu verbinden und brauchen den Scan: "Scan for ad-hoc cells in range (necessary for some drivers to trigger IBSS scanning)" http://wiki.debian.org/WiFi/AdHoc
Nach Deaktivierung dieses Hakens und anschließendem Reboot ... ist der Router platt und startet andauernd neu, Korrektur - er startet 3 Mal neu ... jetzt scheint er sich wieder gefangen zu haben.

Ich glaube, daß reicht erstmal ... hoffentlich fühlt sich jetzt keiner auf die Füße getreten.

P.S. Ach ja, der Router läuft natürlich.

2010-09-08

A long Journey: OpenWRT & Piratenfreifunk on a DIR-300.

... Install everything ... harhar ... that was easy ... NOT!

So this time, I'll post the most helpful links at first ... the ultimate links that helped me:

The regular link that tried to show the way:
The very short summary:
  • Download the needed images from http://firmware.piratenfreifunk.de/piratenfreifunk/latest/atheros/
  • Install the boot loader.
  • Install the firmware.
First Part - the Installation of a new RedBoot-Loader.

I tried to install the RedBoot-Loader ... but the well known script 'dir300-flash' did not work out under Debian Lenny. It did, well ... nothing. So I searched through the net until I found the 'Mini-Flashing-Guide' which pushed me into the right direction. Combined with the source from the 'dir300-flash' script I did the following:

Connect the ethernet cable to the WAN-interface (Internet, muahaha), configure your local IP address to "192.168.20.80" and open a telnet console (I read often not to turn on the router using a 30/30 reset game before starting telnet ... I did not care, it worked):
  • cabling
  • prepare a console
  • prepare a 30/30 boot sequence incl. power on
  • configure your local device to 192.168.20.80
  • and ...
$ sudo telnet 192.168.20.81 9000
Trying 192.168.20.81...
Connected to 192.168.20.81.
Escape character is '^]'.
version
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.

Version: "RedBoot v2.3"
RAM: 0x80000000-0x80800000, [0x80036350-0x807ed000] available
FLASH: 0xbfc00000 - 0xbfff0000, 64 blocks of 0x00010000 bytes each.
RedBoot> load ap61.ram
Using default protocol (TFTP)
Can't load 'ap61.ram': file not found
RedBoot>
*sigh* - find the path your TFTP-Server uses - mine was configured using /etc/inetd.conf - within the path the installer 'dir300-flash' already had made symbolic links which my Debian system denies! So I copied all files directly into the TFTP-Folder ...
RedBoot> load ap61.ram
Using default protocol (TFTP)
Entry point: 0x800410bc, address range: 0x80041000-0x800680d8
RedBoot> go
Change your local IP address to "192.168.1.2" and open a new telnet console:
$ sudo telnet 192.168.1.1 9000
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
DD-WRT> load -r -b %{FREEMEMLO} ap61.rom
Using default protocol (TFTP)
TFTP timed out 1/15
Can't load 'ap61.rom': operation timed out
DD-WRT>
And again a problem with the TFTP-server ... but this time from within the redboot-client - you have to redefine the server address within the client:
DD-WRT> ip_address -h 192.168.1.2
IP: 192.168.1.1/255.255.255.0, Gateway: 0.0.0.0
Default server: 192.168.1.2
DD-WRT> load -r -b %{FREEMEMLO} ap61.rom
Using default protocol (TFTP)
Raw file loaded 0x80080000-0x800a8717, assumed entry at 0x80080000
DD-WRT>
Now for the 'toughest' part ... configure by console - you will have to create a boot-script - while doing this by hand, you will stumble upon a missing possibility to stop the edition after you have entered ">> exec" - just hit ENTER when you see the double prompt ">>":
DD-WRT> fconfig -d
Run script at boot: false ? true
Boot script:
Enter script, terminate with empty line
>> fis load -l vmlinux.bin.l7
>> exec
>>
Boot script timeout (1000ms resolution): 0 ? 5
Use BOOTP for network configuration: true ? false
Gateway IP address: ? 192.168.20.80
Local IP address: ? 192.168.20.81
Local IP address mask: ? 255.255.255.0
Default server IP address: ? 192.168.20.80
Console baud rate: 9600 ? 9600
GDB connection port: 9000 ? 9000
Force console for special debug messages: false ? false
Network debug at boot time: false ? false
Update RedBoot non-volatile configuration - continue (y/n)? y
... Erase from 0xbffe0000-0xbfff0000: .
... Program from 0x80ff0000-0x81000000 at 0xbffe0000: .
DD-WRT>
Already some sweating hands? Here we go:
DD-WRT> fis init
About to initialize [format] FLASH image system - continue (y/n)? y
*** Initialize FLASH Image System
... Erase from 0xbffe0000-0xbfff0000: .
... Program from 0x80ff0000-0x81000000 at 0xbffe0000: .
DD-WRT>
Calm down ... and now ...:
DD-WRT> fis create -l 0x30000 -e 0xbfc00000 RedBoot
An image named 'RedBoot' exists - continue (y/n)? y
... Erase from 0xbfc00000-0xbfc30000: ...
... Program from 0x80080000-0x800a8718 at 0xbfc00000: ...
... Erase from 0xbffe0000-0xbfff0000: .
... Program from 0x80ff0000-0x81000000 at 0xbffe0000: .
DD-WRT>
If it really worked out to install a new bootloader ... we'll see:
DD-WRT> reset
Second Part - the Installation of the OpenWRT Firmware (at last?).

As I thought it was enough of console work ... well ... what has been written by the developers of 'open-mesh-flash'?
"List of known to work redboot devices: [...] Dlink, DIR-300 (AFTER INSTALLING A REFLASH-ENABLED REDBOOT)" - screaming done by me ...
Let's try to do it the 'Homers way' - to brick or not to brick:
$ sudo ./open-mesh-flash eth0 openwrt-atheros-root.squashfs openwrt-atheros-vmlinux.lzma
Reading rootfs file openwrt-atheros-root.squashfs with 2752512 bytes ...
Reading kernel file openwrt-atheros-vmlinux.lzma with 786432 bytes ...
Non arp received. Make sure, the device is connected directly!
Peer MAC: 00:22:b0:4b:cf:82
Peer IP : 192.168.20.81
Your MAC: 00:ba:be:ca:ff:ee
Your IP : 192.168.20.0
Redboot enabled device detected - using redboot to flash
WARNING: UNPLUGGING POWER OR ETHERNET DURING THIS PROCESS WILL LIKELY DAMAGE YOUR DEVICE AND THIS WILL NOT BE COVERED BY WARRANTY!
A flash size of 4 MB was detected.
rootfs(0x002c0000) + kernel(0x000e0000) + nvram(0x00000000) sums up to 0x003a0000 bytes
Setting IP address...
Loading rootfs...
Sending rootfs, 5376 blocks...
Initializing partitions...
Flashing rootfs...
Loading kernel...
Sending kernel, 1536 blocks...
Flashing kernel...
Setting boot_script_data...
Done. Restarting device...
YES!!! It boots and runs ... and connects perfectly to my existing OpenWrt-system.

UPDATE: But why does the router always forgets its configuration w/o electricity?!? A reset works ... but a preconfiguration is useless ... replugged and again a 'fresh' system? *facepalm*

UPDATE 2: Erm ... and do NOT try out the OpenWrt-'backfire' versions ... looks like i stumbled into this pit. Needed several tries to reflash and older version - last exit was a 10/10-Reset I found on the DD-WRT board.

UPDATE 3: okokok ... looks like I picked a 'not-so-good' version of the Partition table ... that's the reason why the router suffers his Amnesia ... @maltis gave me his DIR-300 partition scheme
6 RedBoot partitions found on MTD device spiflash
Creating 6 MTD partitions on "spiflash":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x000f0000 : "vmlinux.bin.l7"
0x000f0000-0x003e0000 : "rootfs"
mtd: partition "rootfs" set to be root filesystem
mtd: partition "rootfs_data" created automatically, ofs=370000, len=70000
0x00370000-0x003e0000 : "rootfs_data"
0x003e0000-0x003ef000 : "FIS directory"
0x003ef000-0x003f0000 : "RedBoot config"
0x003f0000-0x00400000 : "boardconfig"