• erase 0xbf020000 +7c0000
• tftpboot 0×80000000 openwrt-ar71xx-tl-wr741nd-v1-squashfs-factory.bin
• cp.b 0×80000000 0x9f020000 0x3c0000

Installed following packages:

• dnsmasq
• hostapd
• bwm-ng

Wrote a script and modified the example hostapd.conf from /usr/share/doc/hostapd/examples.

Put both in ~/bin, which is in my $PATH.

It disables WLAN in the Network Manager via dbus command (thanks to joentjuh for cheat), starts hostapd, starts dnsmasq, starts bandwith monitor and restores most of it after bmw ended.

Usually, i brick my nanos with experimental firmware images and have to climb ….

So i want a tftp-boot_wait redbook on my roof without climbing up there. I have to flash it from my livingroom.

step1: brick my dir-300

Before flashing my redboot from inside openwrt on my nano, i prefer to test with cheap hardware, in this case a dir-300 from d-link, which is a pain in the ass anyway, as i need the terrible dir300flash util or telnet into redboot. A little bit of research showed up, that the redboot on openwrt is NOT writeprotected by the kernel. So after copying dir300.rom to /tmp of my dir, a simple

mtd write /tmp/dir300.rom RedBoot

wrote the image into the bootblock. After a reboot, the dir was waiting for tftp on 192.168.1.1.

The next step was the nanostation, in this case i used ubnt_ns2.rom and did everything like before.

It worked and now i got a new firmware on my rooftop-nano and will hopefully never go up there for a firmware update.

The Problem: whenever i brick a nanostation or bullet, i have to climb to the roof and press the resetbutton to reflash the device. During cold and windy evenings, it is an experience you do not want to repeat.

An old Linksys WRT-54gl has a nvram variable called boot_wait, if it is enabled, you have 5 seconds to send a firmware image via tftp, so you just powerccle your device and send a new firmware after bricking it. As most devices on the roof are powered over ethernet, you can do this without climbing on the roof.

So nbd patched a Redboot to do the same and i will decribe how to flash the bootloader via the serial console.

First, get your tftpserver up and running, serving the files from redboot-ar231x.tar or the openwrt-mirror. Test your tftpserver. I have my tftpserver running on 192.168.1.34, feel free to change the address and chage it in the example.

Connect your serial console, 9600 baud, i usually use screen as a terminal programm.

Plug your device in and press ctrl-c as soon as the message “== Executing boot script in 1.000 seconds – enter ^C to abort” comes.

now, issue following commands:

After this, use “reset” or powercycle the device and it should expect a new firmwareimage via tftp. Use the openwrt combined image.

• babel did not survive the hack-center.
• ahcp did survive.
• measurement needs to be improved

That does not sound much, but i think it’s valuable information as we can now concentrate on some things and forget the other.

Openimp did not run good, it had a memory leak we got not fixed during 26c3, so the router kept rebooting after a few minutes.
Babel also hat real trouble, it ate up a lot of cpu and memory, it felt like olsr 3 years ago.
A few harddrives did not survive the heat of colo, so a part of the topology data are maybe lost.
Firmware building and development did work quite good, but could be better, that was mainly my verpeilung, there is room for improvement.

I will continiue the tests in my local mesh neighbourhood without babel and without ipv4 based olsr, so expect more firmware builds soon.

Das währe ja die perfekte Gelegenheit, in Aachen gleich mit Piratenfreifunk zu beginnen und das Stadtweite Wlan gleich Freifunk kompatibel nach pico peering agreement zu gestalten.

Nun Herr Pirat, zeigen sie Flagge für freie Bürgerdatennetze.

• Ein Repository auf github
• Eine vorzeigbare Demo
• und erste installierbare Firmwareversionen.

Kleine vorstellung soll am Di, den 25.8. 09 im Breipott in der Skalitzer Strasse (berlin) sein.

Update: warscheinlich um 20:00 Uhr

Schade, bisher hatten die hamburger das nicht nötig und waren in der lage vernünftig zu wirtschaften.

Ansonsten bisher alles sehr entspannt, die ersten freifunker und OpenWrtler sind angekommen und wir richten uns im freifunk/wireless raum ein.

FAIL!!11!!elf!

Epic fail!

Das Netzwerk war selbst in seinen besten Momenten massiv schlechter als das auf der letzten re:publica. Der für diese Veranstaltung massiv unterdemensionierte 16MBit DSL Anschluss nie ausgelastet.

Die Probleme, welche zu diesem massiven Versagen der Infrastruktur führten, lassen sich grob in 4 bereiche einteilen:

• management/teamwork/koordination
• hardware
• software
• mangelnde Fähigkeiten einzelner.

Die leckeren Details, was passiert ist, was wirklich passiert ist und vielleicht sogar die Wahrheit werden wir in den nächsten tagen häppchenweise nachreichen.

Unser grösstes Versäumnis war die mangelhafte, bis nicht vorhande Aussenkommunikation.

Weiterhin möchte ich betonen, das das Team der re:publica keine möglichkeit hatte, diese Katastrophe vorherzusehen. Das Netz auf den vorherigen Veranstaltungen lief sehr gut und sie hatten keinen Grund an uns zu zweifeln. Dem re:publica Team gegenüber wurde immer versichert, das es sich um lösbare Probleme handelt, welche gleich gefixed sind.

Mehr die  nächsten tage, gruß, nbd, joti, alx.