maschinenraum

Wie ihr vielleicht wisst, hat der maschinenraum seit 2013 einen Mate-Automaten, auch bekannt als Auto-Mate.

Neuer Mate-Automat

Leider war besagter Automat jetzt mehrere Jahre am Stück defekt - der antike mechanische Münzprüfer hatte endgültig versagt und niemand hatte Lust darauf dieses Horrorkonstrukt aus Plättchen, Federn, Klappen und Gewichten noch mal zu reparieren. Nach der Anschaffung war das Teil recht dillettantisch von DM auf € umgebaut worden, schon davor hatte jemand dran rumgepfuscht, und so richtig hat das Ding nie funktioniert - immer mal haben sich Münzen veklemmt, falsche Münzen wurden angenommen (an sich hat das Ding sowieso nur sehr exakt 1x 1€ und 1x 50 Cent zählen können), etc.. Irgendwann war er einfach komplett verklemmt und die Luft war bei allen Beteiligten raus.

Letzten Herbst haben wir uns dann der Sache endlich mal angenommen. Grober Plan: Das ganze Ding umbauen auf einen elektrischen Münzprüfer (und folglich auch elektrische Entriegelung) + Arduino.
Mittlerweile läuft der Auto-Mate wieder gut und zuverlässig, das hier soll eine kleine Dokumentation der vorgenommenen Arbeiten sein.

Ganz am Anfang stand der Ausbau der Fächer-Mechanik und des Münzprüfer-Mechanismus. Also raus damit!

Die ganze Münz-Mechanik wurde dann erst mal abgebaut, bis wir das absolut Minimum übrig hatte: ein kleiner Riegel mit einer Zugstange. Wenn die Zugstange gezogen ist, gibt der Riegel die Mechanik frei und es kann ein Fach geöffnet werden.
Und wo schon mal alles so schön da lag, haben wir auch gleich mal die komplette Fächer-Mechanik zerlegt, gesäubert, neu gefettet und teilweise repariert (zwei Klappen-Scharniere waren defekt).

Zur Betätigung der Zugstange haben wir uns für einen einfachen Zugmagneten entschieden. Sein bisheriges Leben verbrachte er in einem alten Videorekorder - er war zwar nicht sehr stark, aber auf jeden Fall ausreichend.
Dann brauchten wir noch irgendeine Rückmeldung - der Automat muss erkennen, wenn ein Fach geöffnet wird, damit er den Magneten "loslassen" kann. Da fand sich eine perfekt passende Gabellichtschranke aus einem alten Drucker, die wir unten an der Mechanik anbrachten.
Läuft!

Jetzt brauchten wir noch einen Münzprüfer. Erste Versuche erfolgten mit einem alten "wh emp 800" aus einem Spielautomaten - der hatte sogar einen eingebauten Wechsler, wäre ein nettes Extra.
Leider sind wir absolut gescheitert. Das Teil hat keine Dokumentation, einen proprietären Bus, und vielleicht war's auch (zusätzlich) einfach defekt. Wir haben ihm niemals einen Pieps entlocken können.

Plan B: Billig(st)er Münzprüfer aus Hongkong. Die mitgelieferte Dokumentation ließ auch etwas zu wünschen übrig, aber wir haben es hinbekommen.

Der wurde dann noch angepasst (u.a. einiges abgesägt), damit wir den alten Geldeinwurf + Rückgabe (da kommen Münzen raus, die nicht akzeptiert werden) beibehalten konnten.
Die Münzführung erfolgte provisorisch über zusammengeklebte Papp-Röhren - wie alle Provisorien sind die wahrscheinlich in 10 Jahren noch da.

Zum Schluss wurden noch ein paar LEDs zurechtgefeilt und in den ungenutzten Geldeinwurf installiert (ursprünglich gab es zwei mechanische Zähler: einer für große Münzen (1DM, 2DM), einer für kleine Münzen (10Pf., 50Pf.)): rot für Standby, gelb für Münze erkannt, grün für entriegelt.

Zum Debugging wurde dann die "iMate" wieder in Betrieb genommen - die war auch mindestens so lange wie der Automat defekt. Die iMate ist ein Club-Mate-Getränkekasten, der mal zu einem PC umgebaut wurde (Pentium 2 oder so? Das Ding dürfte jetzt schon fast 10 Jahre hier rumstehen). Stand früher auf dem Automaten und zeigte den #maschinenraum IRC-Channel. Steht jetzt wieder oben auf dem Automaten und kann - zusätzlich zum IRC - live die seriellen Daten vom Arduino anzeigen.

Ein paar Bugs tauchen auch schon auf:
- einmal gegen den Automaten treten = 10 Cent! -> nachdem wir den Automaten mit GND von Arduino verbunden haben war das weg.
- immer, wenn der Kompressor vom Kühlaggregat anspringt, zählt der Automat 30 Cent. Wenn der Kompressor ausgeht, zählt er nochmal 20 Cent. -> ein Netzfilter (aus einer Mikrowelle vom Sperrmüll) schaffte da Abhilfe - ab Werk hatte der Automat gar nix.
- der Lüftermotor war immer wieder mal höllisch laut und hat gerattert -> Kühlaggregat ausgebaut, Ursache gefunden (eine abgerissene Schraube, die mal jemand mit Kleber wieder angebracht hatte), Ursache beseitigt (mit einem Bügel über ein anderes Schraubenloch wieder befestigt), noch gleich die echt experimentelle (und garantiert nicht VDE-konforme Verkabelung) in Ordnung gebracht, Ruhe ist (nicht so richtig, aber jetzt ist das Lautstärke-Level normal).
- der Münzprüfer zählte nur unzuverlässig 20Cent, meistens nahm er sie nicht an -> noch mal neu angelernt, diesmal im Automaten, also mit den extra 5mm Weg durch die Blende -> alles gut.

Code und (hoffentlich auch bald Schaltplan) gibt's auf unserem gitlab: https://gitlab.bau-ha.us/maschinenraum/automate

Hallo an alle!

Pünktlich zum sich nährenden Jahresende und zum Nikolaus, wollen wir euch am 06.12.2017 ab 16:00 ganz herzlich einladen um den Maschinenraum und die Initiativmitglieder kennenzulernen
Kommt einfach vorbei und löchert uns mit Fragen oder quatscht mit uns über eure Ideen und Projekte, die wir eventuell zusammen umsetzen können. Eventuell kann sich der ein oder andere sogar vorstellen, die Initiativarbeit im ehrenamtlichen Rahmen fortzuführen....

Der 06.12. hält aber noch mehr für euch bereit! Außer unsererem "Tag der offenen Tür", ist in der M18 auch noch die Initiativen-Weihnachtsfeier, was euch die Möglichkeit gibt mit den anderen Initiativen des StuKo ein bisschen in weihnachtliche Stimmung zu kommen.

Noch einmal zum Mitschreiben:
WAS? --> Maschinenraum Kennenlerntreffen
Und WO? --> In der M18 (Haus der Studierenden Marienstraße 18)
Aber ab WANN denn? --> ab 16:00!
Und muss ich was wissen oder mitbringen? --> Nein, gute Laune und ein bisschen Interesse. Wenn ihr Lust habt schaut euch doch einfach unseren Blog an um ein groben Eindruck zu bekommen, was unter anderem im Maschinenraum passiert.

Danke für eine wunderbare Party.

Hier sind die Photos die Twitter nicht wollte ;-)

Achtung die Seite ist fast 19MB groß!

» Read the rest of this entry «

..weiter geht's. Teil I war ein Rundumschlag mit allgemeinen Geplänkel und jetzt wird es konkreter.

