FunkFeuer Wiki - Benutzerbeiträge [de]

UBNT Bullet2

2009-07-12T01:23:37Z

HaraldG: Neuer Link für olsrd-0.5.6r5

[[Datei:Bullet2.JPG]]

Die [http://ubnt.com/products/bullet.php Ubiquiti Bullet2] ist ein Wetterfester Router, der direkt an Antennen mit N-Buchse angeschlossen werden kann. Die Stromversorgung erfolgt über PoE direkt über das Netzwerkkabel (4,5+; 7,8-). Die Bullet verfügt über einen LAN-Anschluss und 6 LEDs. LED 1+2 zeigen Stromversorgung und LAN-Aktivität an. Dir restlichen LEDs zeigen im Originalbetriebssystem die Empfangsleistung an. Für AirOS gibt es zwar ein olsrd-Paket, aber leider ist der WLAN-Treiber nicht Ad-Hoc-Modus-fähig. Daher installiert man am besten OpenWRT.

== OpenWRT Installation ==

Das OpenWRT Image kann bequem mit dem AirOS Webinterface auf die Bullet2 geflasht werden.

Folgendes Firmware-Image ist das richtige:

http://downloads.openwrt.org/kamikaze/8.09/atheros/openwrt-atheros-ubnt2-squashfs.bin

=== alternativ ===
Sollte man aus irgendwelchen Gruenden nicht mehr auf das Webinterface zugreifen koennen, kann man das Image auch per TFTP hochladen.

Dazu drueckt man nach dem einschalten sofort die Reset Taste fuer 6-10 Sekunden (bis jeweils 2 LEDs abwechselnd blinken), anschliessend verbindet man sich mit einem TFTP Client (evt. zuerst mit ping die Erreichbarkeit testen).
<pre>
> tftp 192.168.1.20
> bin
> put <IMAGE-NAME>
> exit
</pre>

== Nach dem flashen ==
Die Bullet hat nun die IP 192.168.1.1
entsprechend musst du deine Netzwerkkarte neu konfigurieren
dann per telnet einloggen ("root"/kein passwort) und mit passwd ein passwort für den root user setzen um SSH zu aktivieren

== Netzwerk Konfiguration ==

Die relevanten Files fuer die Netzwerkkonfiguration sind
* /etc/config/network
* /etc/config/wirless

OpenWRT bridged das Ethernet und WIFI Interface standardmaessig, diese Standardkonfiguration wird veraendert um auf dem Wireless Interface die oeffentliche IP zu konfigurieren. Auf dem Ethernet Interface wird eine private IP Adresse konfiguriert. Spaeter werden dann iptables Rules erstellt um den Traffic aus dem LAN nach aussen zu NAT'en.

''/etc/config/network''
<pre>
config 'interface' 'loopback'
option 'ifname' 'lo'
option 'proto' 'static'
option 'ipaddr' '127.0.0.1'
option 'netmask' '255.0.0.0'

config 'interface' 'lan'
option 'ifname' 'eth0'
option 'proto' 'static'
option 'ipaddr' '192.168.xx.xx'
option 'netmask' '255.255.255.0'

#hier wird die IP Adresse eingetragen die man im Reedemer zugewiesen bekommen hat
config 'interface' 'wan'
option 'ifname' 'ath0'
option 'proto' 'static'
option 'ipaddr' 'xx.xx.xx.xx'
option 'netmask' '255.255.xx.xx'
</pre>

Die richtigen Werte fuer ssid/bssid entnimmt man am besten dieser Seite: [[Kanalwahl]]

Es ist darauf zu achten dass "option 'network' 'lan'" auskommentiert ist (man kann es auch ganz entfernen), da man sonst auf eth0 und ath0 die selbe IP hat.

''/etc/config/wireless''
<pre>
config 'wifi-device' 'wifi0'
option 'type' 'atheros'
option 'channel' '1'

config 'wifi-iface'
option 'device' 'wifi0'
# option 'network' 'lan'
option 'encryption' 'none'
option 'hidden' 0
option 'mode' 'adhoc'
option 'ssid' 'v1.freiesnetz.www.funkfeuer.at'
option 'bssid' '4E:FE:52:36:2E:65'
</pre>

In der Standardkonfiguration sind nur die Kanäle 1-11 aktiviert. Möchte man die Kanäle 12 oder 13 verwenden, ist der CountryCode auf "Österreich" zu stellen. Dazu ändert man in der Datei ''/etc/modules.d/50-madwifi'' die Zeile mit ''ath_ahb'' auf:
ath_ahb countrycode=40

== OLSR Installation ==

Da man auf der Bullet (wahrscheinlich) noch keinen Internetzugriff hat, kann man sich das ipk File auf den lokalen Rechner herunterladen, per SCP auf die Bullet kopieren und anschliessend per ''opkg'' installieren.

OLSR braucht die libpthread die du zuvor installieren musst
* http://downloads.openwrt.org/kamikaze/8.09/atheros/packages/libpthread_0.9.29-14_mips.ipk
* http://texas.funkfeuer.at/~harald/olsrd/mips/olsrd_0.5.6-r5-1_mips.ipk
opkg install <ipk-file>

=== OLSR Konfiguration ===
Das Konfigurationsfile fuer olsr heisst in OpenWRT: ''/etc/config/olsrd'' und es hat die uebliche UCI schreibweise, die sich von einer Standard olsr Konfigurationsdatei zwar syntaktisch unterscheidet aber die selben Konfigurationsparameter aufweisst. Die hier angegebenen Werte fuer Timer und Intervale sind von Empfehlungen auf der Funkfeuer Mailingliste uebernommen worden. Falls eine Parameter in der folgenden Liste vermisst wird so wurde dieser nicht explizit gesetzt da sein Standardwert bereits ok ist.

''/etc/config/olsrd''
<pre>
config olsrd
option IpVersion '4'
option Willingness '7'
option TcRedundancy '2'
option LinkQualityAlgorithm 'etx_ff'
option MprCoverage '7'

config Interface
list interface 'wan'
option Ip4Broadcast '255.255.255.255'
option HelloInterval '3.0'
option HelloValidityTime '125.0'
option TcValidityTime '500.0'
option TcInterval '2.0'
option MidInterval '25.0'
option MidValidityTime '500.0'
option HnaInterval '10.0'
option HnaValidityTime '125.0'
</pre>

== Iptables / NAT ==

OpenWRT kommt mit einem Standard iptables Setup, ich habe es durch ein paar einfache Regeln ersetzt die ihren Zweck erfuellen. Das Script kann nach /etc/rc.d/S45_deinwunschname verlinkt werden.
<pre>
#!/bin/sh

iptables -F
iptables -t nat -F
iptables -X

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.xx.0/24 -j MASQUERADE
iptables -A FORWARD -i ath0 -o ath0 -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.xx.0/24 -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

#olsr
iptables -A INPUT -s 193.238.156.0/22 -p udp --dport 698 -j ACCEPT
iptables -A INPUT -s 78.41.112.0/21 -p udp --dport 698 -j ACCEPT

iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -j ACCEPT
</pre>

== DHCP DNS Option ==

Wenn man moechte, dass Clients, DNS Requests direkt an den DNS Server schicken, kann der DHCP Server so eingerichtet werden, dass er dies den Clients als Option mitgibt.

<pre>
# uci add_list dhcp.lan.dhcp_option="6,193.238.157.16,193.238.157.5"
# uci commit dhcp
# /etc/init.d/dnsmasq restart
</pre>
Durch diese Schritte wird die Datei ''/etc/config/dhcp'' entsprechend veraendert und dnsmasq neugestartet.

== Anmerkung/Tipp ==

Die Ausspahrung im Schraubverschluss an der Unterseite ist zwar genau so gross dass ein RJ45 Stecker durchpasst, trotzdem sollte man bei gekauften (bereits gekrimpten) Kabeln darauf achten dass diese keinen Klipschutz haben. Dieser kann beim Durchfuehren des Kabels bzw. beim zuschrauben zu Problemen fuehren und muss dann evt. mit einem Messer vorsichtig entfernt werden.

fuer die signalstaerke leds gibt es einen (IMO zieml. invasiven) patch...
https://dev.openwrt.org/ticket/5066

== Hardware Pics ==
* http://www.flickr.com/photos/mattw/3103755054/sizes/l/
* http://www.flickr.com/photos/mattw/3103756610/sizes/l/
(gruene platine = Bullet2, weisse platine = Bullet5)

* http://www.flickr.com/photos/mattw/3460916088/
(hier siehst Du, das Bullet2 und Picostation2 baugleich sind bis auf den Antennenanschluss)

Arbeitsgruppe FoneraPlus

2009-07-11T22:01:58Z

HaraldG: Linkupdate für Version 0.5 = olsrd-0.5.6r5

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Konfiguration für aktuelles (8.09) kamikaze und 0xFF=
Es gibt eine vorbereitete best practice Konfiguration für die Fonera(+) und kamikaze für den Einsatz im Funkfeuer Mesh. Die Installation ist denkbar einfach:

Entweder (für die Fonera+)
* http://texas.funkfeuer.at/~harald/firmware-0.5/0xff-bootstrap-fonera+_0.5.tgz
oder (für die Fonera)
* http://texas.funkfeuer.at/~harald/firmware-0.5/0xff-bootstrap-fonera_0.5.tgz
herunterladen und nach /tmp auf dem Router, auf dem bereits kamikaze läuft, kopieren:
scp 0xff-bootstrap-fonera_0.5.tgz root@192.168.1.1:/tmp/

Dann auf dem Router einloggen, das Archiv entpacken und das 0xff-bootstrap Skript mit der gewünschten wlan-IP starten:
ssh root@192.168.1.1
cd /tmp/
tar -xzf 0xff-bootstrap-fonera_0.5.tgz
./0xff-bootstrap 10.42.42.1 # Use your own IP!!!

Das war's! Wenn du willst, kannst du selber noch ein paar Konfigurationsdateien bearbeiten, musst du aber wahrscheinlich nicht. Neu starten und die Fonera sollte sich mit dem Mesh verbinden.

Siehe den nächsten (obsoleten) Abschnitt für Hintergrundinformationen.

=Experimentelle Firmware für 0xFF (obsolet)=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

===Original OpenWrt===
Der Konfigtarball funktioniert auch mit den originalen Firmwareimages von OpenWrt. (Aktuelle Snapshots oder Release Candidates) - Allerdings müssen ein paar Pakete nachinstalliert werden.

* ip - für wait4default
* kmod-sched - Kernelmodule für olsr traffic control
* tc - für olsr traffic control

Für alles weitere sollte es keinen Unterschied machen welche Firmware verwendet wird.

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!
/etc/init.d/rtprio enable
/etc/init.d/rtprio start

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe FoneraPlus

2009-04-04T14:06:56Z

HaraldG: kaputtes Markup repariert

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Konfiguration für aktuelles (8.09) kamikaze und 0xFF=
Es gibt eine vorbereitete best practice Konfiguration für die Fonera(+) und kamikaze für den Einsatz im Funkfeuer Mesh. Die Installation ist denkbar einfach:

Entweder (für die Fonera+)
* http://texas.funkfeuer.at/~harald/firmware-0.4/0xff-bootstrap-fonera+_0.4.tgz
oder (für die Fonera)
* http://texas.funkfeuer.at/~harald/firmware-0.4/0xff-bootstrap-fonera_0.4.tgz
herunterladen und nach /tmp auf dem Router, auf dem bereits kamikaze läuft, kopieren:
scp 0xff-bootstrap-fonera_0.4.tgz root@192.168.1.1:/tmp/

Dann auf dem Router einloggen, das Archiv entpacken und das 0xff-bootstrap Skript mit der gewünschten wlan-IP starten:
ssh root@192.168.1.1
cd /tmp/
tar -xzf 0xff-bootstrap-fonera_0.4.tgz
./0xff-bootstrap 10.42.42.1 # Use your own IP!!!

Das war's! Wenn du willst, kannst du selber noch ein paar Konfigurationsdateien bearbeiten, musst du aber wahrscheinlich nicht. Neu starten und die Fonera sollte sich mit dem Mesh verbinden.

Siehe den nächsten (obsoleten) Abschnitt für Hintergrundinformationen.

=Experimentelle Firmware für 0xFF (obsolet)=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

===Original OpenWrt===
Der Konfigtarball funktioniert auch mit den originalen Firmwareimages von OpenWrt. (Aktuelle Snapshots oder Release Candidates) - Allerdings müssen ein paar Pakete nachinstalliert werden.

* ip - für wait4default
* kmod-sched - Kernelmodule für olsr traffic control
* tc - für olsr traffic control

Für alles weitere sollte es keinen Unterschied machen welche Firmware verwendet wird.

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!
/etc/init.d/rtprio enable
/etc/init.d/rtprio start

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe FoneraPlus

2009-04-04T14:03:45Z

HaraldG: Update: 0xff-bootstrap

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Konfiguration für aktuelles (8.09) kamikaze und 0xFF=
Es gibt eine vorbereitete best practice Konfiguration für die Fonera(+) und kamikaze für den Einsatz im Funkfeuer Mesh. Die Installation ist denkbar einfach:

Entweder (für die Fonera+)
* http://texas.funkfeuer.at/~harald/firmware-0.4/0xff-bootstrap-fonera+_0.4.tgz
oder (für die Fonera)
* http://texas.funkfeuer.at/~harald/firmware-0.4/0xff-bootstrap-fonera_0.4.tgz
herunterladen und nach /tmp auf dem Router, auf dem bereits kamikaze läuft, kopieren:
| scp 0xff-bootstrap-fonera_0.4.tgz root@192.168.1.1:/tmp/

Dann auf dem Router einloggen, das Archiv entpacken und das 0xff-bootstrap Skript mit der gewünschten wlan-IP starten:
| ssh root@192.168.1.1
| cd /tmp/
| tar -xzf 0xff-bootstrap-fonera_0.4.tgz
| ./0xff-boostrap 10.42.42.1 # Use your own IP!!!

Das war's! Wenn du willst, kannst du selber noch ein paar Konfigurationsdateien bearbeiten, musst du aber wahrscheinlich nicht. Neu starten und die Fonera sollte sich mit dem Mesh verbinden.

Siehe den nächsten (obsoleten) Abschnitt für Hintergrundinformationen.

=Experimentelle Firmware für 0xFF (obsolet)=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

===Original OpenWrt===
Der Konfigtarball funktioniert auch mit den originalen Firmwareimages von OpenWrt. (Aktuelle Snapshots oder Release Candidates) - Allerdings müssen ein paar Pakete nachinstalliert werden.

* ip - für wait4default
* kmod-sched - Kernelmodule für olsr traffic control
* tc - für olsr traffic control

Für alles weitere sollte es keinen Unterschied machen welche Firmware verwendet wird.

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!
/etc/init.d/rtprio enable
/etc/init.d/rtprio start

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe Babel

2009-01-18T02:23:14Z

HaraldG: Block für manuelle Vergabe, rerun

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
Auf dieser Seite wird die Arbeit im Zusammenhang mit Babel koordiniert und dokumentiert. Fertige Dokumentation sollte auf die Wikiseite [[Babel]] verschoben werden. Diese Seite hat teilweise inhaltliche Überschneidungen mit der [[Arbeitsgruppe IPv6 im Mesh]].

=IP Adressen Vergabe=
Wir haben den IPv6 Prefix 2a02:60:2::/48 von Funkfeuer für Babelexperimente zugewiesen bekommen. Die Aufteilung des Prefix wird über diese Seite koordiniert, aber bitte zusätzlich auch ein kurzes Mail an harald@lefant.net schreiben, damit es auch außerhalb des Wikis ein Backup der Information gibt.

==2a02:60:2::/64 - Pool für /128 Prefices==
===2a02:60:2::/96 - IPv4 mapping Block - Startskript===
In diesem Block wird jeder v4 Adresse a.b.c.d die v6 Adresse 2a02:60:2::a.b.c.d zugeordnet. Diese Adresse wird vom babel-Initskript automatisch konfiguriert, damit alle babel-Router für Monitoringzwecke erreichbar sind.

===2a02:60:2::1:0:0/96 - manuelle Vergabe===
2a02:60:2::1:0:1 rerun.babel # HaraldG

==2a02:60:2:1::/64 - LAN am Knoten g4==
Kontakt: HaraldG

Arbeitsgruppe Babel

2008-12-31T16:57:56Z

HaraldG: IP Vergabe dokumentiert

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
Auf dieser Seite wird die Arbeit im Zusammenhang mit Babel koordiniert und dokumentiert. Fertige Dokumentation sollte auf die Wikiseite [[Babel]] verschoben werden. Diese Seite hat teilweise inhaltliche Überschneidungen mit der [[Arbeitsgruppe IPv6 im Mesh]].

=IP Adressen Vergabe=
Wir haben den IPv6 Prefix 2a02:60:2::/48 von Funkfeuer für Babelexperimente zugewiesen bekommen. Die Aufteilung des Prefix wird über diese Seite koordiniert, aber bitte zusätzlich auch ein kurzes Mail an harald@lefant.net schreiben, damit es auch außerhalb des Wikis ein Backup der Information gibt.

==2a02:60:2::/64 - Pool für /128 Prefices==
===2a02:60:2::/96 - IPv4 mapping Block - Startskript===
In diesem Block wird jeder v4 Adresse a.b.c.d die v6 Adresse 2a02:60:2::a.b.c.d zugeordnet. Diese Adresse wird vom babel-Initskript automatisch konfiguriert, damit alle babel-Router für Monitoringzwecke erreichbar sind.

==2a02:60:2:1::/64 - LAN am Knoten g4==
Kontakt: HaraldG

Arbeitsgruppe Babel

2008-12-31T16:30:37Z

HaraldG: Seite angelegt

Arbeitsgruppen

2008-12-31T16:24:52Z

HaraldG: Neue Arbeitsgruppe für Babel

Ein Working Wiki (kurz. WoW) ist im Grunde auch nur ein oder mehrere Wiki Seiten, allerdings über Dinge die noch w.i.p. ..

siehe auch: [[Arbeitsgruppe_WoW|Was ist ein WoW?]]

Und gleichzeitig eben mit der Einladung an alle daran Interresierten sich an diesem Inhalt noch ungezwungener als im restlichen Wiki auch schreiberisch zu beteiligen,..

Auch Fragen/Ideen und nicht nur Antworten/Inhalt sind auf diesen Seiten (oder der Diskussion) äusserst angebracht! (-;

=[[Arbeitsgruppe_Hardware|Hardware]]=
* [[Arbeitsgruppe_Hardware_Fonera_power|Fonera (Low Power)]] WoW
* [[Arbeitsgruppe_FoneraPlus|Fonera+]] WoW
* [[Arbeitsgruppe_Hardware_OSBRiDGE_5GXi|OSBRiDGE 5GXi]]
* [[Arbeitsgruppe_Hardware_SL75WLAN|SL75 WLAN]]
* [[Arbeitsgruppe_Hardware_RONJA|RONJA]]
** [[Arbeitsgruppe_Hardware_RONJA:Optischer_Kopf|RONJA - Optischer Kopf]]
* [[Arbeitsgruppe_Hardware_Mikrotik_Routerboards|Mikrotik_Routerboards]]

=[[Arbeitsgruppe_Software|Software]]=
* [[Arbeitsgruppe_Software_DNS|DNS Probleme und Lösungen]] WoW
* [[Arbeitsgruppe_Software_AdhocBridge|Drahtlose Adhoc Netzwerke bridgen]] WoW
* [[Arbeitsgruppe_Software_Failure_Monitoring|Besseres Monitoring von Funknetz Ausfällen]] WoW
* [[Arbeitsgruppe_Software_PINGPERF|Bandwidth Tests mit ping]] WoW
* [[Arbeitsgruppe_IPv6_im_Mesh|IPv6 im Mesh]] WoW
* [[Arbeitsgruppe_Babel|Babelexperiment]] WoW

=[[Arbeitsgruppe_Support|Support]]=
* [[FAQ]]
* [[Erste Schritte]]

=[[Arbeitsgruppe_Homepage|Homepage]]=

=[[Arbeitsgruppe_Funknetz|Funknetz]]=

=[[Arbeitsgruppe_Housing|Housing]]=

=[[Arbeitsgruppe_Backbone|Backbone]]=

=[[Arbeitsgruppe_Oberwelt|Oberwelt]]=
*[[Oberwelt:Ziel|Ziel]]
*[[Oberwelt:Veranstaltungen|Veranstaltungen]]
*[[Oberwelt:InfoMaterial|InfoMaterial]]

=[[Arbeitsgruppe_Verein|Verein]]=

=[[Arbeitsgruppe_VoIP|VoIP]]=

Diskussion:Arbeitsgruppe IPv6 im Mesh

2008-11-29T16:24:53Z

HaraldG: /* ipv4 raus aus dem Backbone - Antwort an Alex */

Meine (==[uk]) 0.02Eur (nachdem ich mir noch nicht sicher bin wies in den Artikel passt). /Ein wenig auch meine Erfahrungen mit jahrelangem IPv6 Produktionsbetrieb an der Uni Wien/.

* radvd am Router fuers LAN (das Paket gibts zumindest mal)
** Damit koennen alle gaengigen OSn ohne konfig ins Netz.
* ip6tables
* Ich hab mit 6to4 keine uebermaessig guten Erfahrungen gemacht - auf lange sicht macht sich native/dual-stack bezahlt.
** Haken: alle nodes muessen dual-stack sein (weil OLSR leider auch kein Multiprotokoll-RP ist [1])
* DNS (insb. Reverse DNS ist problematisch - insb bei der Verwendung von EUI64-Adressen)
** Deswegen machen wir das bei uns (Uni Wien) derzeit auch nur fuer Server - und dort verwenden wir keine EUI64 Adressen.

[1] Was eigentlich ein echter Mangel ist. Wird das mit OLSR-NG besser? (siehe IS-IS und BGP4)

olsrd kann v6 oder v4 . Wenn man beides will: 2 mal starten :) Es gibt in .ZA ein Netz, das olsr rein auf v6 faehrt --[[Benutzer:Aaron|aka]] 20:48, 18. Aug 2008 (CEST)

----
Hey, da beteiligen sich ja schon Leute, obwohl ich die Seite noch nicht einmal auf der ML angekündigt habe... cool. :)