Wir schauen uns an wie die Firmware an. Ziel soll sein selbst etwas an der Firmware ändern zu können. Wenn man da keinen Bock drauf hat, kann man auch direkt Meshkit benutzen und bekommt eine fertige Firmware für seinen Router!

Los geht's!

ein paar Grundlagen

...ist vielleicht das falsche Wort dafür, aber es gibt ein paar Ideen und Konzepte die immer wieder auftauchen und in etwa zu wissen womit man da zu tun hat macht alles sehr viel einfacher.

• Linux - Da wir durchgehend Tools auf Linux nutzen, die Firmware auf Linux läuft und der ganze Code auf Linux aufbaut sind ein paar Kenntnisse nötig. Das minimale Level an Sachen, die man wissen muss gibt es in als Tutorial in 30 Lektionen bei "Learn Linux The Hard Way". Der Name ist etwas unglücklich, so "hard" ist es wirklich nicht. Es handelt sich nur um eine Einführung in wesentliche Konzepte, die einem immer und immer wieder und überall begegnen.
• TCP/IP - Was ist eine IP-Adresse und was ist DNS und solche Dinge.. muss man nicht alles wissen, aber es ist nützlich eine Idee davon zu haben. Ist ja schließlich ein Netzwerk. Es gibt viele Tutorials im Netz dazu. Hier ist ein recht ausführliches.
• Shell-Scripting - Ein großer Teil von OpenWRT und kalua besteht aus Shell-Scripten und diese sind teilweise ziemlich kryptisch. Hier ist ein ausführliches Tutorial. Tools wie sed, awk und Reguläre Ausdrücke sind nützlich und tauchen oft im Quellcode auf. Da das alles noch nicht kompliziert genug zu sein scheint, ist es so, dass die Shell auf OpenWRT eine ash von busybox ist. Diese ist nur zu POSIX kompatibel (kann aber auch ein paar Sachen darüber hinaus und manches auch nicht :/). Da die meisten Tutorials für die Bash-Shell geschrieben sind laufen Beispiele oft nicht mit der ash auf OpenWRT. Hier gibt es einen Überlick über die Unterschiede. Beim Googlen hilft es explizit nach "Posix Shell" zu suchen.
• make - das OpenWRT-Buildsystem nutzt Makefiles, ebenso wird der  Linux-Kernel damit compiliert und fast alle OpenWRT-Pakete. Make ist mit ein paar Beispielen am besten erklärt. Das OpenWRT-Buildsystem ist eher schwarze Magie, aber wenn man sadistisch veranlagt ist, dann kann man hier anfangen in die Abgründe hinabzusteigen.
• git - Eine verteilte Versionsverwaltung, die hier noch keine größere Rolle spielt, aber die Sourcen für die diversen Projekte sind auf github zu finden oder in eigenen git-Repositories. Es ist nützlich ein wenig mit den üblichen Begriffen vertraut zu sein um sich orientieren zu können. Auf git-scm.com gibt es Tutorials... hier brauchen wir erstmal nur git checkout und eine Idee davon was ein commit ist und was branches sind.

..und das wichtigste:

Learn to Read the Source, Luke

echt jetzt! Das Problem ist, dass es kaum oder keine Dokumentation gibt. Dieser Blogpost ist auch nur aus dem Frust heraus entstanden keine Informationen über die Funktionsweise der Weimarnetz-Firmware zu haben. Im Zweifel hilft es nur den Quellcode zu lesen.

Okay - jetzt geht es aber los:

Das Buildsystem (besser: die Buildsysteme)

Ziel ist es für einen Router ein Image mit der Weimarnetz-Firmware aus dem Quellcode zu bauen. Dafür folgen wir erstmal der Anleitung aus dem git-Repository vom Weimarnetz:

# login as non-root user
export REPONAME="weimarnetz"
export REPOURL="git://github.com/weimarnetz/weimarnetz.git"

git clone $REPOURL
mkdir myrelease; cd myrelease

DO="../$REPONAME/openwrt-build/build_release.sh"

# choose your router-model and build, for example:
# build all ar71xx based hardware images
# with barrier breaker 14.07 final
$DO "HARDWARE.ar71xx" ffweimar_standard \ 
     patch:901-minstrel-try-all-rates.patch \
     patch:luci-remove-freifunk-firewall.patch \
     patch:openwrt-remove-ppp-firewall-from-deps.patch \
     patch:openwrt-remove-wpad-mini-from-deps.patch \
     ffweimar_luci_standard hostapd vtunnoZlibnoSSL \ 
     i18n_german https owm shrink tc use_bb1407

Alles klar? Hier auch nicht..

export VAR= setzt eine Umgebungsvariable in der Shell - diese Variablen werden später vom Script build_release.sh genutzt um das Repository zu clonen.

Das Build-Script selbst wird noch in eine 2. Umgebungsvariable $DO gepackt und in der letzten Zeile wird das Buildscript mit vielen mysteriösen Optionen ausgeführt zu denen wir gleich noch kommen...

Ein Blick in das Build-Script erklärt vielleicht die langatmigen Ausführungen zu Shell-Scripten und Quellcode lesen am Anfang des Artikels: build-release.sh. Es stellt sich heraus, dass in diesem Script im wesentlichen nur die Repositories gecloned werden und einige Vorbereitende Konfigurationen unternommen werden und die eigentliche Magic in einem 2. Script passiert. Dieses Script heißt mybuild.sh und es wird in build-release.sh in Zeile 197 mit dem Argument make aufgerufen sowie - und das passiert automatisch den Argumenten, die wir weiter oben schon build_release.sh mitgegeben haben.

In mybuild.sh werden viele Funktionen definiert aber in Zeile 44 wird es interessant:

case "$ACTION" in
    "")
        show_help
        exit 1
    ;;
    make)
        ACTION="mymake"
    ;;
esac

Jetzt wird die Funktion mymake() aufgerufen... hier die nach besten unwissen kommentierte Version:

mymake()
{
        # Parameter der Funktion werden
        # in die Variable $option gepackt
	local option="$1" # e.g. V=99
        # Zähle die CPU Kerne 
        # und packe sie in die Variable $cpu_count
	local cpu_count="$( grep -c ^processor /proc/cpuinfo )"
        # lege ein paar Variablen an
	local t1 t2 date1 date2 hardware
	local filelist file

        # [... ein paar Zeilen gekürzt]

        # lösche alte Firmware Dateien
	filelist="$( get_firmware_filenames )"

	for file in $filelist; do {
		[ -e "bin/$( get_arch )/$file" ] &&
                 rm "bin/$( get_arch )/$file"
	} done

        # Optionen für make werden vorbereit: 
        # -j (Anzahl der Kerne die make nutzt) also z.B. -j4
        # und nach die mitgegeben Optionen - siehe weiter oben.
	option="-j$(( $cpu_count + 1 ))${option:+ }$option"	
	echo "executing: 'make $option'"

        # Hier passiert der eigentliche Build.. 
        # make von OpenWRT wird aufgerufen... 
        # Hier wird das Image gebaut!!!
	make $option || return 1

        # Es hat geklappt!
        [...
	echo "\"Jauchzet und frohlocket...\" \ 
         ob der Bytes die erschaffen wurden: \ 
         (revision: $( scripts/getver.sh ))" 

# [...]
}

Die Eigentliche Arbeit wird von OpenWRT geleistet. Wie feeds.conf und make menuconfig und .config Files funktionieren würde noch einen weiteren Blogpost füllen. Mit den Infos hier und dem OpenWRT-Wiki bekommt man das aber schnell heraus. Entweder durch Source lesen oder zum Treffen kommen :)

Jetzt kann man sich durch die Dokumentation auf der Weimarnetz github-Seite wühlen und herausbekommen wie man seine eigene Firmware ändert. Am besten erstmal auf dem Router testen.

Momentan gaukelt einem das Buildsystem auch noch vor man würde die lokal veränderten Dateien ins Image einbauen. Dem ist nicht so. Es wird ein Paket aus dem github-Sourcen gebaut über einen Package-Feed der den aktuellen Master-Branch nutzt.

Die Makefile für das Paket sieht so aus:

include $(TOPDIR)/rules.mk

PKG_NAME:=kalua
PKG_VERSION:=2014-09
PKG_RELEASE=$(PKG_SOURCE_VERSION)

PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://github.com/weimarnetz/weimarnetz.git
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE_VERSION:=master
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz

include $(INCLUDE_DIR)/package.mk

define Package/kalua
  SECTION:=utils
  CATEGORY:=Utilities
  MAINTAINER:=Andreas Bräu <freifunk@andi95.de>
  TITLE:=Kalua extensions
  URL:=http://kalua.org/trac/wiki
endef


define Package/kalua/description
 Kalua extensions used in weimarnetz.
endef

define Package/kalua/compile
endef

define Package/kalua/install
	$(INSTALL_DIR) $(1)/etc
	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/etc/kalua_* $(1)/etc/
	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/etc/local* $(1)/etc/
	$(INSTALL_BIN) $(PKG_INSTALL_DIR)/etc/variables* $(1)/etc/
        [...gekürzt]
endef

$(eval $(call BuildPackage,kalua))

Dieses Paket wird über die feeds.conf (die im Build-System auch auftaucht, grep -r ist immer nützlich) eingebunden. Details über Package-Feeds findet man im OpenWRT-Wiki

Soweit erstmal... leider auch mehr eine Linkliste als ein Tutorial, aber mit den Infos sollte man erstmal reicht weit kommen. Am besten zum Treffen kommen oder die Mailingliste fragen.

Links und Tutorials

Es gibt noch weitere gute Tutorials. Bernd hat mich auf zwei gute Bücher mit freien Lizenzen aufmerksam gemacht, die Freifunk allgemein behandeln:

WLAN für alle – Freie Funknetze in der Praxis

Wireless Networking in the Developing World ist ein guter - wenn auch etwas älterer Einstieg.

Die Dokumentation (und der Quellcode) anderer Firmware-Versionen ist auch lesenswert und teilweise auf die Weimarnetz-Firmware übertragbar:

Freifunk Gluon Dokumentation
Meshkit Dokumentation

Have Phun!

Häufige Gäste der M18 kennen es vielleicht: Jeden Dienstag Abend sind die "Freifunker" im Maschinenraum. Was verbirgt sich hinter Freifunk und dem lokalen Ableger namens Weimarnetz? Und wie funktioniert das eigentlich...

Was ist Freifunk?

Eine schöne Definition  findet sich auf der Seite der Berliner Freifunker:

Die Vision von Freifunk ist die Verbreitung freier Netzwerke, die Demokratisierung der Kommunikationsmedien und die Förderung lokaler Sozialstrukturen. Durch die Vernetzung ganzer Stadtteile wollen wir der digitalen Spaltung entgegenwirken und freie unabhängige Netzwerkstrukturen aufbauen. Konkret hat sich Freifunk zum Ziel gesetzt, offene WLAN-Netze einzurichten und diese miteinander zu verbinden. Dies ermöglicht einen freien Datenverkehr "durch die Luft" in der ganze Stadt innerhalb des Freifunk-Netzes. Freifunk ist somit eine offene nicht-kommerzielle hierarchielose Initiative für freie Funknetzwerke.

...kurz&knapp: lokal unhabängige freie Netzwerke aufbauen, technischer und sozialer Natur. Anders formuliert: Internet selber bauen mit - aber nicht nur -  WLAN-Routern.

Hier, hier und hier kann Mensch weiterlesen...

Wie funktionierts?

Freifunker sagen:

Die Grundlage von Freifunk bildet ein sogenanntes Mesh-Netzwerk. Alle WLAN-Router im Freifunk-Netz kommunizieren direkt miteinander und bilden ein eigenes Funknetzwerk in der Stadt. Jeder Mensch im Freifunknetz kann mit Hilfe eines Routingprotokolls andere Teilnehmer_innen erreichen und so Daten austauschen. Manche Knoten sind desweiteren auch direkt mit dem Internet verbunden und so haben alle Menschen im Freifunk Netz auch direkten Zugriff auf das globale Netz.

...äh ja.. Mesh klingt gut... aber:

Wie läuft's nun technisch im Detail?

...kurz&knapp: WLAN-Router +  Linux + Mesh-Software + Freifunk-Software = Freifunk.

Es folgt ein kleiner unvollständiger, selektiver Crashcourse gefüllt mit Links zu weiteren Informationen, die nützlich sein können wenn man selbst an der Firmware entwickeln will oder mehr wissen will. Mitbringen muss man erstmal nichts außer Neugier, Zeit und Geduld... sowie ein klein wenig Frustrationstoleranz ;)

Linux

..ja auf vielen WLAN-Routern läuft Linux. Wie auch auf Android-Telefonen, Flugzeugen und Raumstationen. Das man auf den meisten Routern selbst Linux installieren kann ist der GPL, Linksys und einer Klage zu verdanken. Das war 2004. So lange gibt es auch schon das Weimarnetz. Aus dem veröffentlichten Quellcode des Linksys-Routers entwickelte sich eine Linux-Distribution für alle möglichen Arten von Routern namens OpenWRT und jede Freifunk Software, auch in Weimar, baut auf OpenWRT auf. Mittlerweile sind gängige Chipsätze und Routermodelle gut unterstützt und einige Hersteller liefern ihre Router auch gleich mit OpenWRT aus.

OpenWRT

Linux ist streng genommen nur der Kernel des Betriebssystems. Die Shell und weitere Software wird mit einer Distribution wie OpenWRT angepasst und verteilt. OpenWRT ist die Grundlage für die Firmware und als normaler Nutzer hat man damit nicht viel zu tun. Wenn man einfach nur einen Router aufstellen will, kann man sich fertig vorkonfigurierte Images bauen lassen. Dabei nutzt man Meshkit, dass auf dem OpenWRT Imagebuilder aufbaut.

OpenWRT ist natürlich anders als z.B. ein Ubuntu. Aber vieles ist auch ähnlich z.B gibt es auch eine Paketverwaltung bei OpenWRT und verdammt viele Pakete. OpenWRT ist für Embedded-Geräte optimiert, also Geräte mit meist auf irgendeiner Art beschränkten Ressourcen. So läuft OpenWRT mit ein paar Tricks schon mit 2MB Flash und 16MB RAM. Die fertigen Images für die Router im Weimarnetz sind inklusive Kernel+Systemtools sowie unserer Freifunk-Software auf dem Router-Flash nur etwa 3.5MByte groß. Dementsprechend muss man Kompromisse machen.

Nur passen die meisten Pakate nicht auf den geringen Flash-Speicher des Routers. Abhilfe schafft ein Router mit USB, da kann man das Dateisystem auf dem USB-Stick auslagern - Ein Router mit 4Mbyte Flash macht das ganze aber auch interessanter ;)

Alle Informationen, die man wissen muss finden sich im OpenWRT-Wiki.

Hardware

Preislich geht es mit tauglichen Routern so ab 15€ los und nach oben sind keine Grenzen gesetzt. Details über unterstützte Hardware gibt im OpenWRT-Wiki und auf der Weimarnetz-Website. Mit etwas Arbeit sollten aber alle von OpenWRT unterstützten Router mit mindestens 4MByte-Flash und 32Mbyte RAM laufen. Zu jedem Modell gibt es eine ausführliche Seite im OpenWRT-Wiki mit Details zum Stand der Unterstützung und Hinweise auf mögliche Probleme. Unterschiede gibt es bezüglich der WLAN-Features, wie auch in der Prozessorarchitektur (MIPS, ARM und PowerPC sind häufig anzutreffen) sowie natürlich bezüglich Flash-Speicher und RAM.

Generell gilt, dass TP-Link gut und günstig ist und Ubiquity besser aber etwas teurer ist.

WLAN

Die Router sollen ja auch Daten hin und her senden... Dafür wird WLAN genutzt. Also kann man sich auch mit WLAN-Standards beschäftigen und ist bestrebt ständig neue Möglichkeiten die Bandbreite und Reichweite sowie die generelle Effizenz des Netzes zu verbessern. Man kann z.B. Antennen selber bauen oder mit Tools wie Horst nach optimalen Standorten suchen. Wissen um die Theorie und Praxis von Antennen ist immer nützlich. Außerdem kommt mal aus dem Haus, wenn man Outdoor-Installation baut :)

Meshing

..oder Vermaschtes Netz. Der Kern der ganzen Geschichte: Jetzt hat man ein paar Router die sich im vermaschten Adhoc-Modus sehen können und wie genau können die jetzt ein größeres und nutzbares Netzwerk bilden? Dafür braucht man ein Routingprotokoll! Da gibt es z.B. OLSR (Layer 3) oder B.A.T.M.A.N. (Layer 2) und noch ein paar mehr... So ein Routingprotokoll definiert wie verbundene Router auf der Netzwerk-Ebene miteinander sprechen können und welche Pfade die Pakete unter allen Möglichen Bedingungen nehmen können. Da wird viel Experimentiert und es gibt teilweise RFCs sowie viele wissenschaftliche Veröffentlichungen über die Protokolle und sogar einen Wettbewerb welches Protokoll besser ist... einfach mal bei die Links durchklicken...

Weimarnetz nutzt OLSR und so läuft auf allen Routern der olsrd Dienst der aus dem Routern das Weimarnetz macht. Hier ist eine Karte aller aktueller Knoten mit ihren Verbindungen zueinander.

Freifunk-Software

Wir haben jetzt einen passenden Router, für das Teil auch noch eine tolle Linux-Distribution und wir haben uns für ein Routingprotokoll, dass wir fürs vermaschen nutzen wollen entschieden... Und jetzt?

Irgendwie fehlt da noch ein System. Das Image muss konfiguriert werden und für neue Router angepasst werden, man möchte als Nutzer nicht immer mit telnet und seriellen Kabel die Bytes herumschieben... eine Weboberfläche wäre auch schön. Zudem ist einem schon beim Vorwort zum OLSR RFC schwindelig geworden und eigentlich will man das alles ja nur nutzen und experimentieren. Außerdem muss man die Knoten in der Community irgendwie benennen und für TCP/IP benötigt man eindeutige IP-Adressen damit es keine Konflikte gibt... und überhaupt wäre es cool, wenn alle Freifunknetze innerhalb von Deutschland miteinander reden könnten?

Alle diese Probleme versucht die Freifunk-Software zu lösen - und noch ein paar weitere: So werden auf dem Router auch noch zugänge für VPN-Server konfigiguriert um auch Knoten die nicht physikalisch verbunden sind zu vernetzen und der Störerhaftung zu entgehen... es gibt zudem ein Monitoring der laufenden Knoten in der Community und viele weitere Details die gelöst werden müssen...

kalua

Auf den Weimarnetz-Routern erledigt davon vieles kalua - eine Werkzeugsammlung in POSIX-Shell programmiert, die den Router aufsetzt und konfiguriert und nachfolgend darüber wacht, dass das Router und das Netz laufen, auch wenn mal was schief geht.

dazu später mehr...

Neugierig? Freifunk-Treffen ist immer Dienstag ab 20.00Uhr - Maschinenraum M18.