Klar, der radvd wird schon seit ein paar Tagen von mir getestet - scheint sogar auf der alten Freifunkfirmware ganz passabel zu laufen...

Was native IPv6 betrifft: Bei Funkfeuer geht der Trend derzeit ganz stark in Richtung mehr Hardware- (und Firmware-) vielfalt. Ich glaub' nicht, dass in absehbarer Zeit "IPv6 forwarding auf allen Nodes" durchsetzbar sein wird.

Ja, beim nächsten OLSR RFC wird IPv6 stark berücksichtigt, aber total unklar, wann das implementiert wird und ob Funkfeuer dann noch OLSR verwendet oder ein anderes Protokoll...

Ach ja, kannst die Seite natürlich gerne umbauen, wenn deine Erfahrungen dann besser hinein passen ...

Harald

== eine ideale Welt. ==

Eigentlich muesste ja IPv6 einem Mesh-Netzwerk entgegenkommen.
* im WLAN keine Globalen v6 Adressen noetig - eigentlich muessten dort die link-locals fuer die Routing-wolke reichen
* ein /48 pro Node - das wird dann per HNA announced.
* Ein Knoten ohne EndHosts braucht damit eigentlich auch keine Globalen IPs (Note: wie sehen im OLSR RouterIDa aus?)

''RouterIDs im OLSR: Sind normalerweise IP Adressen von einem Interface - bei Nodes mit mehreren Interfaces wird eines mehr oder weniger zufällig ausgewählt. Es gibt aber auch Leute, die darüber nachdenken, als IDs die MAC Adressen zu verwenden.''

''Die Idee mit den Subnetzen für die Nodes geistert schon eine Weile in manchen Köpfen hier herum, aber es scheint mittelfristig nicht umsetzbar...''

<cynism>
Und ueberhaupt wird ja mit IPv6 alles viel besser und schneller und ueberhaupt.
</cynism>

== ipv4 raus aus dem Backbone ==
Da sich alle IPv4 Adressen im IPv6 Adressraum abbilden lassen ist es nur logisch, den backbone mittelfristig auf v6 only umzustellen. Dies würde die verschwendung von v4 PI-Adressen für wlaninterfaces beenden und die nutzung von ipv6 für den enduser ermöglichen.

Damit dies geht, ist es nötig, den ipv4 traffic durch das v6 mesh zu bekommen.
* Klassisches tunneling kommt da meines erachtens nicht in frage, da dann die verbindungen zwischen den clients über den tunnelserver gehn.
* Stateless dynamic tunneling wahre denkbar, war für mich aber nicht interessant.
Daher habe ich mich mit Stateless IPCM/IP Translation nach rfc2765 beschäftigt und dies unter http://blogs.k-ita.de/~alx/?p=91 zusammengefasst.

Gruss, Alex

:Hi Alex, das ist sehr interessant. Ich kopier den Link zu deinem Blog einmal auf die Hauptseite. --[[Benutzer:HaraldG|HaraldG]] 17:24, 29. Nov 2008 (CET)

Arbeitsgruppe IPv6 im Mesh

2008-11-29T16:23:55Z

HaraldG: Link zu Blog von alx über Protokolltranslation

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

=Was wir schon haben=
* Einen großen Block IP6 Adressen
* natives IP6 im housing
* öffentliche IP4 Adressen auf allen Routern

=Probleme=
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.

=Lösungsvorschläge=
==6to4 Tunnel==
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

===Vorteile===
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
* Die Infrastruktur von IPv4 kann mitbenutzt werden
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
* Es funktioniert mit allen relevanten Firmwares

===Nachteile===
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
* Ein 6to4 anycast server in unserer Nähe wäre fein
* Es wird eine öffentliche IPv4 Adresse benötigt

===Funktionsweise beim Routen eines Pakets===
Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

===Let's do it===
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:

PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo MYIP | tr "." " ") )

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:

ip tunnel add tun6to4 mode sit ttl 64 remote any local MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4 # /16 ist richtig
ip -6 route add default via ::192.88.99.1 dev tun6to4

:Bemerkung: Wir verwenden in Zeile 3 /16 anstelle der sonst üblichen /64, weil ja alle 6to4 Adressen über den Tunnel direkt erreichbar sind und nicht nur unsere eigene... Würden wir /64 verwenden, dann würden Routen zu IPs im Mesh über den anycast server gehen, also nicht mehr den "natürlichen Weg", was 6to4 irgendwie ad absurdum führen würde - da könnten wir gleich eine zentrale Tunnellösung verwenden.

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router:
ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC:
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter [[#Adressautokonfiguration | unten]].

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
ping6 marvin.funkfeuer.at

Wenn das oben nicht reicht (linksys/whiterussian machte probleme) dann noch
sysctl -w net.ipv6.conf.all.forwarding=1

Weil v6 forwarding bei mir ausgeschaltet war

und
ip -6 route add 2000::/3 via ::192.88.99.1 dev tun6to4

weil das routing mit der defaultroute so nicht geklappt hat

===Dauerhafte Konfiguration für FFF===
Folgendes Skript stellt die obige Konfiguration bei einem Neustart wieder her. Die Parameter am Beginn müssen natürlich für jeden Router angepasst werden (Mag wer ein .ipk mit einer Seite für's webinterface schreiben?).

/etc/init.d/S556to4
#!/bin/sh

MYIP="127.43.233.17"
PREFIX="2002:7f2b:e911"
LANDEV="vlan0"

case $1 in
start)
ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

ip -6 addr add $PREFIX:1::1/64 dev $LANDEV
;;

stop)
ip tunnel del tun6to4
ip -6 addr del $PREFIX:1::1/64 dev $LANDEV
;;

*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac

===Offene Fragen===
* Wie gut funktioniert pathmtu discovery?
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
* Eigener anycast server für Funkfeuer?
* DNS für IP6 Adressen?

=Lokale IPv6 Konfiguration=
==Adressautokonfiguration==
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement daemon (radvd)'' laufen, der den Router im Netz ankündigt.

===Installation des radvd===
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0.0, br0, br-lan, ...) verwenden, herausfinden:

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
inet6 fe80::216:1ff:fe92:8bf2/64 scope link
inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:

interface vlan0
{
AdvSendAdvert on;
prefix 2002:c1ee:9eb2:1::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden:

/etc/init.d/S51radvd start #Freifunkfirmware
/etc/init.d/radvd start #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

==Firewall==
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

=Weitere Quellen=
* http://debienna.at/IPv6to4
* http://wiki.debian.org/DebianIPv6
* http://wiki.openwrt.org/IPv6_howto
* [http://blogs.k-ita.de/~alx/?p=91|Stateless IPCM/IP Translation nach rfc2765]

Freifunk Firmware

2008-11-29T16:14:29Z

HaraldG: wl-adv ist bei neueren FFF nicht mehr wichtig

<google>WIKI</google>

'''WICHTIG MOMENTAN NUR 1.6.28 verwenden KEINE NEUERE FIRMWARE'''

==Download==
Die Firmware von Freifunk in einer für deutsch "de" angepassten Form ist [http://download-master.berlin.freifunk.net/ipkg/ hier] zu finden.
Im [http://download-master.berlin.freifunk.net/ipkg/readme.txt Readme] ist beschrieben, welche Firmware Version zu welcher Hardware Version passt.
[http://ipkg.funkfeuer.at/freifunk/ipkg/ oder hier ] ist der 0xff paketserver

Hier ein kurzer Auszug des Readme der Version 1.6.7:

_g+gl/ Linksys WRT54G-v1.x|2.0|2.2|3.0|3.1|4.0, WRT54GL-v1.0|1.1
_gs/ Linksys WRT54GS-v1.0, WRT54GS-v1.1
_gs40/ Linksys WRT54GS-v4.0 (WRT54GS-v3.0 unverified)
_g3g/ Linksys WRT54G3G (a WRT54G with PCMCIA UMTS card)
_allnet/ Allnet ALL0277 (tested: all0277 without ADSL)
_moto/ Motorola WR850G (tested: wr850g v1.0, minor issues)
_se505/ Siemens SE505 (v1.0|2.0)
_trx/ Linksys WAP54G-v1.1|2.0|3.0, WRT54G-v5.0|5.1|6.0, WRT54GS-
v5.0|5.1|6.0; Asus WL500, WL500-Deluxe, WL500-Premium;
Buffalo WHR-G54S, WHR-HP-G54 && for Freifunk updates
_failsafe/ Emergency minimal failsafe files, only telnet 192.168.1.1
_kit/ BIN/TRX Linux generation kits, Micro+WEP versions here

eventuelle Beta Version gibt es [http://download-master.berlin.freifunk.net/sven-ola/testing/ hier]

==Installation linksys (.bin) und buffalo (.trx)==
=== Installation per web Interface (einfacher, nur Linksys) ===
Nun wird eine neue Firmware in den Router "geflasht", also installiert.
Was ist zu tun:
*IP des PCs fix auf 192.168.1.2 ((einzustellen unter "Systemsteuerung"->"Netzwerkverbindungen". Dort auf die LAN-Verbindung des Routers, Rechtsklick auf "Eigenschaften")
*Ebenfalls dort die Netzwerkmaske (net mask) 255.255.255.0 einstellen
*Im Webinterface des Routers den Menüpunkt "Firmware Upgrade" (in der deutschen Version heißt das anders!) anklicken und die soeben gespeicherte Freifunk Firmware als Datei angeben.
*Ein wenig warten (10 min)
*Das Webinterface der neuen Firmware auf http://192.168.1.1 aufrufen

Logindaten ab Werk zum Konfigurieren für Linksys WRT54 Router:
:Benutzername: root
:Passwort: admin

->Tipp: Sobald man eine Änderung der Router Konfiguration vorgenommen hat, fordert die Firmware zum Neustart auf. Dies muss aber nicht sofort erfolgen, sondern man kann durchaus zuerst alle neuen Einstellungen vornehmen und erst dann neu starten!

===Installation mit tftp (linksys und buffalo)===

Hier die Beschreibungen für tftp und tftp2 (Windows-GUI) und tftp für Linux.

====tftp Windows====
* IP des PCs fix auf 192.168.1.2 einstellen (bzw 192.168.11.2 bei buffalo)
* am PC die DOS Eingabeaufforderung aufmachen (Start -> Ausführen ... "cmd.exe")
* In der DOS Eingabeaufforderung den befehl

tftp -i 192.168.1.1 MEINEFREIFUNKIMAGEDATEI.bin
(192.168.11.1 MEINEFREIFUNKIMAGEDATEI.trx bei buffalo)

VORBEREITEN (wobei MEINEFREIFUNKIMAGEDATEI natürlich die freifunk Image Datei ist, die man downgeloadet hat).
Vorbereiten heißt: eintippen aber noch nicht enter drücken.
* die Linksys rebooten
* WICHTIG: den richtigen Moment erwischen und ENTER drücken.
Es ist oft ein bisschen ein Herumprobieren bis man den richtigen Moment erwischt.
Auch sollte man sich Zeit lassen, bis der Router unter 192.168.1.1 bzw 192.168.11.1 mit der Freifunk-Firmware per Browser erreichbar ist. Das kann bis zu 5 Minuten dauern.

====tftp2 Windows====

Deutlich einfacher geht das Flashen unter Windows mit tftp2.exe (einfach in google suchen). Prinzipiell ist die Vorgehensweise wie bei tftp.

* IP des PCs fix auf 192.168.1.2 einstellen (bzw 192.168.11.2 bei buffalo)
* Server ist 192.168.1.1 bzw 192.168.11.1
* kein Password
* File ist MEINEFREIFUNKIMAGEDATEI.bin bzw MEINEFREIFUNKIMAGEDATEI.trx
* den Router vom Strom abstecken
* anstecken und "kurz darauf" auf "Upgrade" drücken.

Es ist oft ein bisschen ein Herumprobieren bis man den richtigen Moment erwischt.
Auch sollte man sich Zeit lassen, bis der Router unter 192.168.1.1 bzw 192.168.11.1 mit der Freifunk-Firmware per Browser erreichbar ist. Das kann bis zu 5 Minuten dauern.

====tftp Linux====

* Paket "tftp-hpa" oder anderes geeignetes tftp-Tool installieren.
* Commando zum Flashen absetzen. dazu sollte man sich im Verzeichnis befinden wo auch die <aktuelle-firmwareversion>.trx liegt. In den Beipielen unten wird angenommen dass der Router die IP 192.168.11.1 hat. Der PC muss sich natürlich im gleichen IP-Netzwerk befinden.
* Dann den Router einschalten und warten...
tftp 192.168.11.1
binary
rexmt 1
timeout 60
trace
Packet tracing on.
tftp> put <aktuelle-firmwareversion>.trx

oder in einer command line (empfohlen):
echo -e "binary\nrexmt 1\ntimeout 60\ntrace\nput <aktuelle-firmwareversion>.trx\n" | tftp 192.168.11.1

==Standard Konfiguration==

'''Hinweis:'''
Seit Version 1.6 ist die Verwaltung der Firmware über WLAN deaktiviert,
da dabei das Routerpasswort ständig unverschlüsselt über Funk gesendet wird.
Man kann den Router aber dennoch über Funk verwalten, wenn man
[http://wiki.funkfeuer.at/index.php/Linksys_WRT54GL#Verwalten_via_Funk_geht_nicht über einen SSH-Tunnel verschlüsselt] auf die Weboberfläche zugreift
Das Paket [[Freifunk_Firmware#freifunk-recommended_bzw_0xff-recommended|Freifunk_recommended]] bringt aber bereits eine SSL-Erweiterung mit, um auch wieder über Funk auf die Verwaltung in der Weboberfläche zuzugreifen!
'''Hier nicht beschriebene Optionen der Freifunk-Firmware sollten unverändert übernommen werden'''

===Kennwort===
ein neues Kennwort zweimal eingeben
===Kontaktinfos===
*'''Spitzname:''' [[Frontend_Mitglied#.2A_Nickname|<Nickname aus dem Frontend/Redeemer>]]
*'''E-Mail:''' [[Frontend_Mitglied#.2A_E-Mail|<E-Mail aus dem Frontend/Redeemer>]]
*'''Standort:''' <Knotenname aus dem Frontend/Redeemer> (oder tatsächliche Adresse?)
:zb: "str99" (oder "Strasse 99"?)

===System===

*'''Rechnername:''' <device-name>
:z.B. "omni" oder "nordost" siehe auch: [[Frontend_Device#Name|Name des Devices im Frontend]]
*'''Domain:''' <knoten-name>.<ort>.funkfeuer.at
:z.B. "str99.wien.funkfeuer.at"
*'''DNS-Server:''' 193.238.157.16;193.238.157.5
:mit ''';''' OHNE Abstand
*'''Starte DNS/DHCP-Server:''' Einschalten
:bei z.B. WAP54g wegen Speichermangel ausschalten
*'''Zeitzone:''' MET-1MEST-2,M3.3.0,M10.5.0
*'''Land:''' Austria

===OLSR===
Alles leer bzw. auf default-Einstellung belassen, ausser...

*'''ACHTUNG NEU:''' '''Broadcast IPV4:''' 255.255.255.255
*'''OLSR Tempo:''' 5
*'''QOS-Protokoll (ETX):''' Einschalten
*'''DynGW:''' Ausschalten (nur für <1.6.x, später nicht mehr vorhanden)'''
*'''Policy Routing:''' Ausschalten (Ausnahme: Router die auch noch über einen "normalen" Internetanschluss ins Internet können)
*'''Nameservice:''' Ausschalten (spart ein bisschen Traffic)
*'''REST''' unterhalb bleibt alles auf: Einschalten

===Drahtlos===
WLAN-Protokoll: OLSR (static ab 1.6.13)

WLAN-IP-Adresse: die IP-Adresse dieses Devices, abzulesen in der Redeemer [[Frontend_Devices | Device Übersicht]] (193.238.15x.x)

WLAN-Netzmaske:

* bei einer Addresse zwischen '''193.238.156.0 und .159.254''':  255.255.25'''2'''.0 <- Achtung

* bei einer Addresse zwischen '''78.41.112.0 und .112.254''':      255.255.25'''5'''.0 <- Achtung

WLAN-Default-Route: bleibt leer! Das Routing erledigt OLSR. Fixe Routen erzeugen loops. Dann besser den OLSR LQ-Faktor unter Punkt OLSR ändern.

WLAN-Modus: ad-hoc

'''''NACH EINTRAGEN NOCH EINMAL AUF "DRAHTLOS" KLICKEN UM ssid, bssid und Kanal ZU '''KONTROLLIEREN.''' Bitte hier keine Fehler machen'''''

ESSID: z.B. v1.freiesnetz.www.funkfeuer.at [http://wiki.funkfeuer.at/index.php/Kanalwahl#Unsere_ssid_und_bssid laut Liste]

BSSID: '''im zur not kurzzeitig LEER lassen funkpriorität bssid for essid (MUSS man aber eintragen)''' [http://wiki.funkfeuer.at/index.php/Kanalwahl#Unsere_ssid_und_bssid laut Liste]

Kanal: z.B. 1 [http://wiki.funkfeuer.at/index.php/Kanalwahl#Unsere_ssid_und_bssid laut Liste]

'''''NACH EINTRAGEN NOCH EINMAL AUF "DRAHTLOS" KLICKEN UM ssid bssid und Kanal ZU KONTROLLIEREN. Bitte hier keine Fehler machen'''''

Kartentyp: 802.11b/g

Empfangsantenne: bei wrt54gL Antenne A (das der Antennenanschluss der nicht bei der Spannungsversorgung ist)

Sendeantenne: bei wrt54gL Antenne A (das der Antennenanschluss der nicht bei der Spannungsversorgung ist)
:[http://forum.funkfeuer.at/viewtopic.php?pid=173 Forum: 2ter Antennenanschluss am WRT54GL]

Sendeenergie: Minimaleinstellung ist 1 (sind Milliwatt) und maximal siehe [https://wiki.funkfeuer.at/index.php/Gesetzliche_Bestimmungen Gesetzliche_Bestimmungen] je nach Antennengewinn. Die meisten Linksys gehen am besten mit 45 mW, haben da die besten/meisten Verbindungen.
|in neuer firmware ist ein rechner dabei mit << nach links qdbm übernehmen

'''Achtung im Gegensatz zu alten ff versionen ist die sendeleistung in qdbm und nicht mehr mw '''
daher mit Kabel/Stecker-Verlust: Antennengewinn: das ergebniss ist im grauen feld zu sehen mit
und mit << in qdmb umrechnen lassen *45qdbm sind nur 13mw*, 60qdbm = 32mw, 70qdbm=56mw, 80qdbm=100mw

Entfernung (Meter): zb 14000 die meisten laufen mit 18000
| (nach motto paar Meter mehr Schaden nicht, zuwenige eher daher keinesfalls 1000 )

Funk-Modus: B und G Modus

(E)SSID senden: Einschalten

Basisrate: je nach Wlan-Modus

Übertragungsrate: auto |( bei schwierigen bedingungen 2! (NIE 1 das geht nicht gut)
und wenn die rate manchmal automatisch auf 1 (in statistik) geht dann 2 oder 5,5 selten auch bis 11 einstellen bei mehr gehen unter umständen nur mehr die stärksten verbindungen '''bitte immer wieder zeitweise mal beobachten korrigieren'''

Multicast-Rate: 5,5 in neuerer firmware

CTS-Schutz: aus

Frame-Burst: aus

Beacon-Intervall: 100

DTIM-Intervall: 1

Frag.-Schwelle: 2346

RTS-Schwelle: 250

MTU-Wert: leer oder 1500

===LAN===
LAN-Protokoll: statisch

LAN-IP: 192.168.1.1

LAN-Netzmaske: 255.255.255.0

LAN-Default-Route: LEER lassen

Statische Routen: LEER lassen

NAT ausschalten: nein -- im Wiener Funkfeuer Netz

NAT ausschalten: nein (JA -- wenn auf den LAN Ports weitere Funkfeuer Devices angesteckt werden)

Firewall ausschalten: Nein (JA -- wenn auf den LAN Ports weitere Funkfeuer Devices angesteckt werden)

DHCP-Start-IP: 192.168.1.100

DHCP-Benutzeranzahl: 100

DHCP-Lease-Dauer: kann leer bleiben oder 43200 für 12 Stunden''' aber nicht 0''' ! (0 deaktiviert den DHCP Server)

===WAN===
im Normalfall = deaktiviert

WAN-IP: leer

WAN-Mask: leer

WAN-Def.Route: leer

RJ45-Anschlüsse: '''automatischer Vorschlag darf NICHT verändert werden '''
"0 5" beim Buffalo WHR54 oder "4 5" beim Linksys WRT54gl oder auch 0 5 bei älteren Linksys

Diese Option verbindet die 5 physikalisch vorhandenen Anschlüsse mit dem internen (WAN)Anschluss

Beim Linksys Wrt54GL(!) gelten folgende Werte: 4=Internet(WAN), 3=LANport1, 2=LANport2, 1=LANport3, 0=LANport4

Will man zB 2 WAN Ports für 2 weitere Linksys haben, nimmt man 4 (WANPort) und 3 (LANport1) => "3 4 5" - zB alle LANports als WANport verwenden => "0 1 2 3 4 5"

===Publizieren===

===Software===
Die Installation zusätzlicher Software ist optional, weil die Freifunk Firmware alle für 0xFF notwendigen Programme bereits installiert hat.

Das Paket 0xff-recommended-de installiert die Funkfeuer-Oberfläche, die Statistiken, wl-adv und weitere nützliche Pakete automatisch, es ist allerdings erst nach dem Einstellen des Funkfeuer Paketserves verfügbar, siehe weiter unten unter [[Freifunk_Firmware#Den_Funkfeuer_Paketserver_verwenden]]

===Firmware===
bevor man auf eine neuere Firmware Version updaten kann, muss man zuvor unter "Neustart" "starten im readonly modus" wählen und auch durchführen dan die 0xff.TRX rauf spielen.
Funk und LAN WAN bleiben nach diesen Neustart aktiv

Einstellungen bleiben auch nach einem Update erhalten. Daher kann auch per Funk upgedatet werden!!
[http://wiki.funkfeuer.at/index.php?title=Freifunk_aktualisieren ausführliche Anleitung]

===Neustart===
ohne Worte

==Anpassungen==
===Den Funkfeuer Paketserver verwenden===

Nachdem der original freifunk-Server gelegentlich nicht erreichbar ist und es einige funkfeuer-Erweiterungen für die Software gibt, wurde ein eigener Server eingerichtet. Diesen kann man folgendermaßen verwenden:

====über das Webinterface====

* http://ipkg.funkfeuer.at/funkfeuer-ipkg-patch_1.6_mipsel.ipk herunterladen
* die Datei im Webinterface unter Software1 uploaden
* den Router neu starten
* Liste aktualisieren in software2

====über SSH====

* per ssh auf den Router einloggen

* folgende Befehle ausführen:

ipkg install http://ipkg.funkfeuer.at/funkfeuer-ipkg-patch_1.6_mipsel.ipk
/etc/init.d/S12ipkg
ipkg update

Danach sind unter "Software 2" zum Beispiel das Hotspot- und das Nettools-Paket verfügbar, außerdem greift der Router für Updates auf den Funkfeuer-Mirror zu.

===0xFF Oberfläche mit österreichischen Links===

"Software 2" klicken
Bei "freifunk-webadmin-0xff" auf installieren klicken

Ein eigenes Bild für die Startseite des FreiFunk Webinterface:
* Das gewünschte Bild auf dem Rechner auf "intro.jpg" umbenennen
* Das Bild sollte nicht zu Groß sein (einige zig kB)
Auf "Publizieren" und "Durchsuchen" klicken
Das Bild auswählen und hochladen
Nach einem Refresh der Startseite ("Aktualisieren") (eventuell Cache leeren) sollte das Bild sofort sichtbar sein

==Verbund mehrer Devices an einem Node/Knoten==

'''Achtung:''' die 2 oder mehr Router sollten die selbe Firmwareversion haben, sonst kann es Probleme geben.

===Zwei Router im Verbund===

Um 2 Router per Kabel miteinander zu verbinden, ist es nötig auf einem Ethernet-Anschluss jedes Routers eine offizielle Funkfeuer-IP-Adresse zu konfigurieren.

einfach die selbe ip adresse wie am funk am WAN verwenden '''KEINESFALLS diese ip am LAN port'''
verwenden dazu bitte lesen http://wiki.funkfeuer.at/index.php/Freifunk_Firmware#Mehr_als_zwei_Router_im_Verbund

Anschließend das Web-Interface des Routers im Browser aufrufen und unter "Verwalten" einloggen.

* Im Web-Interface des Routers auf "WAN" klicken
* WAN-Protokoll: "OLSR" auswählen
* WAN-IP: Die entsprechende IP-Adresse
* WAN-Netzmaske: 255.255.25'''2'''.0 oder 255.255.25'''5'''.0 (je nach WAN-IP), siehe Drahtlos
* "Übernehmen" und neu starten.

Beim zweiten Router ebenso verfahren und die beiden Geräte mit einem Ethernet Kabel an den beiden WAN-Anschlüssen verbinden. Fertig! Auf der Statusseite wird die offizielle IP des zweiten Routers unter "Nachbarn" angezeigt, der ETX-Wert sollte nach einer kleinen Wartezeit "1.00" maximal auch mal 1.02 sein.

===Mehr als zwei Router im Verbund===
====Variante 1====
Da man nicht mehr als zwei Router via WAN direkt verbinden kann, benutzt man auf einem Router den LAN Port (4 Anschlüsse je Router) oder verwendet einen zusätzlichen Netzwerk Switch/Hub, siehe [[Freifunk_Firmware#Variante_2|Variante 2]]

in der aktuellen Firmware (1.6.28) gibt es massive Probleme, wenn man für "Drahtlos" und
LAN dieselbe IP-Adresse verwendet. Daher MUSS man zusätzliche IP-Adressen besorgen.

Um diese zusätzlichen IP-Adressen zu beziehen, muss man sich mit seinen Zugangsdaten in der [https://marvin.funkfeuer.at/frontend_wien/ Redeemer Benutzerdatenbank] anmelden. Dann auf "[[Frontend_Nodes|Nodes]]" klicken und beim gewünschten Knoten unter [[Frontend_Devices|Devices]] auf "Show" klicken. Dann mit "Hinzufügen" ein weiteres [[Frontend_Device|Device]] anlegen. Heißt das Gerät zum Beispiel
"nordost", dann wären "nordostlan" oder omnilan, v1lan, knoten1v1x oder knoten1v1lan die möglichen Namen passend zum "Funknamen".

* Im Web-Interface des Routers auf "LAN" klicken
* LAN-Protokoll: "OLSR" auswählen
* LAN-IP: eine der reservierten IP-Adressen.
* LAN-Netzmaske: 255.255.25'''2'''.0 oder 255.255.25'''5'''.0 (je nach LAN-IP), siehe Drahtlos
* "Übernehmen" und neu starten
* 2-4 Ethernet-Kabel an die LAN-Anschlüsse anstecken.
* '''Achtung:''' Dieses Gerät kann jetzt keine dahinter liegenden PC's mit DHCP und NAT versorgen (dazu die weiteren Geräte verwenden) da der LAN-Port für die Verbindung zu den anderen Routern verwendet wird und ist daher auch nicht unter 192.168.1.1 im Browser erreichbar! (entweder auf einem per Kabel verbundenen Router einsteigen und auf der Statusseite zu diesem Gerät durchklicken oder vorher den WAN-Port entsprechend konfigurieren)

Die weiteren Geräte wie unter "[[Freifunk_Firmware#Zwei_Router_im_Verbund|Zwei Router im Verbund]]" angeführt konfigurieren.
Die Ethernet Kabel des ersten Gerätes mit den WAN-Buchsen der weiteren Geräte verbinden, fertig! Auf der Statusseite werden die offizielle IP-Adressen der anderen Router unter "Nachbarn" angezeigt. Der ETX-Wert sollte bei allen nach einer kleinen Wartezeit "1.00" sein.

====Variante 2====
Am LAN Port die fixe interne IP einstellen 192.168.x.x, Mask 255.255.255.0, NAT nicht ausschalten. Am WAN Port OLSR, die FF-Adresse und Mask 255.255.25x.0 einstellen. Sämtliche WAN-Ports der Router mit einem Switch verbinden. Vorteil: die LAN Ports können weiter verwendet werden.

====Variante 3====
Sämtliche Einstellungen wie bei [[Freifunk_Firmware#Variante_2|Variante 2]], aber den Wert für RJ45-Anschluss folgendermaßen anpassen:
[http://wiki.funkfeuer.at/index.php/Freifunk_Firmware#WAN WAN]
Vorteil: Damit kann man aus den einzelnen LAN Ports zusätzliche WAN Ports machen. Man benötigt keinen Switch. Verbleibende LAN Ports können weiterhin für interne Endgeräte verwendet werden.
Nachteil: Der eingestellte Wert für RJ45-Anschluss hat je nach verwendeter Hardware (Linksys/Buffalo) eine andere Bedeutung. Man sollte es daher vorher Testen, welcher Wert (0-5) für welches Port steht.

==Die Erweiterungen==
===freifunk-recommended bzw 0xff-recommended===
Freifunk-recommended installiert unter anderem:
*DNS/DHCP Server
*graphische Router Statistiken
*graphische Darstellung des Netzwerks: OLSR-Viz
*horst: ein Kommandozeilen Tool zum WLAN Messen/scannen
0xff-recommended-de installiert noch zusätzlich die Österreichische Funkfeuer-Oberfläche
====Voraussetzungen für die Installation====
*die Internet(Funk)verbindung steht
*Ein Router mit ausreichend Speicher
====über das Webinterface====
* unter "Software1" "Freifunk-recommended-de" auswählen und "Software laden" klicken.
*:[[Bild:freifunk-recommended_software1.png|100px|left]] 
* Anschließend beginnt sich das graue Fenster zu füllen...
*:[[Bild:freifunk-recommended_software1_load.png|100px|left]] 
* Das dauert nun einige Minuten (je nach Internetanbindung) bis zum Schluß folgendes im grauen Fenster steht:
*:[[Bild:freifunk-recommended_software1_load_finish.png|100px|left]] 
* Um die Statistiken zu initialisieren, muss der Router noch rebooten: Unter "Neustart" -> "Einfacher Neustart"
*:nach einigen Minuten erscheint der erste Graph unter "Statistik"
====über SSH====
ipkg install freifunk-recommended-de
===Statistik===
(ist im freifunk-recommended-Paket schon enthalten)
====über SSH====
ipkg install freifunk-statistics-de

===OSLR VIZ===
====über SSH====
ipkg install freifunk-olsr-viz-de

----

Arbeitsgruppe FoneraPlus

2008-11-21T00:45:18Z

HaraldG: Anleitung für original OpenWrt

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

===Original OpenWrt===
Der Konfigtarball funktioniert auch mit den originalen Firmwareimages von OpenWrt. (Aktuelle Snapshots oder Release Candidates) - Allerdings müssen ein paar Pakete nachinstalliert werden.

* ip - für wait4default
* kmod-sched - Kernelmodule für olsr traffic control
* tc - für olsr traffic control

Für alles weitere sollte es keinen Unterschied machen welche Firmware verwendet wird.

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!
/etc/init.d/rtprio enable
/etc/init.d/rtprio start

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe FoneraPlus

2008-11-21T00:32:18Z

HaraldG: Installationsanleitung für rtprio ergänzt

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!
/etc/init.d/rtprio enable
/etc/init.d/rtprio start

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe Software AdhocBridge

2008-11-05T22:55:39Z

HaraldG: /* Memoryleak (Lösung gefunden (wirklich?)) */

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: Markus Kitttenberger)
----
Ansich kann man doch alles bridgen,..

Adhoc Netze zu bridgen endet aber meist enttäuschend,..

es geht gar nicht, bzw. furchtbar schlecht/langsam,..

Warum ist das so?

Im Adhoc modus werden keine ACKs für gebridge pakete versendet (da sie ja nicht die macadresse des in der bridge befindleichen wireless interfaces haben) die folgen sind geringer durchsatz, oder schlimmeres

Kann man das umgehen?

Ja, entweder man schreibt einen nicht adhoc-standardkonformen wlan treiber,..

Oder man versendet nur Pakete mit der richtigen MAC Adresse,..

Will man ein drahtlos Adhoc-netz mit einem einzigen drahtgebundenen gegenüber bridgen, lässt sich das problemlos erreichen,..
Und mit dieser eingeschränkten bridge kann man schon problemlos einen wlan-router an einen zwieten anstekcne, der dann defakto ein zweiteres wireless interface hat,.. prädestiniert dafür sind Router mit nur einem Ethernet port (wie z.B. Foneras)

=MAC rewriting=
um das problem mit den WLAN-Acks zu lösen reicht es auf der bridge alle pakete vom zu bridgenden ethernet device die MAc adresse des wlan interfaces zu geben, und vice versa,..

die kann man mit ebtables komfortbael tun

allerdings streiken dann die arp-lookups, da bei diesen die mac adressen sowohl im ehternet header als auch im paket vorliegen,..

mit arptables kann man dies ebenso leicht mit 2 Zeilen erledigen

damit arptables allerdings mit bridges funktinoert braucht man einem kernel mit BRIDGE_NF

dies bedeutet für 2.4er kernel einen patch, und für 2.6er eine konfig optinoen beim kompilieren

weiters emfpiehlt es sich nachher BRIDGE_NF nur für arptables aktivert zu lassen und für iptables wieder abzuschalten, da dies sonst merklich (ergibt eine xfach höhere cpu load) performance kostet, wenn alle gebridgten pakete durch iptables/netfilter durch müssen, (selbet wenn es dort gar keine iptable rules gibt)

=Eigene Firmware?=
Aufgrund des modifizierten kernels ist es nicht so leicht dies einfach als ipkg zu einer bestehenden openwrt-basierten firmware zu realisieren?

Weiss wer wie man kmod packages macht (d.h. rausfindet was sich alles an einem kernel durch BRIDGE_NF ändert)

Die andere variante sich eine eingene komplett zu flashende firmware zu ersparen ist das ARP-Packet-rewriting nicht mit arptables zu machen sonderm mittels einem selbst gemachten/modifizierten arp-proxies oder ähnlichem zu ersetzen

andererseits ist eine funktionierende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja z.B.: keiner drauf (-;)

==Probleme mit der eigenen Firmware==
Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet oder alle Links verliert. Anscheinend gibt es mindestens zwei Probleme:

===Memoryleak (Lösung gefunden (wirklich?))===
Es gibt recht offensichtlich ein Memoryleak, dass aber nichts mit der bridge Konfiguration zu tun hat, sondern anscheinend an bestimmten Kernelversionen liegt:

:OK, ich muss zugeben, ich weiß nicht mehr genau, wann ich mit welchem Patch getestet hab', folgendes stammt jedenfalls von g4 mit BRIDGE_NETFILTER und mit ebtables und arptables geladen (also voll funktionsfähige Bridge):

: root@FoneraBridge:/tmp# uname -a
: Linux FoneraBridge 2.6.26.5 #1 Tue Oct 21 02:14:29 CEST 2008 mips unknown

: root@FoneraBridge:/tmp# cat freelog
: 19700101-02-01 Mem: 13740 11428 2312 0 1112
: 19700101-03-01 Mem: 13740 11092 2648 0 1112
: 19700101-04-01 Mem: 13740 11188 2552 0 1112
: 19700101-05-01 Mem: 13740 11380 2360 0 1112
: 19700101-06-01 Mem: 13740 11140 2600 0 1112
: 19700101-07-01 Mem: 13740 11208 2532 0 1112
: 19700101-08-01 Mem: 13740 11244 2496 0 1112
: 19700101-09-01 Mem: 13740 11200 2540 0 1112
: 19700101-10-01 Mem: 13740 11252 2488 0 1112
: 19700101-11-01 Mem: 13740 11256 2484 0 1112
: 19700101-12-01 Mem: 13740 11352 2388 0 1112
: 19700101-13-01 Mem: 13740 11376 2364 0 1112
: 19700101-14-01 Mem: 13740 11448 2292 0 1112
: 19700101-15-01 Mem: 13740 11568 2172 0 1112
: 19700101-16-01 Mem: 13740 11548 2192 0 1112
: 19700101-17-01 Mem: 13740 11836 1904 0 1112
: 19700101-18-01 Mem: 13740 11520 2220 0 1112
: 19700101-19-01 Mem: 13740 11596 2144 0 1112
: 19700101-20-01 Mem: 13740 11692 2048 0 1112
: 19700101-21-01 Mem: 13740 11932 1808 0 1112
: 19700101-22-01 Mem: 13740 11952 1788 0 1112
: 19700101-23-01 Mem: 13740 12032 1708 0 1112
: 19700102-00-01 Mem: 13740 12032 1708 0 1112
: 19700102-01-01 Mem: 13740 11880 1860 0 1112
: 19700102-02-01 Mem: 13740 11904 1836 0 1112
: 19700102-03-01 Mem: 13740 11872 1868 0 1112
: 19700102-04-01 Mem: 13740 11868 1872 0 1112
: 19700102-05-01 Mem: 13740 11952 1788 0 1112
: 19700102-06-01 Mem: 13740 12144 1596 0 1112
: 19700102-07-01 Mem: 13740 11932 1808 0 1112
: 19700102-08-01 Mem: 13740 11960 1780 0 1112
: 19700102-09-01 Mem: 13740 11956 1784 0 1112
: 19700102-10-01 Mem: 13740 11948 1792 0 1112
: 19700102-11-01 Mem: 13740 11936 1804 0 1112
: 19700102-12-01 Mem: 13740 11964 1776 0 1112
: 19700102-13-01 Mem: 13740 12008 1732 0 1112
: 19700102-14-01 Mem: 13740 12080 1660 0 1112
: 19700102-15-01 Mem: 13740 11996 1744 0 1112
: 19700102-16-01 Mem: 13740 12272 1468 0 1112
: 19700102-17-01 Mem: 13740 12272 1468 0 1112
: 19700102-18-01 Mem: 13740 12272 1468 0 1112
: 19700102-19-01 Mem: 13740 12028 1712 0 1112
: 19700102-20-01 Mem: 13740 11968 1772 0 1112
: 19700102-21-01 Mem: 13740 11968 1772 0 1112
: 19700102-22-01 Mem: 13740 12000 1740 0 1112
: 19700102-23-01 Mem: 13740 12032 1708 0 1112
: 19700103-00-01 Mem: 13740 12032 1708 0 1112
: 19700103-01-01 Mem: 13740 12032 1708 0 1112
: 19700103-02-01 Mem: 13740 12116 1624 0 1112
: 19700103-03-01 Mem: 13740 12064 1676 0 1112
: 19700103-04-01 Mem: 13740 12124 1616 0 1112
: 19700103-05-01 Mem: 13740 12140 1600 0 1112
: 19700103-06-01 Mem: 13740 12152 1588 0 1112
: 19700103-07-01 Mem: 13740 12164 1576 0 1112
: 19700103-08-01 Mem: 13740 12160 1580 0 1112
: 19700103-09-01 Mem: 13740 12192 1548 0 1112
: 19700103-10-01 Mem: 13740 12192 1548 0 1112
: 19700103-11-01 Mem: 13740 12192 1548 0 1112
: 19700103-12-01 Mem: 13740 12236 1504 0 1112
: 19700103-13-01 Mem: 13740 12232 1508 0 1112
: 19700103-14-01 Mem: 13740 12244 1496 0 1112
: 19700103-15-01 Mem: 13740 12220 1520 0 1112
: 19700103-16-01 Mem: 13740 12284 1456 0 1112
: 19700103-17-01 Mem: 13740 12220 1520 0 1112
: 19700103-18-01 Mem: 13740 12256 1484 0 1112
: 19700103-19-01 Mem: 13740 12256 1484 0 1112
: 19700103-20-01 Mem: 13740 12276 1464 0 1112
: 19700103-21-01 Mem: 13740 12332 1408 0 1112
: 19700103-22-01 Mem: 13740 12336 1404 0 1112
: 19700103-23-01 Mem: 13740 12336 1404 0 1112
: 19700104-00-01 Mem: 13740 12292 1448 0 1112
: 19700104-01-01 Mem: 13740 12264 1476 0 1112
: 19700104-02-01 Mem: 13740 12264 1476 0 1112
: 19700104-03-01 Mem: 13740 12344 1396 0 1112

:Also wirklich klar erkennbar ist ein Leak da nicht mehr. - Mit dem früheren Kernel hätte der Router nie 3 Tage uptime erreicht, weil er schon nach etwas mehr als einem Tag out of RAM rebooted hätte.

:Ein bissi was zu tun gehabt hat er auch in der Zeit:

: root@FoneraBridge:/tmp# tc -s qdisc
: qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
: Sent 8380773865 bytes 8282658 pkt (dropped 0, overlimits 0 requeues 0)
: rate 0bit 0pps backlog 0b 0p requeues 0
: qdisc prio 11: dev wifi0 root bands 3 priomap 2 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2
: Sent 2176364281 bytes 2584495 pkt (dropped 0, overlimits 0 requeues 534)
: rate 0bit 0pps backlog 0b 0p requeues 534
: qdisc pfifo 10: dev wifi0 parent 11:1 limit 195p
: Sent 495379536 bytes 456544 pkt (dropped 0, overlimits 0 requeues 34)
: rate 0bit 0pps backlog 0b 0p requeues 34
: qdisc pfifo 20: dev wifi0 parent 11:2 limit 195p
: Sent 52648133 bytes 88524 pkt (dropped 0, overlimits 0 requeues 3)
: rate 0bit 0pps backlog 0b 0p requeues 3
: qdisc pfifo 30: dev wifi0 parent 11:3 limit 195p
: Sent 1628336612 bytes 2039427 pkt (dropped 0, overlimits 0 requeues 497)
: rate 0bit 0pps backlog 0b 0p requeues 497

::Nach 14 Tagen ist die Fonera jetzt doch rebootet. Ursache war leider nicht feststellbar und die Dauer der downtime davor auch nicht (Grenze 0-2 Stunden). --[[Benutzer:HaraldG|HaraldG]] 23:55, 5. Nov 2008 (CET)

Folgender Kernel hat das Problem:
/ # uname -a
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown

während bei diesem Kernel noch kein Leak nachweisbar war (ca.
12 Stunden laufzeit):
/ # uname -a
Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown

(allerdings lief dieser kenel ohne bridge_nf ??)

Update:
allerdings mit bridge_nf weisen auch 2.6.26.5er Kernel noch leaks auf, darum läuft nun auf einer testbridge (garten94-heusued) ein automatischer reboot nach 24h oder bei weniger als 1MB freien Speicher, zwar keine elegante Lösung, aber zumindest kann man nun mal den router einfach laufen lassen und abwarten ob wenigsten die wlan probleme (siehe unten) Geschichte sind,..

Mit folgendem Skript habe ich getestet:

/etc/freelog.sh:
#!/bin/sh

echo -n $(date '+%Y%m%d-%H-%M') >>/tmp/freelog
free | grep Mem: >>/tmp/freelog

/etc/crontabs/root:
01 * * * * /etc/freelog.sh

Das ist natürlich nur eine sehr grobe Messmethode und cron hat auch selber einiges an RAM-Verbrauch, aber nach einiger Zeit sieht man trotzdem ob eine Firware betroffen ist oder nicht, ohne einen Absturz abwarten zu müssen...

BTW, /tmp/freelog liegt in der RAM disk, ist also nach einem Absturz weg - also regelmäßig wegsichern oder regelmäßig nachschauen.

====Daten von g4====
/ # uname -a
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown

Kurz nach dem reboot der bridge sagt free:
total used free shared buffers
Mem: 13612 8332 5280 0 768
Swap: 0 0 0
Total: 13612 8332 5280

/tmp/freelog bis kurz vorm Absturz:
20000101-10-12 Mem: 13612 10028 3584 0 768
20000101-11-01 Mem: 13612 10160 3452 0 768
20000101-12-01 Mem: 13612 10196 3416 0 768
20000101-13-01 Mem: 13612 10020 3592 0 768
20000101-14-01 Mem: 13612 10024 3588 0 768
20000101-15-01 Mem: 13612 10156 3456 0 768
20000101-16-01 Mem: 13612 10184 3428 0 768
20000101-17-01 Mem: 13612 10220 3392 0 768
20000101-18-01 Mem: 13612 10268 3344 0 768
20000101-19-01 Mem: 13612 10388 3224 0 768
20000101-20-01 Mem: 13612 10508 3104 0 768
20000101-21-01 Mem: 13612 10588 3024 0 768
20000101-22-01 Mem: 13612 10624 2988 0 768
20000101-23-01 Mem: 13612 10832 2780 0 768
20000102-00-01 Mem: 13612 11160 2452 0 768
20000102-01-01 Mem: 13612 12324 1288 0 768

===Fehlermeldung: no xmit buf===
Dieses Problem scheint unabhängig vom (noch) vorhanden Arbeitsspeicher aufzutreten. Folgendes findet sich in logread, wenn die bridge aufhört, traffic am wifi Interface zu senen. Von g4 mit kernel 2.6.21.5:

Jan 2 01:12:08 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:09 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:20 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:24 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:28 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:40 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:13:43 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:13:55 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:14:22 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:14:25 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf

Und dies stammt von garten94 von der mit der seriellen Konsole überwachten Fonera (Kernel wieder 2.6.21.5):
Jan 1 15:53:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:06 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:55:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
.
.
.
Jan 1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:45 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:54 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.info kernel: NETDEV WATCHDOG: wifi0: transmit timed out
/ # date
Sat Jan 1 16:33:36 UTC 2000
root@OpenWrt:/# free
total used free shared buffers
Mem: 13612 9012 4600 0 768
Swap: 0 0 0
Total: 13612 9012 4600

Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...

Im Zusammenhang mit diesem Problem kann auch ein irrsinnig hoher requeues counter beobachtet werden - das kann beim Debuggen nützlich sein

Arbeitsgruppe Software AdhocBridge

2008-10-25T21:36:00Z

HaraldG: Neue Daten von g4, wo man eigentlich kein Leak sieht

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: Markus Kitttenberger)
----
Ansich kann man doch alles bridgen,..

Adhoc Netze zu bridgen endet aber meist enttäuschend,..

es geht gar nicht, bzw. furchtbar schlecht/langsam,..

Warum ist das so?

Im Adhoc modus werden keine ACKs für gebridge pakete versendet (da sie ja nicht die macadresse des in der bridge befindleichen wireless interfaces haben) die folgen sind geringer durchsatz, oder schlimmeres

Kann man das umgehen?

Ja, entweder man schreibt einen nicht adhoc-standardkonformen wlan treiber,..

Oder man versendet nur Pakete mit der richtigen MAC Adresse,..

Will man ein drahtlos Adhoc-netz mit einem einzigen drahtgebundenen gegenüber bridgen, lässt sich das problemlos erreichen,..
Und mit dieser eingeschränkten bridge kann man schon problemlos einen wlan-router an einen zwieten anstekcne, der dann defakto ein zweiteres wireless interface hat,.. prädestiniert dafür sind Router mit nur einem Ethernet port (wie z.B. Foneras)

=MAC rewriting=
um das problem mit den WLAN-Acks zu lösen reicht es auf der bridge alle pakete vom zu bridgenden ethernet device die MAc adresse des wlan interfaces zu geben, und vice versa,..

die kann man mit ebtables komfortbael tun

allerdings streiken dann die arp-lookups, da bei diesen die mac adressen sowohl im ehternet header als auch im paket vorliegen,..

mit arptables kann man dies ebenso leicht mit 2 Zeilen erledigen

damit arptables allerdings mit bridges funktinoert braucht man einem kernel mit BRIDGE_NF

dies bedeutet für 2.4er kernel einen patch, und für 2.6er eine konfig optinoen beim kompilieren

weiters emfpiehlt es sich nachher BRIDGE_NF nur für arptables aktivert zu lassen und für iptables wieder abzuschalten, da dies sonst merklich (ergibt eine xfach höhere cpu load) performance kostet, wenn alle gebridgten pakete durch iptables/netfilter durch müssen, (selbet wenn es dort gar keine iptable rules gibt)

=Eigene Firmware?=
Aufgrund des modifizierten kernels ist es nicht so leicht dies einfach als ipkg zu einer bestehenden openwrt-basierten firmware zu realisieren?

Weiss wer wie man kmod packages macht (d.h. rausfindet was sich alles an einem kernel durch BRIDGE_NF ändert)

Die andere variante sich eine eingene komplett zu flashende firmware zu ersparen ist das ARP-Packet-rewriting nicht mit arptables zu machen sonderm mittels einem selbst gemachten/modifizierten arp-proxies oder ähnlichem zu ersetzen

andererseits ist eine funktionierende Adhocbridge ein gerät das man eher einmal und nie wieder flasht,.. weil es dann ohne updates problemlos weiterhin seinen dienst tun wird (denn oslr ist ja z.B.: keiner drauf (-;)

==Probleme mit der eigenen Firmware==
Derzeit gibt es das Problem, dass unsere eigene Firware alle paar Tage abstürzt/rebootet oder alle Links verliert. Anscheinend gibt es mindestens zwei Probleme:

===Memoryleak (Lösung gefunden (wirklich?))===
Es gibt recht offensichtlich ein Memoryleak, dass aber nichts mit der bridge Konfiguration zu tun hat, sondern anscheinend an bestimmten Kernelversionen liegt:

:OK, ich muss zugeben, ich weiß nicht mehr genau, wann ich mit welchem Patch getestet hab', folgendes stammt jedenfalls von g4 mit BRIDGE_NETFILTER und mit ebtables und arptables geladen (also voll funktionsfähige Bridge):

: root@FoneraBridge:/tmp# uname -a
: Linux FoneraBridge 2.6.26.5 #1 Tue Oct 21 02:14:29 CEST 2008 mips unknown

: root@FoneraBridge:/tmp# cat freelog
: 19700101-02-01 Mem: 13740 11428 2312 0 1112
: 19700101-03-01 Mem: 13740 11092 2648 0 1112
: 19700101-04-01 Mem: 13740 11188 2552 0 1112
: 19700101-05-01 Mem: 13740 11380 2360 0 1112
: 19700101-06-01 Mem: 13740 11140 2600 0 1112
: 19700101-07-01 Mem: 13740 11208 2532 0 1112
: 19700101-08-01 Mem: 13740 11244 2496 0 1112
: 19700101-09-01 Mem: 13740 11200 2540 0 1112
: 19700101-10-01 Mem: 13740 11252 2488 0 1112
: 19700101-11-01 Mem: 13740 11256 2484 0 1112
: 19700101-12-01 Mem: 13740 11352 2388 0 1112
: 19700101-13-01 Mem: 13740 11376 2364 0 1112
: 19700101-14-01 Mem: 13740 11448 2292 0 1112
: 19700101-15-01 Mem: 13740 11568 2172 0 1112
: 19700101-16-01 Mem: 13740 11548 2192 0 1112
: 19700101-17-01 Mem: 13740 11836 1904 0 1112
: 19700101-18-01 Mem: 13740 11520 2220 0 1112
: 19700101-19-01 Mem: 13740 11596 2144 0 1112
: 19700101-20-01 Mem: 13740 11692 2048 0 1112
: 19700101-21-01 Mem: 13740 11932 1808 0 1112
: 19700101-22-01 Mem: 13740 11952 1788 0 1112
: 19700101-23-01 Mem: 13740 12032 1708 0 1112
: 19700102-00-01 Mem: 13740 12032 1708 0 1112
: 19700102-01-01 Mem: 13740 11880 1860 0 1112
: 19700102-02-01 Mem: 13740 11904 1836 0 1112
: 19700102-03-01 Mem: 13740 11872 1868 0 1112
: 19700102-04-01 Mem: 13740 11868 1872 0 1112
: 19700102-05-01 Mem: 13740 11952 1788 0 1112
: 19700102-06-01 Mem: 13740 12144 1596 0 1112
: 19700102-07-01 Mem: 13740 11932 1808 0 1112
: 19700102-08-01 Mem: 13740 11960 1780 0 1112
: 19700102-09-01 Mem: 13740 11956 1784 0 1112
: 19700102-10-01 Mem: 13740 11948 1792 0 1112
: 19700102-11-01 Mem: 13740 11936 1804 0 1112
: 19700102-12-01 Mem: 13740 11964 1776 0 1112
: 19700102-13-01 Mem: 13740 12008 1732 0 1112
: 19700102-14-01 Mem: 13740 12080 1660 0 1112
: 19700102-15-01 Mem: 13740 11996 1744 0 1112
: 19700102-16-01 Mem: 13740 12272 1468 0 1112
: 19700102-17-01 Mem: 13740 12272 1468 0 1112
: 19700102-18-01 Mem: 13740 12272 1468 0 1112
: 19700102-19-01 Mem: 13740 12028 1712 0 1112
: 19700102-20-01 Mem: 13740 11968 1772 0 1112
: 19700102-21-01 Mem: 13740 11968 1772 0 1112
: 19700102-22-01 Mem: 13740 12000 1740 0 1112
: 19700102-23-01 Mem: 13740 12032 1708 0 1112
: 19700103-00-01 Mem: 13740 12032 1708 0 1112
: 19700103-01-01 Mem: 13740 12032 1708 0 1112
: 19700103-02-01 Mem: 13740 12116 1624 0 1112
: 19700103-03-01 Mem: 13740 12064 1676 0 1112
: 19700103-04-01 Mem: 13740 12124 1616 0 1112
: 19700103-05-01 Mem: 13740 12140 1600 0 1112
: 19700103-06-01 Mem: 13740 12152 1588 0 1112
: 19700103-07-01 Mem: 13740 12164 1576 0 1112
: 19700103-08-01 Mem: 13740 12160 1580 0 1112
: 19700103-09-01 Mem: 13740 12192 1548 0 1112
: 19700103-10-01 Mem: 13740 12192 1548 0 1112
: 19700103-11-01 Mem: 13740 12192 1548 0 1112
: 19700103-12-01 Mem: 13740 12236 1504 0 1112
: 19700103-13-01 Mem: 13740 12232 1508 0 1112
: 19700103-14-01 Mem: 13740 12244 1496 0 1112
: 19700103-15-01 Mem: 13740 12220 1520 0 1112
: 19700103-16-01 Mem: 13740 12284 1456 0 1112
: 19700103-17-01 Mem: 13740 12220 1520 0 1112
: 19700103-18-01 Mem: 13740 12256 1484 0 1112
: 19700103-19-01 Mem: 13740 12256 1484 0 1112
: 19700103-20-01 Mem: 13740 12276 1464 0 1112
: 19700103-21-01 Mem: 13740 12332 1408 0 1112
: 19700103-22-01 Mem: 13740 12336 1404 0 1112
: 19700103-23-01 Mem: 13740 12336 1404 0 1112
: 19700104-00-01 Mem: 13740 12292 1448 0 1112
: 19700104-01-01 Mem: 13740 12264 1476 0 1112
: 19700104-02-01 Mem: 13740 12264 1476 0 1112
: 19700104-03-01 Mem: 13740 12344 1396 0 1112

:Also wirklich klar erkennbar ist ein Leak da nicht mehr. - Mit dem früheren Kernel hätte der Router nie 3 Tage uptime erreicht, weil er schon nach etwas mehr als einem Tag out of RAM rebooted hätte.

:Ein bissi was zu tun gehabt hat er auch in der Zeit:

: root@FoneraBridge:/tmp# tc -s qdisc
: qdisc pfifo_fast 0: dev eth0 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
: Sent 8380773865 bytes 8282658 pkt (dropped 0, overlimits 0 requeues 0)
: rate 0bit 0pps backlog 0b 0p requeues 0
: qdisc prio 11: dev wifi0 root bands 3 priomap 2 2 2 2 2 2 1 1 2 2 2 2 2 2 2 2
: Sent 2176364281 bytes 2584495 pkt (dropped 0, overlimits 0 requeues 534)
: rate 0bit 0pps backlog 0b 0p requeues 534
: qdisc pfifo 10: dev wifi0 parent 11:1 limit 195p
: Sent 495379536 bytes 456544 pkt (dropped 0, overlimits 0 requeues 34)
: rate 0bit 0pps backlog 0b 0p requeues 34
: qdisc pfifo 20: dev wifi0 parent 11:2 limit 195p
: Sent 52648133 bytes 88524 pkt (dropped 0, overlimits 0 requeues 3)
: rate 0bit 0pps backlog 0b 0p requeues 3
: qdisc pfifo 30: dev wifi0 parent 11:3 limit 195p
: Sent 1628336612 bytes 2039427 pkt (dropped 0, overlimits 0 requeues 497)
: rate 0bit 0pps backlog 0b 0p requeues 497

Folgender Kernel hat das Problem:
/ # uname -a
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown

während bei diesem Kernel noch kein Leak nachweisbar war (ca.
12 Stunden laufzeit):
/ # uname -a
Linux OpenWrt 2.6.26.2 #2 Tue Aug 12 19:47:19 CEST 2008 mips unknown

(allerdings lief dieser kenel ohne bridge_nf ??)

Update:
allerdings mit bridge_nf weisen auch 2.6.26.5er Kernel noch leaks auf, darum läuft nun auf einer testbridge (garten94-heusued) ein automatischer reboot nach 24h oder bei weniger als 1MB freien Speicher, zwar keine elegante Lösung, aber zumindest kann man nun mal den router einfach laufen lassen und abwarten ob wenigsten die wlan probleme (siehe unten) Geschichte sind,..

Mit folgendem Skript habe ich getestet:

/etc/freelog.sh:
#!/bin/sh

echo -n $(date '+%Y%m%d-%H-%M') >>/tmp/freelog
free | grep Mem: >>/tmp/freelog

/etc/crontabs/root:
01 * * * * /etc/freelog.sh

Das ist natürlich nur eine sehr grobe Messmethode und cron hat auch selber einiges an RAM-Verbrauch, aber nach einiger Zeit sieht man trotzdem ob eine Firware betroffen ist oder nicht, ohne einen Absturz abwarten zu müssen...

BTW, /tmp/freelog liegt in der RAM disk, ist also nach einem Absturz weg - also regelmäßig wegsichern oder regelmäßig nachschauen.

====Daten von g4====
/ # uname -a
Linux OpenWrt 2.6.21.5 #1 Wed Jul 23 12:51:05 CEST 2008 mips unknown

Kurz nach dem reboot der bridge sagt free:
total used free shared buffers
Mem: 13612 8332 5280 0 768
Swap: 0 0 0
Total: 13612 8332 5280

/tmp/freelog bis kurz vorm Absturz:
20000101-10-12 Mem: 13612 10028 3584 0 768
20000101-11-01 Mem: 13612 10160 3452 0 768
20000101-12-01 Mem: 13612 10196 3416 0 768
20000101-13-01 Mem: 13612 10020 3592 0 768
20000101-14-01 Mem: 13612 10024 3588 0 768
20000101-15-01 Mem: 13612 10156 3456 0 768
20000101-16-01 Mem: 13612 10184 3428 0 768
20000101-17-01 Mem: 13612 10220 3392 0 768
20000101-18-01 Mem: 13612 10268 3344 0 768
20000101-19-01 Mem: 13612 10388 3224 0 768
20000101-20-01 Mem: 13612 10508 3104 0 768
20000101-21-01 Mem: 13612 10588 3024 0 768
20000101-22-01 Mem: 13612 10624 2988 0 768
20000101-23-01 Mem: 13612 10832 2780 0 768
20000102-00-01 Mem: 13612 11160 2452 0 768
20000102-01-01 Mem: 13612 12324 1288 0 768

===Fehlermeldung: no xmit buf===
Dieses Problem scheint unabhängig vom (noch) vorhanden Arbeitsspeicher aufzutreten. Folgendes findet sich in logread, wenn die bridge aufhört, traffic am wifi Interface zu senen. Von g4 mit kernel 2.6.21.5:

Jan 2 01:12:08 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:09 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:20 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:24 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:28 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:12:40 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:13:43 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:13:55 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:14:22 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 2 01:14:25 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf

Und dies stammt von garten94 von der mit der seriellen Konsole überwachten Fonera (Kernel wieder 2.6.21.5):
Jan 1 15:53:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:06 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:54:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 15:55:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
.
.
.
Jan 1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:45 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:29:54 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.warn kernel: ath_mgtstart: discard, no xmit buf
Jan 1 16:30:07 OpenWrt user.info kernel: NETDEV WATCHDOG: wifi0: transmit timed out
/ # date
Sat Jan 1 16:33:36 UTC 2000
root@OpenWrt:/# free
total used free shared buffers
Mem: 13612 9012 4600 0 768
Swap: 0 0 0
Total: 13612 9012 4600

Anscheinend hat der WATCHDOG das Problem nach über einer halben Stunde downtime wieder behoben...

Im Zusammenhang mit diesem Problem kann auch ein irrsinnig hoher requeues counter beobachtet werden - das kann beim Debuggen nützlich sein

Arbeitsgruppe FoneraPlus

2008-10-25T21:20:16Z

HaraldG: Anleitung: aktivieren von rdate

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.3.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Wer gerne eine aktuelle Zeit auf seinem Router hat, kann auch noch folgendes machen:

/etc/init.d/wait4default enable
/etc/init.d/rdate enable

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe FoneraPlus

2008-10-23T17:08:55Z

HaraldG: Update für 0xff-config 0.3

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* statische IPs für LAN/WAN
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates
* traffic priorization: OLSR traffic vor allem anderen

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/olsr-minimal.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.3.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.3.tgz

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.3.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei olsr-minimal.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp olsr-minimal.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf olsr-minimal.tgz
opkg install libpthread_XXX_mips.ipk
opkg install olsrd_XXX_mips.ipk
opkg install olsrd-mod-httpinfo_XXX_mips.ipk
opkg install olsrd-mod-txtinfo_XXX_mips.ipk
/etc/init.d/olsr-ff enable # Starte olsrd beim booten
/etc/init.d/olsr-ff start # Starte olsrd jetzt!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel tcpdump) zu installieren:

opkg update
opkg install foo
opkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* testen
* Noch mehr testen
* ?

Arbeitsgruppe Software AdhocBridge

2008-08-27T18:53:52Z

HaraldG: Hinweis auf requeues Statistik zum Debuggen

Arbeitsgruppe IPv6 im Mesh

2008-08-24T19:27:55Z

HaraldG: Unsere 6to4 Adresse ist wirklich /16

Arbeitsgruppe Software AdhocBridge

2008-08-21T23:05:12Z

HaraldG: Memoryleak, und wifi Probleme

Arbeitsgruppe IPv6 im Mesh

2008-08-21T01:40:09Z

HaraldG: init skript für 6to4 auf FFF

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

=Was wir schon haben=
* Einen großen Block IP6 Adressen
* natives IP6 im housing
* öffentliche IP4 Adressen auf allen Routern

=Probleme=
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.

=Lösungsvorschläge=
==6to4 Tunnel==
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

===Vorteile===
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
* Die Infrastruktur von IPv4 kann mitbenutzt werden
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
* Es funktioniert mit allen relevanten Firmwares

===Nachteile===
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
* Ein 6to4 anycast server in unserer Nähe wäre fein
* Es wird eine öffentliche IPv4 Adresse benötigt

===Funktionsweise beim Routen eines Pakets===
Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

===Let's do it===
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:

PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo MYIP | tr "." " ") )

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:

ip tunnel add tun6to4 mode sit ttl 64 remote any local MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router:
ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC:
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter [[#Adressautokonfiguration | unten]].

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
ping6 marvin.funkfeuer.at

===Dauerhafte Konfiguration für FFF===
Folgendes Skript stellt die obige Konfiguration bei einem Neustart wieder her. Die Parameter am Beginn müssen natürlich für jeden Router angepasst werden (Mag wer ein .ipk mit einer Seite für's webinterface schreiben?).

/etc/init.d/S556to4
#!/bin/sh

MYIP="127.43.233.17"
PREFIX="2002:7f2b:e911"
LANDEV="vlan0"

case $1 in
start)
ip tunnel add tun6to4 mode sit ttl 64 remote any local $MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

ip -6 addr add $PREFIX:1::1/64 dev $LANDEV
;;

stop)
ip tunnel del tun6to4
ip -6 addr del $PREFIX:1::1/64 dev $LANDEV
;;

*)
echo "Usage: $0 {start|stop}"
exit 1
;;
esac

===Offene Fragen===
* Wie gut funktioniert pathmtu discovery?
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
* Eigener anycast server für Funkfeuer?
* DNS für IP6 Adressen?

=Lokale IPv6 Konfiguration=
==Adressautokonfiguration==
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement daemon (radvd)'' laufen, der den Router im Netz ankündigt.

===Installation des radvd===
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0.0, br0, br-lan, ...) verwenden, herausfinden:

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
inet6 fe80::216:1ff:fe92:8bf2/64 scope link
inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:

interface vlan0
{
AdvSendAdvert on;
prefix 2002:c1ee:9eb2:1::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden:

/etc/init.d/S51radvd start #Freifunkfirmware
/etc/init.d/radvd start #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

==Firewall==
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

=Weitere Quellen=
* http://debienna.at/IPv6to4
* http://wiki.debian.org/DebianIPv6
* http://wiki.openwrt.org/IPv6_howto

Arbeitsgruppe Software AdhocBridge

2008-08-19T17:37:26Z

HaraldG: Daten Memoryleak g4

Arbeitsgruppe Software AdhocBridge

2008-08-19T03:30:00Z

HaraldG: Memoryleak

Fonera

2008-08-19T03:13:22Z

HaraldG: Link auf die Arbeitsgruppe Fonera+

<google>WIKI</google>

=About=
Adrian Dabrowski hat auf der Funkfeuer Convention am 24.11.2006 einen Vortrag über Hardware Hacking gehalten, in dem es auch um die Fonera ging. Die Folien kann man hier downloaden:

http://convention.funkfeuer.at/wp-content/uploads/funkfeuer-convention-hardware-hacking-adrian-dabrowski.pdf

Die Fonera ist ein Wlan Router, der von http://www.fon.com verwendet wird, um mit dem Internetzugang anderer Leute Geld zu verdienen.

Die Fonera kostet € 34,44 und ist damit im Bereich der günstigeren Router

es gibt schon einige Möglichkeiten die Fonera Firmware zu ändern,

zum Beispiel einfach das bestehende Betriebsystem verändern,

es gibt jedoch auch schon Lösungen die ein komplett neues Betriebssystem aufspielen.

Es wird wohl nicht mehr lange dauern, bis fertige Software zur Verfügung steht, wie es bei den Linksysen bekannt ist,
die Frage ist, ob FON nicht einiges dagegen unternehmen wird, z.b Änderung der Hardware.

Wichtig ist deshalb, dass man eine neue Fonera nicht erst ins Internet lässt, sondern gleich "bearbeitet"

===Nachteile===
* die Fonera ist eigendlich nicht dazu gedacht, dass man damit herumspielt, deshalb kommt man nur über Tricks hinein
* die Fonera hat ein extrem langsames Flash, das booten dauert länger als das Flashen bei einem WRT54GL ;-)
* die Pakete die es momentan gibt, sind fast alle experimentell, deshalb gibt es noch keine Webinterfaces etc. (es wird daran aber schon sehr intensiv gearbeit)
* die Originalfirmware ist auf USA eingestellt, damit sind nur die Kanäle 1-11 verfügbar, es wird daran gearbeitet...

=Systemeigenschaften im Originalzustand=

==Software==
* Linux 2.4.36
* 2 WIFI Netze
** Privat, WPA, Lokales LAN + Internet
** Public, Captive Portal, nur Internet
* Captive Portal: Chilli
* Phoning Home

==Hardware==
* MIPS CPU
* Router600mA @ 5V (3W)
* Atheros Chipset -> Linux MADWIFI
* PSMA Antenne, 2,2dbi
* Atheros -90/-93dbm.
zum Vergleich: Linksys -65dBm@54Mbps, -80dBm@11Mbps
* 8 MB Serial Flash / 16 MB Flash
* Low Cost

=Flashen=
==Die Version von FreiFunk (Sven Ola)==
'''es wurde bereits eine ausgereifte Version von FreiFunk entwickelt'''
hier zu finden:

[http://ipkg.funkfeuer.at/freifunk/fonera/ http://ipkg.funkfeuer.at/freifunk/fonera/] [http://ipkg.funkfeuer.at/freifunk/fonera/README.txt README]

bzw.

[http://download.berlin.freifunk.net/fonera/ http://download.berlin.freifunk.net/fonera/] [http://download.berlin.freifunk.net/fonera/README.txt README]

'''GUTES HOW-TO dazu: http://wiki.freifunk-hannover.de/Fonera_mit_OLSR'''

Wichtig: Aktivierung von '''IPv4Broadcast''':

mit z.b WinSCP auf dem Router einloggen und /etc/init.d/S83olsrd mit einem
beliebigen Texteditor bearbeiten.

nach

Interface $FF_DEVS
{

folgendes hinzufügen:

Ip4Broadcast 255.255.255.255

wer mit vi / vim vertraut ist kann das auch gern über ssh machen :-)

==Experimentelle 0xFF Firmware auf OpenWRT Basis==
Es gibt für die Fonera und Fonera+ eine experimentelle Firmware, die im Wesentlichen aus einem kamikaze + 0xFF spezifischer Konfiguration besteht. Details sind auf der Seite der [[Arbeitsgruppe_FoneraPlus]] zu finden.

Vorteil: Alle Sachen wie Ip4Broadcast, Kanal 13, etc funktionieren bereits mehr oder weniger out of the Box.

Nachteil: Es gibt kein Webinterface. Um die Benutzung von ssh und einem Texteditor kommt man nicht herum.

= Power over Ethernet =

die 2. Version der Fonera (2200 siehe Rückseite) mit 7,5V Stromanschluss (und schwarzem LAN Anschluss und dünnem Stecker)

kann ohne Probleme mit bis zu 13V betrieben werden, da sie intern einen Schaltregler hat, der sehr effizient arbeitet und auch bei höheren Spannungen nicht viel Wärme erzeugt.

Achtung beim Stecker, der markierte Draht ist Masse, am besten aber nochmal nachmessen.

'''Die 1. Version (2100) kann nicht so einfach per POE betrieben werden, der Längsregler würde wahscheinlich sofort durchbrennen.'''

=Über den Ethernet-Port der Fonera ins Netz - Dirty Hack=
== /etc/firewall.user ==
iptables -t nat -I PREROUTING -s 192.168.0.2 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.0.2 -j MASQUERADE
iptables -I INPUT -s 192.168.0.2 -j ACCEPT
iptables -I FORWARD -s 192.168.0.2 -j ACCEPT

== /etc/config/fon ==
#config network lan
# option mode static
# option ipaddr 192.168.10.1
# option netmask 255.255.255.0
# option dhcp 1

config network wan
option mode 'static'
option ipaddr '192.168.0.1'
option netmask '255.255.255.0'
# option gateway '192.168.0.1'
option dns '193.238.157.16'

== Client Konfiguration ==
IP: 192.168.0.2
Netmask: 255.255.255.0
Gateway: 192.168.0.1
DNS: 193.238.157.16

Voilá!

== Zwei Router im Verbund ==
Um 2 Router per Kabel miteinander zu verbinden einfach die IP Adresse des WLAN Interfaces auch für das WAN verwenden.

Nun per ssh auf den ersten Router verbinden und die Datei /etc/config/fon editieren.
#config network lan
# option mode static
# option ipaddr 192.168.10.1
# option netmask 255.255.255.0
# option dhcp 1

config network wan
option mode 'static'
option ipaddr '193.238.156.X' (Funkfeuer Adresse des Routers)
option netmask '255.255.252.0' (oder auch 255.255.255.0 bei einer 78.41.112.X Addresse)
# option gateway '193.238.0.1'
option dns '193.238.157.16'
option gateway ''

Nun muss noch eine Firewall Regel erstellt werden die den Tarffic ungefilter weiterleitet.
Dazu die Datei /etc/firewall.user um die folgenden Zeilen ergänzen.

iptables -I INPUT -i eth0 -j ACCEPT
iptables -I OUTPUT -o eth0 -j ACCEPT

Jetzt fehlt nur noch OLSR auf dem WAN Port zu aktivieren.

Dazu wird das Skript /etc/init.d/S83olsrd editiert.

Interface $FF_DEVS "eth0"
{

Nun muss der ganze Vorgang noch für den zweiten Router wiederholt werden.

=Links=
http://jauzsi.hu/2006/10/13/inside-of-the-fonera

http://wiki.freifunk-hannover.de/Fonera_mit_OLSR - FreiFunk Hannover WIKI

http://www.mariomix.net/mariomix-blog/2006/11/hacking-la-fonera-parte-3/ - Hacking Part 3

http://www.notmart.org/index.php/BlaBla/Hacking_la_fonera..._part_III - noch eine Anleitung Hacking Part 3, englisch

http://bingobommel.blogspot.com/ - Hacking Part 2

http://olsrexperiment.de/sven-ola/fonera/ - Sven-Ola's Pakete, OLSR

http://fon.rogue.be/lafonera-0.7.0-rev4/

http://fon.rogue.be/lafonera/

http://fon.rogue.be/lafonera-experimental/

http://www.art-xtreme.com/blog/20061017/activar-ssh-en-la-fonera/ - Serieller Hack

http://www.easy2design.de/bla/?page_id=98 - Wenn der Fonera die KernelPanic-Krankheit hat: Debricking and more :)

http://www.dd-wrt.com/wiki/index.php/LaFonera_Software_Flashing#Flashing - Fonera auf DD-WRT flashen (expert section)

http://mrmuh.blogspot.com/2006/11/updates-explained-and-bridging-mode.html - Brigding mit der Fonera (Interessant für Nutzung als WLAN-AP oder im Client-Mode (bridge) )

http://www.dd-wrt.com/wiki/index.php/LaFonera_Hardware_32MB_SDRAM_MOD - Nette sahe fuer bastler ;o)

http://www.dd-wrt.com/phpBB2/viewtopic.php?t=14747&highlight=olsr - DD-WRT mit OLSR !
ich hab OLSR mit DD-WRT nicht zum Laufen gebracht, Erfahrungsberichte? --[[Benutzer:Datacop|datacop]] 14:46, 21. Okt 2007 (CEST)

[[Category:Hardware]]

Arbeitsgruppe FoneraPlus

2008-08-19T02:55:05Z

HaraldG: Auch die normale Fonera wird von der Firmware unterstützt

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "ip" ist installiert, wie in der Freifunkfirmware
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

Die Firmware funktioniert auch mit der "normalen" Fonera. Dafür gibt es einen eigenen leicht veränderten Konfigtarball:
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera_0.1.tgz

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden. (Siehe Bemerkungen auf der [[Diskussion:Arbeitsgruppe_FoneraPlus|Diskussionsseite]])
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* traffic priorization: OLSR traffic vor allem anderen
* Größere Auswahl an Paketen kompiliern oder ausprobieren ob ein Pool von OpenWRT verwendet werden kann.
* ?

Arbeitsgruppe IPv6 im Mesh

2008-08-18T03:01:20Z

HaraldG: Tippfehler

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

=Was wir schon haben=
* Einen großen Block IP6 Adressen
* natives IP6 im housing
* öffentliche IP4 Adressen auf allen Routern

=Probleme=
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.

=Lösungsvorschläge=
==6to4 Tunnel==
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

===Vorteile===
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
* Die Infrastruktur von IPv4 kann mitbenutzt werden
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
* Es funktioniert mit allen relevanten Firmwares

===Nachteile===
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
* Ein 6to4 anycast server in unserer Nähe wäre fein
* Es wird eine öffentliche IPv4 Adresse benötigt

===Funktionsweise beim Routen eines Pakets===
Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

===Let's do it===
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:

PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo MYIP | tr "." " ") )

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:

ip tunnel add tun6to4 mode sit ttl 64 remote any local MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router:
ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC:
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter [[#Adressautokonfiguration | unten]].

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
ping6 marvin.funkfeuer.at

More coming soon ...

===Offene Fragen===
* Wie gut funktioniert pathmtu discovery?
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
* Eigener anycast server für Funkfeuer?
* DNS für IP6 Adressen?

=Lokale IPv6 Konfiguration=
==Adressautokonfiguration==
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement daemon (radvd)'' laufen, der den Router im Netz ankündigt.

===Installation des radvd===
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0.0, br0, br-lan, ...) verwenden, herausfinden:

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
inet6 fe80::216:1ff:fe92:8bf2/64 scope link
inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:

interface vlan0
{
AdvSendAdvert on;
prefix 2002:c1ee:9eb2:1::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden:

/etc/init.d/S51radvd start #Freifunkfirmware
/etc/init.d/radvd start #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

==Firewall==
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

=Weitere Quellen=
* http://debienna.at/IPv6to4
* http://wiki.debian.org/DebianIPv6
* http://wiki.openwrt.org/IPv6_howto

Arbeitsgruppe FoneraPlus

2008-08-18T02:47:53Z

HaraldG: Klammer vergessen

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden. (Siehe Bemerkungen auf der [[Diskussion:Arbeitsgruppe_FoneraPlus|Diskussionsseite]])
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* traffic priorization: OLSR traffic vor allem anderen
* Größere Auswahl an Paketen kompiliern oder ausprobieren ob ein Pool von OpenWRT verwendet werden kann.
* ?

Arbeitsgruppe FoneraPlus

2008-08-18T02:47:15Z

HaraldG: Link auf Diskussionsseite

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden. (Siehe Bemerkungen auf der [[Diskussion:Arbeitsgruppe_FoneraPlus|Diskussionsseite]]
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* traffic priorization: OLSR traffic vor allem anderen
* Größere Auswahl an Paketen kompiliern oder ausprobieren ob ein Pool von OpenWRT verwendet werden kann.
* ?

Arbeitsgruppe IPv6 im Mesh

2008-08-18T02:37:04Z

HaraldG: Link zu Autokonfig mit radvd

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

=Was wir schon haben=
* Einen großen Block IP6 Adressen
* natives IP6 im housing
* öffentliche IP4 Adressen auf allen Routern

=Probleme=
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.

=Lösungsvorschläge=
==6to4 Tunnel==
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

===Vorteile===
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
* Die Infrastruktur von IPv4 kann mitbenutzt werden
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
* Es funktioniert mit allen relevanten Firmwares

===Nachteile===
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
* Ein 6to4 anycast server in unserer Nähe wäre fein
* Es wird eine öffentliche IPv4 Adresse benötigt

===Funktionsweise beim Routen eines Pakets===
Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

===Let's do it===
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:

PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo MYIP | tr "." " ") )

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:

ip tunnel add tun6to4 mode sit ttl 64 remote any local MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router:
ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC:
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Anstatt am PC händisch IP und route einzutragen kann man auch die Autokonfiguration von IPv6 verwenden. Siehe dazu die Anleitung weiter [[#Adressautokonfiguration | unten]].

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
ping6 marvin.funkfeuer.at

More coming soon ...

===Offene Fragen===
* Wie gut funktioniert pathmtu discovery?
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
* Eigener anycast server für Funkfeuer?
* DNS für IP6 Adressen?

=Lokale IPv6 Konfiguration=
==Adressautokonfiguration==
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement deamon (radvd)'' laufen, der den Router im Netz ankündigt.

===Installation des radvd===
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0.0, br0, br-lan, ...) verwenden, herausfinden:

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
inet6 fe80::216:1ff:fe92:8bf2/64 scope link
inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:

interface vlan0
{
AdvSendAdvert on;
prefix 2002:c1ee:9eb2:1::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden:

/etc/init.d/S51radvd start #Freifunkfirmware
/etc/init.d/radvd start #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

==Firewall==
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

=Weitere Quellen=
* http://debienna.at/IPv6to4
* http://wiki.debian.org/DebianIPv6
* http://wiki.openwrt.org/IPv6_howto

Arbeitsgruppe IPv6 im Mesh

2008-08-18T01:44:09Z

HaraldG: Beschreibung zu autokonfig

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----
und wenn dieses blöde Mediawiki nicht gerade meine Arbeite gefressen hätte, dann wäre hier auch schon ur viel zu lesen. *grml*

Es gibt ca. 2 Mrd. öffentliche IPv4 Adressen. Davon sind ca 74% unter der Kontrolle der USA, vom Rest hab' ich allein 5 bei Funkfeuer registriert und muss trotzdem NAT verwenden. Da dies eher unbefriedigend ist, wurde IPv6 entwickelt, das aber bisher noch nicht wirklich große Verbreitung gefunden hat. Was liegt also näher als diese neue Technologie in einem experimentellen Netz wie Funkfeuer auszuprobieren?

=Was wir schon haben=
* Einen großen Block IP6 Adressen
* natives IP6 im housing
* öffentliche IP4 Adressen auf allen Routern

=Probleme=
* Mittelfristig werden nicht alle Mesh-Router IP6 Forwarding unterstützen
* Die Routingtabelle für jedes Protokoll extra zu berechnen macht nicht wirklich viel Sinn
* Bei Verwendung einer klassischen Tunnellösung geht interner traffic vom Mesh zu einem zentralen Server und wieder zurück ins Mesh. Das ist nicht schön.

=Lösungsvorschläge=
==6to4 Tunnel==
Bei IPv6 gibt es einen eigenen Prefix (2002:/16) unter dem jeder IP4 Adresse ein (ziemlich großes) IP6 Subnetz zugeornet ist. Diese Adressen sind zum Übergang zwischen IPv4 und IPv6 gedacht.

===Vorteile===
* Es muss kein eigener IP6 Adressblock registriert/verwaltet werden
* Die Infrastruktur von IPv4 kann mitbenutzt werden
* Pakete zwischen Mesh Nodes gehen über den natürlichen Weg im Mesh
* Es funktioniert mit allen relevanten Firmwares

===Nachteile===
* Eigene IP6 Blöcke können nicht im Internat angekündigt werden
* Ein 6to4 anycast server in unserer Nähe wäre fein
* Es wird eine öffentliche IPv4 Adresse benötigt

===Funktionsweise beim Routen eines Pakets===
Wenn wir ein IP6 Route haben: Wir benutzen diese

Die Zieladdresse ist eine 6to4 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die IP4 Adresse des zuständigen Gateways.

Die Zieladdresse ist eine andere IP6 Adresse: Wir geben das Paket in ein 6to4 Tunnelpaket und senden dieses and die 6to4 anycast Adresse (192.88.99.1).

===Let's do it===
Zuerst müssen wir die Unterstützung für IPv6 in den Kernel laden:

ipkg install kmod-ipv6
insmod /path/to/ipv6.o

Als nächstes müssen wir für unsere IP4 Adresse den 6to4 Prefix berechnen. Dazu geben wir folgenden Befehl in eine Unix Shell (die Shell von freifunkfirmware genügt leider nicht, die von kamikaze schon) ein:

PREFIX=$(printf "2002:%02x%02x:%02x%02x" $(echo MYIP | tr "." " ") )

Zum Beispiel für die ip 78.41.112.63 ist das Ergebnis "2002:4e29:703f".

Als nächstes wollen wir das ganze einmal temporär konfigurieren, um es auszuprobieren. Dazu geben wir am Router die folgenden Befehle ein:

ip tunnel add tun6to4 mode sit ttl 64 remote any local MYIP
ip link set dev tun6to4 up
ip -6 addr add $PREFIX::1/16 dev tun6to4
ip -6 route add default via ::192.88.99.1 dev tun6to4

So, nun sollte der Router unter der IP6 Addresse $PREFIX::1 erreichbar sein. Damit wir das aber auch nutzen können, müssen
wir auch noch IPv6 am LAN konfigurieren. Wie das genau geht, hängt von der Firmware ab. Ich hab' bei mir folgendes gemacht.

Am Router:
ip -6 addr add $PREFIX:1::1/64 dev vlan0

Und am PC:
sudo ip -6 addr add $PREFIX:1::2/64 dev eth0
sudo ip -6 route add default via $PREFIX:1::1

Nun sollten wir vom PC aus die IPv6 Verbindung testen können, z.B. mit:
ping6 marvin.funkfeuer.at

More coming soon ...

===Offene Fragen===
* Wie gut funktioniert pathmtu discovery?
** Bei meinen bisherigen Tests (mit tracepath6 und ein paar Tage normale Nutzung) war's ok sowohl zu 6to4 Adressen als auch zu echten IP6 Adressen. - Tests in die andere Richtung wären aber auch noch nett.
* Bisher alle Tests ganz ohne Firewall (nicht einmal IPv4)
* Eigener anycast server für Funkfeuer?
* DNS für IP6 Adressen?

=Lokale IPv6 Konfiguration=
==Adressautokonfiguration==
Ein nettes Feature von IPv6 ist die automatische Konfiguration der Adressen auf den Clients durch das IPv6 Protokoll selbst (also ganz ohne DHCP). Damit das funktioniert, muss am Router allerdings ein sogenannter ''router advertisement deamon (radvd)'' laufen, der den Router im Netz ankündigt.

===Installation des radvd===
Der radvd wird sowohl von der Freifunkfirmware als auch von OpenWRT/kamikaze unterstützt. Nach einem

ipkg install radvd

befindet sich in /etc/radvd.conf eine Beispielkonfiguration, die noch an das System angepasst werden muss. Zunächst müssen wir den IPv6 Prefix, den wir am LAN-Interface (bei meinem Router ist das vlan0, bei anderen Routern heißt es vielleicht eth0.0, br0, br-lan, ...) verwenden, herausfinden:

root@OpenWrt:/etc# ip addr show dev vlan0
4: vlan0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
link/ether 00:16:01:92:8b:f2 brd ff:ff:ff:ff:ff:ff
inet 192.168.11.1/24 brd 192.168.11.255 scope global vlan0
inet6 fe80::216:1ff:fe92:8bf2/64 scope link
inet6 2002:c1ee:9eb2:1::1/64 scope global

Die globale inet6 Adresse ist das was uns interessiert. Die Adresse ist "2002:c1ee:9eb2:1::1", der Prefix ist "2002:c1ee:9eb2:1::/64" - ohne der letzten Eins in der Ausgabe von ip!

Diesen Prefix brauchen wir jetzt um am Router eine passende /etc/radvd.conf Datei zu erstellen. In meinem Fall sieht die Datei so aus:

interface vlan0
{
AdvSendAdvert on;
prefix 2002:c1ee:9eb2:1::/64
{
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
};
};

Das Interface und der Prefix sind entsprechend zu ersetzen!

Bei kamikaze müssen wir auch noch explizit aktivieren, dass der radvd beim Booten gestartet werden soll:
/etc/init.d/radvd enable

Jetzt muss der radvd noch gestartet werden:

/etc/init.d/S51radvd start #Freifunkfirmware
/etc/init.d/radvd start #kamikaze

Achtung: Der radvd ist sehr sparsam, was Fehlermeldungen betrifft. Wenn es nicht funktioniert den radvd am besten mit der Hand mit Debug level 5 starten.

radvd -d 5

In der Freifunkfirmware sieht man die Ausgabe von radvd nur mit dem Befehl logread.

==Firewall==
Leute, die ihren Usern (oder ihrem Betriebssystem) nicht vertrauen, wollen wahrscheinlich eine Firewall am Router haben. Will jemand eine passende Firewallkonfig vorschlagen?

=Weitere Quellen=
* http://debienna.at/IPv6to4
* http://wiki.debian.org/DebianIPv6
* http://wiki.openwrt.org/IPv6_howto

Arbeitsgruppe IPv6 im Mesh

2008-08-18T00:48:58Z

HaraldG: Formatierung, Rechtschreibung, Wortwahl überarbeitet

Diskussion:Arbeitsgruppe IPv6 im Mesh

2008-08-18T00:19:54Z

HaraldG: Antwort an uk

Diskussion:Arbeitsgruppe FoneraPlus

2008-08-17T18:19:04Z

HaraldG: Antwort @markus

Ad same IP:

(hab untriges jetzt zwar nicht verifiziert, glaub aber mich richtig zu erinnern)

Das mit fehlenden arp requests auf weiteren interfaces im selben subnet, ist doch "ueberall" so
also auf auch den fff buffalos und linksysen die trotzdem mit gleicher ip auf wan und wifi werkeln

d.h. solang nur subnetrouten eingetragen sind, kann man nur am "ersten" interface "arp-connectivity" erwarten,..
auf den anderen funktinoert nur das senden/lauschen auf broadcasts, oder eben more specific routen (z.b.: hostroutes)

da die vom olsrd eingetragneen hostrouten dann eh interface spezifisch (und klarerweise morte specific wie die subnetroute) sind, funktioniert das arp (zum nächsten router/gateway der eingetragenen routen) dann im endeffekt doch auch auf den anderen interfaces,..

d.h. ein standard linux kenel versucht nie auf mehreren interfaces paralell arp lookups zu machen, da er nur die erst(beste) route nimmt um sich für ein interface zu entscheiden,.. und eigentlich stört das im normalbetreib auch nicht weiter,..

allerdings könnt man auf den weiteren devices mit gleicher ip auch gleich /32 subnetmask einrtagen, denn die subnetroute selber funktinoert ja eh nicht so wie erwartet,..

lg MArkus

----

Hm, kann sein, dass mich das bei den Buffalos nie gebissen hat, muss ich einmal ausprobieren...

Idee war eigentlich, dass für ein typisches 0 8 15 Bastelsetup egal sein sollte ob man sich an den LAN oder WAN port hängt. Was hältst du davon als default config zwischen LAN und WAN eine bridge zu machen?

LG Harald

Arbeitsgruppe IPv6 im Mesh

2008-08-17T02:16:36Z

HaraldG: Kleine Syntaxkorrektur

Arbeitsgruppe FoneraPlus

2008-08-17T01:09:56Z

HaraldG: Wortwahl weniger abschreckend

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht primär für unerfahrene Benutzer gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* traffic priorization: OLSR traffic vor allem anderen
* Größere Auswahl an Paketen kompiliern oder ausprobieren ob ein Pool von OpenWRT verwendet werden kann.
* ?

Arbeitsgruppe FoneraPlus

2008-08-17T01:00:22Z

HaraldG: Schritte bis zu sinnvoller/offizieller Unterstützung der Fonera+

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht für Enduser gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

==Was noch fehlt==
Die folgenden Dinge müssen noch in einer Firmware implementiert werden, bevor die Fonera+ als unterstütze Hardware gelten kann:
* traffic priorization: OLSR traffic vor allem anderen
* Größere Auswahl an Paketen kompiliern oder ausprobieren ob ein Pool von OpenWRT verwendet werden kann.
* ?

Arbeitsgruppen

2008-08-17T00:51:54Z

HaraldG: Arbeitsgruppe Fonera+

Ein Working Wiki (kurz. WoW) ist im Grunde auch nur ein oder mehrere Wiki Seiten, allerdings über Dinge die noch w.i.p. ..

siehe auch: [[Arbeitsgruppe_WoW|Was ist ein WoW?]]

Und gleichzeitig eben mit der Einladung an alle daran Interresierten sich an diesem Inhalt noch ungezwungener als im restlichen Wiki auch schreiberisch zu beteiligen,..

Auch Fragen/Ideen und nicht nur Antworten/Inhalt sind auf diesen Seiten (oder der Diskussion) äusserst angebracht! (-;

=[[Arbeitsgruppe_Hardware|Hardware]]=
* [[Arbeitsgruppe_Hardware_Fonera_power|Fonera (Low Power)]] WoW
* [[Arbeitsgruppe_FoneraPlus|Fonera+]] WoW
* [[Arbeitsgruppe_Hardware_OSBRiDGE_5GXi|OSBRiDGE 5GXi]]
* [[Arbeitsgruppe_Hardware_SL75WLAN|SL75 WLAN]]
* [[Arbeitsgruppe_Hardware_RONJA|RONJA]]
** [[Arbeitsgruppe_Hardware_RONJA:Optischer_Kopf|RONJA - Optischer Kopf]]

=[[Arbeitsgruppe_Software|Software]]=
* [[Arbeitsgruppe_Software_DNS|DNS Probleme und Lösungen]] WoW
* [[Arbeitsgruppe_Software_AdhocBridge|Drahtlose Adhoc Netzwerke bridgen]] WoW
* [[Arbeitsgruppe_Software_Failure_Monitoring|Besseres Monitoring von Funknetz Ausfällen]] WoW
* [[Arbeitsgruppe_Software_PINGPERF|Bandwidth Tests mit ping]] WoW
* [[Arbeitsgruppe_IPv6_im_Mesh|IPv6 im Mesh]] WoW

=[[Arbeitsgruppe_Support|Support]]=
* [[FAQ]]
* [[Erste Schritte]]

=[[Arbeitsgruppe_Homepage|Homepage]]=

=[[Arbeitsgruppe_Funknetz|Funknetz]]=

=[[Arbeitsgruppe_Housing|Housing]]=

=[[Arbeitsgruppe_Backbone|Backbone]]=

=[[Arbeitsgruppe_Oberwelt|Oberwelt]]=
*[[Oberwelt:Ziel|Ziel]]
*[[Oberwelt:Veranstaltungen|Veranstaltungen]]
*[[Oberwelt:InfoMaterial|InfoMaterial]]

=[[Arbeitsgruppe_Verein|Verein]]=

=[[Arbeitsgruppe_VoIP|VoIP]]=

Arbeitsgruppe FoneraPlus

2008-08-17T00:49:04Z

HaraldG: Formatierungsfehler

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht für Enduser gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

Arbeitsgruppe FoneraPlus

2008-08-17T00:48:01Z

HaraldG: Bekannte Probleme

Achtung dies ist ein [[Arbeitsgruppe_WoW|WoW]] (Maintainer: siehe Changelog)
----

Auf dieser Seite sollen Informationen rund um die Fonera+ gesammelt werden: best practice Konfigurationen im Funknetz, neue Ideen, Probleme, Testergebnisse, Anleitungen. Dadurch sollen know how für den Einsatz im Funknetz gesammelt und die Weiterentwicklung von Firmwares vorangetrieben werden. Auch wenn diese Seite am Anfang nicht für Enduser gedacht ist, werden die Informationen hier für die Entwicklung einer Enduserfirmware nützlich sein.

=Hardware=
Die Fonera+ unterscheidet sich äußerlich von der Fonera fast nur durch einen zweiten Ethernetport und das wesentlich größere Gehäuse. Schraubt man die Fonera+ auf, so sieht man, dass die Platine schon für die Fonera2 (mit USB) vorbereitet sein dürfte. Es sind also keine großen Änderungen zur Fonera2 zu erwarten - ein Grund mehr warum gute Unterstützung für die Fonera+ sinnvoll erscheint.

Die Fonera+ wird seit einiger Zeit von OpenWRT unterstützt, aber nicht vom letzten Release kamikaze 7.09. Allerdings gibt es derzeit noch einige Mängel...

Gleichzeitig ist die Fonera+ auch zur Fonera weitgehend kompatibel geblieben. Auf der OpenWRT Wiki-Seite zur [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera Fonera] findet man viele Informationen die auch für die Fonera+ gelten.

=Experimentelle Firmware für 0xFF=
Um die Arbeit an der Fonera+ zu erleichtern, gibt es eine eigene Firmware für Funkfeuer, die jeder verwenden kann, der mit ssh/putty und einem Texteditor umgehen kann. Die Firmware orientiert sich möglichst nahe an OpenWRT, hat aber ein paar kleinere Änderungen um Experimente leichter zu machen:

* keine Firewall
* kein DHCP - Client (kommt bei der nächsten Version aber wieder falls Platz ist)
* Kein olsrd im read only Dateisystem, damit Tests mit verschienen Versionen leicht gemacht werden können
* webserver startet nicht (Bug in der Konfig, wird in der nächsten Version wieder gehen)
* Das Tool "patch" ist installiert, für einfache Konfigupdates

==Herunterladen==
Die Firmware besteht momentan aus folgenden Dateien:
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-vmlinux.lzma - das Kernelimage
* http://texas.funkfeuer.at/~harald/firmware/openwrt-atheros-root.squashfs - das read only Dateisystem
* http://texas.funkfeuer.at/~harald/firmware/0xff-atheros-minimal-ipk.tgz - Alle Pakete die notwendig sind, um den olsrd zu starten
* http://texas.funkfeuer.at/~harald/firmware/0xff-config-fonera+_0.1.tgz - tarball mit Konfiguration für Funkfeuer (olsr, Kanal 13 freischalten, etc.)

==Installation==
===Flashen===
Zuerst müssen das Kernelimage und das Dateisystem auf die Fonera+ geschrieben werden. Eine recht ausfühliche Anleitung gibt's im [http://wiki.openwrt.org/OpenWrtDocs/Hardware/Fon/Fonera OpenWRT-Wiki].

Für Experten: Der RedBoot der Fonera+ wartet auf der Adresse 192.168.1.1 und Port 9000 für 2 Sekunden auf eine Verbindung von 192.168.1.254.

===Konfiguration===
Nach dem Flashen wird die Fonera neu gestartet und wartet dann auf der Adresse 192.168.1.1 auf eine telnet Verbindung (diesmal standard telnet port). Sobald mit dem Befehl "passwd" ein Passwort gesetzt wird, kann man sich mit "ssh root@192.168.1.1" einloggen, dafür gibt es dann kein telnet mehr ...

Der Konfigtarball enthält ein vollständig lauffähiges Funkfeuersetup, allerdings sollten ein paar Dinge (zumindest die IP Adressen!) angepasst werden. Der Tarball kann einfach auf die Fonera+ kopiert und dann im Wurzelverzeichnis ausgepackt werden:

scp 0xff-config-fonera+_0.1.tgz root@192.168.1.1:/tmp/
cd /
tar -xzf /tmp/0xff-config-fonera+_0.1.tgz

Die zu ändernden Einstellungen sind durch spezielle Kommentare markiert, die mit grep leicht gefunden werden können:
grep -r Edit.this /etc ... diese Einstellung MUSS geändert werden
grep -r Maybe.edit.this /etc ... weitere Einstellungen wie Kanal
grep -ri edit.this /etc ... findet noch mehr

Wer sich mit dem auf der Firmware installierten vi nicht wohlfühlt, kann den Konfigtarball auch zuerst am PC entpacken, dort editieren und dann erst auf die Fonera+ transferieren. Aber Vorsicht beim Entpacken am PC: Der Tarball legt kein eigenes Unterverzeichnis an, weil er für das Entpacken im / des Routers vorbereitet ist.

===OLSR===
Der Router sollte jetzt eigentlich fertig konfiguriert sein, aber wir brauchen noch zusätzliche Software - insbesonder den olsrd - bevor er einsatzbereit ist. Um die Installation auf Routern ohne Internet zu erleichtern, gibt es die Datei 0xff-atheros-minimal-ipk.tgz, diese wird auf den Router kopiert, entpackt und die Pakete installiert:

am PC:
scp 0xff-atheros-minimal-ipk.tgz root@192.168.1.1:/tmp/
am Router:
cd /tmp
tar -xzf 0xff-atheros-minimal-ipk.tgz
ipkg install libpthread_XXX_mips.ipk
ipkg install olsrd_XXX_mips.ipk
/etc/init.d/olsrd enable # Starte olsrd beim booten
/etc/init.d/olsrd start # Starte olsrd jetzt!

Bei vorigem Schritt ist zu beachten: Da wir für den olsrd bereits eine Konfiguration aus dem Konfigtarball haben, müssen wir die Frage, ob wir die bestehende Konfiguration durch eine Neue ersetzen wollen mit Nein beantworten!

Spätestens jetzt sollten wir Internet auf unserem Router haben. Das heißt jetzt ist ein guter Zeitpunkt, um noch mehr Software (zum Beispiel das httpinfo plugin oder tcpdump) zu installieren:

ipkg update
ipkg install foo
ipkg install bar

Jetzt ist auch ein guter Zeitpunkt um den Router einmal neu zu starten und zu sehen, ob wirklich alles automatisch funktioniert wie es soll.

==Probleme==
Hier werden technische Mängel der Firmware gesammelt. Bei der Lösung ist enge Zusammenarbeit mit OpenWRT notwendig und sinnvoll. Je nach Möglichkeit bitte Verweise auf Tickets, Links, etc. einfügen.

* Der Ethernet Switch empfängt keine Daten, wenn eth0 nicht im promiscuous mode ist - sobald man auf einem Ethernet Interface
tcpdump startet geht alles. Als workaround wird derzeit auf einem der virtuellen Interfaces (meist eth0.0 - LAN) eine bridge angelegt.
* Wenn am LAN und am WAN Interface gleiche Subnetze vergeben werden, dann werden arp requests nur auf einem Interface gesendet, das andere hat dadurch defakto keine Konnektivität. Dies ist vermutich ein Problem des OpenWRT Kernels. Um das Problem zu umgehen müssen IPs aus verschiedenen Subnetzen verwendet werden.
* Der Switch ist momentan nicht konfigurierbar.
* Das Atheros Interface empfängt im promiscuous mode auch frames mit einer fremden BSSID solang der Kanal stimmt. Von diesem Problem sind auch die anderen Foneras betroffen. Vermutlich ein madwifi Problem. Workaround ist nicht notwendig, weil das Problem nicht besonders schlimm stört.

Arbeitsgruppe FoneraPlus

2008-08-17T00:26:47Z

HaraldG: Firmwareinstallationsanleitung fertig

Arbeitsgruppe FoneraPlus

2008-08-16T17:07:33Z

HaraldG: Beschreibung der 0xff Firmware

Arbeitsgruppe FoneraPlus

2008-08-16T15:32:51Z

HaraldG: Arbeitsgruppe Fonera+ angelegt

Arbeitsgruppe IPv6 im Mesh

2008-08-16T15:23:40Z

HaraldG: Kleine Ergänzungen

Arbeitsgruppen

2008-08-16T14:59:41Z

HaraldG: Arbeitsgruppe_IPv6_im_Mesh verlinkt

Ein Working Wiki (kurz. WoW) ist im Grunde auch nur ein oder mehrere Wiki Seiten, allerdings über Dinge die noch w.i.p. ..

siehe auch: [[Arbeitsgruppe_WoW|Was ist ein WoW?]]

Und gleichzeitig eben mit der Einladung an alle daran Interresierten sich an diesem Inhalt noch ungezwungener als im restlichen Wiki auch schreiberisch zu beteiligen,..

Auch Fragen/Ideen und nicht nur Antworten/Inhalt sind auf diesen Seiten (oder der Diskussion) äusserst angebracht! (-;

=[[Arbeitsgruppe_Hardware|Hardware]]=
* [[Arbeitsgruppe_Hardware_Fonera_power|Fonera (Low Power)]] WoW
* [[Arbeitsgruppe_Hardware_OSBRiDGE_5GXi|OSBRiDGE 5GXi]]
* [[Arbeitsgruppe_Hardware_SL75WLAN|SL75 WLAN]]
* [[Arbeitsgruppe_Hardware_RONJA|RONJA]]
** [[Arbeitsgruppe_Hardware_RONJA:Optischer_Kopf|RONJA - Optischer Kopf]]

=[[Arbeitsgruppe_Software|Software]]=
* [[Arbeitsgruppe_Software_DNS|DNS Probleme und Lösungen]] WoW
* [[Arbeitsgruppe_Software_AdhocBridge|Drahtlose Adhoc Netzwerke bridgen]] WoW
* [[Arbeitsgruppe_Software_Failure_Monitoring|Besseres Monitoring von Funknetz Ausfällen]] WoW
* [[Arbeitsgruppe_Software_PINGPERF|Bandwidth Tests mit ping]] WoW
* [[Arbeitsgruppe_IPv6_im_Mesh|IPv6 im Mesh]] WoW

=[[Arbeitsgruppe_Support|Support]]=
* [[FAQ]]
* [[Erste Schritte]]

=[[Arbeitsgruppe_Homepage|Homepage]]=

=[[Arbeitsgruppe_Funknetz|Funknetz]]=

=[[Arbeitsgruppe_Housing|Housing]]=

=[[Arbeitsgruppe_Backbone|Backbone]]=

=[[Arbeitsgruppe_Oberwelt|Oberwelt]]=
*[[Oberwelt:Ziel|Ziel]]
*[[Oberwelt:Veranstaltungen|Veranstaltungen]]
*[[Oberwelt:InfoMaterial|InfoMaterial]]

=[[Arbeitsgruppe_Verein|Verein]]=

=[[Arbeitsgruppe_VoIP|VoIP]]=

Arbeitsgruppe IPv6 im Mesh

2008-08-16T04:24:50Z

HaraldG: Anleitung: 6to4 testen

Arbeitsgruppe IPv6 im Mesh

2008-08-16T03:40:24Z

HaraldG: 6to4 basics

Arbeitsgruppe IPv6 im Mesh

2008-08-16T03:11:53Z

HaraldG: Beschreibung der Ausgangssituation

Arbeitsgruppe IPv6 im Mesh

2008-08-16T03:01:26Z

HaraldG: Einleitung und motivation

Arbeitsgruppe IPv6 im Mesh

2008-08-15T02:31:08Z

HaraldG: