Arbeitsgruppe Hardware RS: Unterschied zwischen den Versionen

Aus FunkFeuer Wiki
Wechseln zu: Navigation, Suche
(Status)
(Routerstation (RS) mit OxFF Firmware flashen)
 
(3 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
nette recht preisgünstige Hardware (evt. < 60€), shipped mit (modded) Openwrt, und somit evt. die eierlegende Wollmilchsau für ein Mesh,..
+
Nette, recht preisgünstige Hardware (evt. < 60€), shipped mit (modded) Openwrt und somit eventuell die eierlegende Wollmilchsau für ein Mesh.
  
 
3 Minipci Slots, 3 x LAN, 64MB RAM 680Mhz Ar7161 MIPS24K CPU, GPIO, Usb 2.0 Support, etc.
 
3 Minipci Slots, 3 x LAN, 64MB RAM 680Mhz Ar7161 MIPS24K CPU, GPIO, Usb 2.0 Support, etc.
  
Pro-Version mit Gbit, mehr RAM, 803af und SDIO wirds auch geben,..
+
Pro-Version mit Gbit, mehr RAM, 803af und SDIO wirds auch geben.
  
 
== Status ==
 
== Status ==
momentan ist mal eine RS vorhanden um sie auszutesten,..
+
Momentan ist mal eine RS vorhanden um sie auszutesten.
(momentan auf 193.238.158.180 am heusued verbaut und hoffentlich online)
+
(Momentan auf 193.238.158.180 am heusued verbaut und hoffentlich online)
  
Wlan scheint recht kompatibel mit üblichen Atheros 2.4 und 5ghz Minipcis zu sein,..
+
Wlan scheint recht kompatibel mit üblichen Atheros 2.4 und 5ghz Minipcis zu sein.
  
WDS-Links (zu Routerboards) funktionieren scheints nicht (wurde aber auch nciht gewissenhaft versucht), des weiteren muss man auf RouterOS Linkquality Werte verzichten etc, (so wie bei Routerboard-Osbridge ja auch)
+
WDS-Links (zu Routerboards) funktionieren scheints nicht (wurde aber auch nicht gewissenhaft versucht), des weiteren muss man auf RouterOS Linkquality Werte verzichten etc. (so wie bei Routerboard-Osbridge ja auch).
  
Die bisherigen groben wlan-probleme scheinen einerseits auf fehler in der config aber eben auch auf config-optionen zurückzuführen zu sein, welche beim auslesen von /etc/config/wireless von kamikaze scheinbar ignoriert bzw. falsch gesetzt werden,..
+
Die bisherigen groben WLAN-Probleme scheinen einerseits auf Fehler in der config aber eben auch auf config-Optionen zurückzuführen zu sein, welche beim auslesen von /etc/config/wireless von kamikaze scheinbar ignoriert bzw. falsch gesetzt werden.
  
 
Weiters scheint die RS ein Problem mit ihren RAM und ihrer CPU zu haben:
 
Weiters scheint die RS ein Problem mit ihren RAM und ihrer CPU zu haben:
und ist mit 180MB / Sekunde da ziemlich lahm (sogar ein WRT54G hat 750MB/Sek )
+
* ist mit 180MB / Sekunde da ziemlich lahm (sogar ein WRT54G hat 750MB/Sek )
mit neuen firmwares/bootloadern sollte es inzwischen 350MB/sek sein, und auch deutlich höhere cpu performance, und aktivierter write cache,.. aber trotzdem ddr ram sollte schneller sein,...
+
* mit neuen firmwares/bootloadern sollten es inzwischen  
 +
** 350MB/Sek sein  
 +
** und auch deutlich höhere CPU Performance
 +
** und aktivierter write cache
 +
Aber trotzdem: DDR-RAM sollte schneller sein.
  
Das RAM Problem besteht somit grossteils immer noch,
+
Das RAM Problem besteht somit grossteils immer noch.
  
die CPU war/ist übrigens so lahm, weil Debug-mode aktiv ist (in neueren Firmwares ist das behoben)
+
Die CPU war/ist übrigens so lahm, weil Debug-mode aktiv ist (in neueren Firmwares ist das behoben).
  
und nun ja - es dauert ne ziemliche Weile bis nach einem Reboot alles und der dropbear im speziellen wieder läuft,..
+
Und - nun ja - es dauert ne ziemliche Weile bis nach einem Reboot alles und der dropbear im speziellen wieder läuft.
  
aber alles in allem kann man die Dinger wohl verwenden *g (Markus)
+
Aber alles in allem kann man die Dinger wohl verwenden *g (Markus)
  
== How To get LuCI on the RS ==
+
== Routerstation (RS) mit OxFF Firmware flashen ==
  
=== RS flashen mit Redboot ===
+
=== Routerstation per TFTP flashen ===
  
==== PC seitige Vorbereitungen ====
+
Hier ist im original Schritt für Schritt beschrieben wie es funktioniert:
  
Zunächst müssen Rootfilesystem und Kernelimage hier heruntergeladen werden
+
http://wiki.openwrt.org/toh/ubiquiti/routerstation
  
http://texas.funkfeuer.at/~datacop/kamikaze/RS_trunk/
+
Hat bei mir nicht ganz so funktioniert und auch das Firmwareimage soll selbstverständlich auch jenes von OxFF sein.
 +
Also hier meine Vorgehensweise:
  
Hier die Dateien,
+
==== PC-seitige Vorbereitungen ====
''openwrt-ar71xx-root.squashfs'' (rootfilesystem)
+
''xxx'' (kernelimage)
+
herunterladen und speichern.
+
  
Selbstverständlich gibt es mehrere Möglichkeiten die Dateien auf die RS zu bekommen, die hier vorgestellte ist jedoch ganz praktikabel.
+
Die Dateien werden über einen TFTP-Server, der auf dem Heimcomputer läuft, von Bootloader der RS geholt und auf der RS abgelegt.
Die Dateien werden über einen TFTP-Server, der auf dem Heimcomputer läuft, von Redboot(Bootloader der RS) geholt.
+
Wie man einen solchen TFTP-Server zum laufen bringt, ist im WWW nach zu lesen und nicht all zu kompliziert. Unter windows gibt es z.B. Pumpkin.
Wie man einen solchen TFTP-Server zum laufen bringt, ist im WWW nach zu lesen und recht einfach.
+
Ich habe unter GNU/Debian Linux das program tftp verwendet. Installieren mit:
  
Hat man nun einen TFTP-Server am laufen, kopiert man die beiden Dateien das entsprechende Verzeichnis des Servers. Gleichzeitig sollte man die Dateinamen, der Einfachheit halber ändern. Ich habe rootfs und kernel verwendet wie hier Beispielsweise zu sehen ist.
+
sudo apt-get install tftp
  
z.B. Linux
+
Nun wird die 0xFF Firmware benötigt, diese findet man unter
user@galactica:/srv/tftp$ ls
+
kernel  rootfs
+
  
Für Windows gibt es Pumpkin, auch ein einfacher TFTP-Server
+
ftp://oe1xrw.ozw.wien.funkfeuer.at/Trunk/ar71xx/
  
Um sich mit der RS zu verbinden wird ein Terminalprogramm benötigt, z.B. minicom (Linux) oder putty (Windows). Einstellungen der RS sind 115200 8N1.
+
und zwar die Datei
  
==== RS seitige Vorbereitungen ====
+
'''openwrt-ar71xx-ubnt-rs-squashfs-factory.bin'''
  
Um sich mit der RS zu verbinden wird weiters ein Pegelkonverter (z.B. MAX232 benötigt und wenn am PC keine serielle Schnittstelle zur Verfügung steht, ein USB to Serial converter.
+
diese enthält das Dateisystem und gelichzeitig auch den Kernel
  
Verbindet (mit Kabeln) man nun die RS mit dem PC und öffnet minicom bzw. putty, und gibt der RS Strom, kann der Startvorgang von Redboot, und in weiterer Folge, des openWRT verfolgt werden.
+
Diese habe ich nun in den Ordner
  
Um in das Redboot zu kommen muss gleich nach anstecken des Stromes die Tastenkombination "Strg+C" gedrückt werde.
+
/srv/tftp
  
===== Nun zu Redboot =====
+
kopiert da dieser vom tftp server verwendet wird.
+
RedBoot bietet eine Vielzahl von Möglichkeiten, im folgenden werden nur die relevanten vorgestellt und kurz erläutert.
+
  
  RedBoot> fis list
+
Damit die RS und der Computer auch aufeinander zugreifen können muss am PC folgende IP-Adresse vergeben werden 192.168.1.x mit 2 < x < 255 und nicht 20 da 192.168.1.20 die RS ist. Ich habe die 192.168.1.30 verwendet.
  
gibt den Inhalt des Flash Speichers aus 
+
Hat man ein Pegelwandler zu Hand (z.B. MAX232 oder viel besser einen FTDI USB to Serial Wandler) kann man sich zur seriellen Schnittstelle der RS verbinden. Sehr informativ da die serielle
 +
Schnittstelle oft zum debuggen verwendet wird und hier alle wichtigen informationen drüber laufen. Ist aber lediglich optional zum flashen wird diese nicht benötigt. Einstellungen sind 115200 8N1.
  
Nun kann das rootfs geholt werden.
+
Unter windows sollte das ganze ähnlich funktinoieren, mit der ausnahmen, dass man mit pumpkin einfach ein wenig rum klickt, aber achtung ich habs nicht ausprobiert
  
RedBoot> load -r -v -b %{FREEMEMLO} -h 192.168.1.21 rootfs
+
==== RS-seitige Vorbereitungen ====
  
Hier wird die Datei rootfs, des TFTP-Servers, der auf dem HeimPC unter der 192.168.1.21 erreichbar ist (funktionieren LAN-Verbindung vorausgesetzt) geholt und temporär in den RAM gespeichert.
+
Spannungsversorgung per POE herstellen und gleichzeitig den RESET-Taster gedrückt halten. Die RS geht nun in den Recovery Modus und wartet das sie auf der 192.168.1.20 per tftp die neue Frimware bekommt,
 +
sollte nach spätestens 10 Sekunden soweit sein. Man erkennt es daran, dass die ersten 3 LEDS (3.3V , RF, WAN) nach 10 sekunden dauerhaft leuchten und das auch so bleiben, kein blinken oder flackern (außer man schick was per über die WAN Schnittstelle hin und her). Unmittelbar nach dem Anstecken, leuchten alle LEDs auf und blinken irgendwie, aber nach 10 sekunden leuchten lediglich die ersten 3. Sollte das nicht so sein ist die RS nicht im Recovery Mode.
 +
Die RS muss über die WAN Buchse (mit POE) angelossen sein.
  
RedBoot> fis delete rootfs
+
==== Flashen ====
  
Da noch ein alter Eintrag rootfs vorhanden ist, muss dieser gelöscht werden. Dies geschieht mit fis delete
+
Bei mir hat es wie folgt einwandfrei funktioniert:
  
... to be continued
+
Kommandozeile:                                                    Beschreibung
 +
* '''user@galactica:~:$ cd /srv/tftp'''   In das Verzeichnis des tftp-servers wechseln
 +
* '''user@galactica:/srv/tftp$ tftp 192.168.1.20'''                  Tftp-Programm starten und IP Addresse übergeben
 +
* '''tftp> binary'''                                                In den Binary modus versetzen
 +
* '''fttp> put openwrt-ar71xx-ubnt-rs-squashfs-factory.bin'''        Die Datei openwrt-ar71xx-ubnt-rs-squashfs-factory.bin senden
 +
* '''Sent 3146136 bytes in 3.2 seconds '''                          Bestätigung das die Daten angekommen sind
 +
* '''tftp> q'''                                                      Verlassen des tftp-Programms
 +
 
 +
Nun benötigt die RS noch ein weilchen (ca. 5 min) bis alle Daten auch richtig abgelegt und gespeichert sind.
 +
Die Daten werden nämlich zunächst lediglich in den RAM abgelegt was ziemlich schnell geht. Es muss jedoch alles noch richtig in den Flash geschrieben werden wozu noch einiges an Zeit benötigt wird da dieser um ein vielfaches langsamer ist als der RAM. Es ist kein Hardwarereset notwendig! Es wird automatisch ein Reset durchgeführt.
 +
 
 +
Sollte alles gut gehen ist die RS unter 192.168.1.1 auf der LAN1 Buchse (direkt neben der WAN (POE Buchse) erreichbar.
 +
 
 +
 
 +
==== Relevante Links ====
 +
 
 +
http://wiki.openwrt.org/toh/ubiquiti/routerstation    openWRT wiki Eintrag
 +
ftp://oe1xrw.ozw.wien.funkfeuer.at/Trunk              0xFF Firmware
 +
http://downloads.openwrt.org/backfire/10.03/          openWRT original Firmware
 +
http://ubnt.com/wiki/RouterStation                    ubnt wiki Eintrag
  
 
==Country Code==
 
==Country Code==
unter /etc/modules.d/50-madwifi
+
Unter /etc/modules.d/50-madwifi
 
   ath_pci countrycode=860
 
   ath_pci countrycode=860
  
ist allerdings der country code von Uzbekistan, imho alle in AT erlaubten kanäle sind freigeschalten, teilweise mit maximal 15db (5180..5320Mhz) ansonsten meist max. 17db was imho nicht weiter stört, und auch mit afaik mit 25mW erlaubte 5,8GHz Subband ist dabei (was in dem band genau erlaubt ist bitte selber nachprüfen bevor man daran denkt solche frequenzen einzustellen,...)
+
Ist allerdings der country code von Uzbekistan, imho alle in AT erlaubten Kanäle sind freigeschalten, teilweise mit maximal 15db (5180..5320Mhz) ansonsten meist max. 17db was imho nicht weiter stört, und auch mit AFAIK mit 25mW erlaubte 5,8GHz Subband ist dabei (was in dem Band genau erlaubt ist, bitte selber nachprüfen, bevor man daran denkt, solche Frequenzen einzustellen,...)
  
will man doch etwas korrekter sein dann
+
Will man doch etwas korrekter sein dann:
 
  ath_pci countrycode=276 outdoor=1
 
  ath_pci countrycode=276 outdoor=1
damit hat man dann die 5Ghz outdoor kanäle, und halt eben den countrycode usrer lieben nachbarn eingestellt (DE)
+
Damit hat man dann die 5Ghz Outdoor Kanäle, und halt eben den countrycode unsrer lieben Nachbarn eingestellt (DE).
will man indoor kanäle dann outdoor weglassen,.. und beides gleichzeitig am selben router gibts wohl nit *g
+
Will man Indoor-Kanäle, dann Outdoor weglassen. Beides gleichzeitig am selben Router gibts wohl nit *g
  
(nebenbei geht mit diesem code auch turbo modus recht problemlos sowohl in den indoor und outdoor kanälen, während mit 860 hatte ich da keinen Erfolg)
+
(Nebenbei geht mit diesem code auch turbo modus recht problemlos, sowohl in den Indoor- und Outdoor-Kanälen, während mit 860 hatte ich da keinen Erfolg)
  
AT hätte country_code von 040 aber damit gabs dann gleich nur noch 2.4ghz Kanäle )-;
+
AT hätte country_code von 040 aber damit gab es dann gleich nur noch 2.4ghz Kanäle )-;
  
 
==Turbo Mode==
 
==Turbo Mode==
geht im station betrieb klaglos, einfach den ap auf turbo mode stellen, und madwifi scannt es vonalleine und aktiviert turbo mode (zumindest auf den static turbo mode kanälen)
+
Geht im station Betrieb klaglos, einfach den ap auf turbo mode stellen und madwifi scannt es von alleine und aktiviert turbo mode (zumindest auf den static turbo mode Kanälen).
  
iwconfig zeigt dann IEEE 802.11Ta an ansgtelle von 802.11a,..  
+
iwconfig zeigt dann IEEE 802.11Ta an ansgtelle von 802.11a.
  
ansonsten könnte man turbo mode auch manuell konfigurieren,..
+
Ansonsten könnte man turbo mode auch manuell konfigurieren:
 
  iwpriv athX turbo 1
 
  iwpriv athX turbo 1
  iwpriv athX mode 5 (nur bei station mitunter notwendig damit sie sich mit nem turbo-mode ap verbinden)
+
  iwpriv athX mode 5 (nur bei station mitunter notwendig, damit sie sich mit nem turbo-mode ap verbinden)
  
 
==AP Forwarding==
 
==AP Forwarding==
auf 5ghz gibts ja kaum adhoc taugliche geräte (weil dann inkompatibel mit dfs), also bleibt idr nur noch wds mit "echter" mesh funktinoalität übrig, idr hat wds aber eh nur kompatibilitätsprobleme, oder macht eh wenig sinn und ptmp ist eh genug bzw. zuviel *g ( ... an hidden stations *g)  
+
Auf 5Ghz gibts ja kaum adhoc taugliche Geräte (weil dann inkompatibel mit dfs), also bleibt in der Regel nur noch wds mit "echter" mesh Funktinoalität übrig, in der Regel hat wds aber eh nur Kompatibilitätsprobleme, oder macht eh wenig Sinn und ptmp ist eh genug bzw. zuviel *g ( ... an hidden stations *g).
  
jedoch sollte in einem olsr netz eben idealerweise nur auf layer 3 geroutet werden und eben nicht vom ap die olsr broadcast der einen station wieder an die anderen station repeatet werden, und in folge dann aller andere traffic zwischen den clients,.. denn die link-kosten des olsr stimmen dann mit der realen doppelbelastung des mediums wiedermal nicht überrein,.. (im grunde ist das sogar noch ein bißchen schlimmer als ptp 5ghz bridges aneinanderzuhängen)
+
Jedoch sollte in einem OLSR-Netz eben idealerweise nur auf Layer 3 geroutet werden und eben nicht vom ap die OLSR-Broadcast der einen Station wieder an die anderen Station repeatet werden und in Folge dann aller andere Traffic zwischen den Clients. Denn die link-Kosten des OLSR stimmen dann mit der realen Doppelbelastung des Mediums wiedermal nicht überein (im Grunde ist das sogar noch ein bisschen schlimmer als PTP 5Ghz bridges aneinander zuhängen).
  
darum imho besser das forwarding/bridging am ap abdrehen,..
+
Darum imho besser das forwarding/bridging am ap abdrehen.
  
 
  iwpriv athX ap_bridge 0
 
  iwpriv athX ap_bridge 0
  
==Distance & Diversity & usw==
+
==Distance, Diversity, usw. ==
wie man derartige advanced wlan settings tatsächlich via /etc/config/wireless konfiguriert sollt ma noch rausfinden/fixen
+
wie man derartige advanced wlan settings tatsächlich via /etc/config/wireless konfiguriert, sollt ma noch rausfinden/fixen.
  
evt tun diese 3 zusammen was es soll
+
Eventuell tun diese 3 zusammen was es soll:
 
  option diversity 1
 
  option diversity 1
 
  option txantenna 1
 
  option txantenna 1
Zeile 126: Zeile 146:
 
  #0 = auto, 1 = antenna a, 2 = antenna b
 
  #0 = auto, 1 = antenna a, 2 = antenna b
  
fürs erste tuns aber cmdline utilities auch
+
Fürs erste tuns aber cmdline utilities auch
 
z.B.: http://wlanwifi.blogspot.com/2008/02/madwifi-utility-usage.html
 
z.B.: http://wlanwifi.blogspot.com/2008/02/madwifi-utility-usage.html
  
nützlich ists mal die distance einzustellen, sonst geht auf langen Strecken gar nix (denn default Setting ist für 301-600 Meter)
+
Nützlich ists mal die distance einzustellen, sonst geht auf langen Strecken gar nix (denn default Setting ist für 301-600 Meter):
  
 
  athctrl -i wifi0 -d 10000
 
  athctrl -i wifi0 -d 10000
  
oder nachdem man genug rumprobiert hat (Einstellungen ändern sich nur in 300 Meter Schritten)
+
Oder nachdem man genug rumprobiert hat (Einstellungen ändern sich nur in 300 Meter Schritten dann eben permanent in /etc/config/wireless in der wifiX section eintragen:
 
+
dann eben permanent in /etc/config/wireless in der wifiX section eintragen
+
  
 
  option 'distance' '10000'
 
  option 'distance' '10000'
  
da manche minipci, zumindest bei broadcasts, mitunter diversity mässig groben Unfug treiben (paketweise abwechselnd antenne A oder B),..
+
Da manche minipci, zumindest bei broadcasts, mitunter diversity mässig groben Unfug treiben (paketweise abwechselnd Antenne A oder B).
  
vermutlich weil sie normalerweise aufgrund der acks lernen welche antenne für welches ziel besser wäre, aber bei broadcasts gibts keien acks und darum besser fix einstellen, vorallem weil wir idr eh nur eine einzige antenne haben
+
Vermutlich weil sie normalerweise aufgrund der acks lernen, welche Antenne für welches Ziel besser wäre, aber bei broadcasts gibts keine acks und darum besser fix einstellen. Vor allem weil wir in der Regel eh nur eine einzige Antenne haben:
  
 
  echo "1" > /proc/sys/dev/wifi0/txantenna # 0 auto, 1 antenna a, 2 antenna b
 
  echo "1" > /proc/sys/dev/wifi0/txantenna # 0 auto, 1 antenna a, 2 antenna b
  
oder im /etc/config/wireless in der wifiX section
+
Oder im /etc/config/wireless in der wifiX Section:
  
 
  option 'diversity' '0' # 0 off, 1 on
 
  option 'diversity' '0' # 0 off, 1 on
Zeile 151: Zeile 169:
 
  option 'txantenna' '0' # Antenna identifier (0, 1 or 2) for emission.
 
  option 'txantenna' '0' # Antenna identifier (0, 1 or 2) for emission.
  
auch das Beschränken der Kanäle fürs scannen macht sinn, (z.B. nur 5G wenn man ne 5G Antenne aber ne abg Card hat)
+
Auch das Beschränken der Kanäle fürs Scannen macht Sinn (z.B. nur 5G wenn man ne 5G Antenne aber ne abg Card hat),
sonst dauert das Scannen nach der Gegenstelle (nach einem disconnent) immer sooo lange *g
+
sonst dauert das Scannen nach der Gegenstelle (nach einem disconnect) immer sooo lange *g
(allerdings hat untriges bis jetzt nie erwünschte Wirkung gezeigt, es wird weiterhin auch auf allen Frequenzbändern gescannt)
+
(Allerdings hat untriges bis jetzt nie erwünschte Wirkung gezeigt, es wird weiterhin auch auf allen Frequenzbändern gescannt):
  
 
  athchans -i ath0 1-2 #restrict channel search to 1-2
 
  athchans -i ath0 1-2 #restrict channel search to 1-2
  
oder man setzt wenigstens den mode im Konfigfile
+
Oder man setzt wenigstens den mode im Konfigfile:
 
   
 
   
 
  option 'hwmode' '11a'
 
  option 'hwmode' '11a'
  
 
== OLSR ==
 
== OLSR ==
Läuft klaglos drauf, und wenn man die Firewall abschaltet  
+
Läuft klaglos drauf und wenn man die Firewall abschaltet:
  
 
  /etc/init.d/firewall disable
 
  /etc/init.d/firewall disable
  
oder eben die zu restriktiven forwarding regeln abändert, dann passt alles, ansonsten ist ein kamikaze Router mit olsr eben ein böses blackhole,..
+
Oder eben die zu restriktiven forwarding Regeln abändert, dann passt alles, ansonsten ist ein kamikaze Router mit OLSR eben ein böses blackhole.
 +
 
 +
Weitere Details zur [[OLSR-Konfiguration]]
 +
 
 +
Allgemeines [[OLSR-Linux-Howto|Howto]] für OLSR unter Linux
  
weitere Details zur [[OLSR-Konfiguration]]
+
== Unbricking ==
 +
https://lists.openwrt.org/pipermail/openwrt-users/2009-May/000759.html
  
und allgemeines [[OLSR-Linux-Howto|Howto]] fuer OLSR unter linux
+
[[Category: WorkingWiki]]
 +
[[Category: Arbeitsgruppen]]
 +
[[Category: Arbeitsgruppe Hardware]]
 +
[[Category: Hardware]]

Aktuelle Version vom 29. August 2011, 11:18 Uhr

Nette, recht preisgünstige Hardware (evt. < 60€), shipped mit (modded) Openwrt und somit eventuell die eierlegende Wollmilchsau für ein Mesh.

3 Minipci Slots, 3 x LAN, 64MB RAM 680Mhz Ar7161 MIPS24K CPU, GPIO, Usb 2.0 Support, etc.

Pro-Version mit Gbit, mehr RAM, 803af und SDIO wirds auch geben.

Status

Momentan ist mal eine RS vorhanden um sie auszutesten. (Momentan auf 193.238.158.180 am heusued verbaut und hoffentlich online)

Wlan scheint recht kompatibel mit üblichen Atheros 2.4 und 5ghz Minipcis zu sein.

WDS-Links (zu Routerboards) funktionieren scheints nicht (wurde aber auch nicht gewissenhaft versucht), des weiteren muss man auf RouterOS Linkquality Werte verzichten etc. (so wie bei Routerboard-Osbridge ja auch).

Die bisherigen groben WLAN-Probleme scheinen einerseits auf Fehler in der config aber eben auch auf config-Optionen zurückzuführen zu sein, welche beim auslesen von /etc/config/wireless von kamikaze scheinbar ignoriert bzw. falsch gesetzt werden.

Weiters scheint die RS ein Problem mit ihren RAM und ihrer CPU zu haben:

  • ist mit 180MB / Sekunde da ziemlich lahm (sogar ein WRT54G hat 750MB/Sek )
  • mit neuen firmwares/bootloadern sollten es inzwischen
    • 350MB/Sek sein
    • und auch deutlich höhere CPU Performance
    • und aktivierter write cache

Aber trotzdem: DDR-RAM sollte schneller sein.

Das RAM Problem besteht somit grossteils immer noch.

Die CPU war/ist übrigens so lahm, weil Debug-mode aktiv ist (in neueren Firmwares ist das behoben).

Und - nun ja - es dauert ne ziemliche Weile bis nach einem Reboot alles und der dropbear im speziellen wieder läuft.

Aber alles in allem kann man die Dinger wohl verwenden *g (Markus)

Routerstation (RS) mit OxFF Firmware flashen

Routerstation per TFTP flashen

Hier ist im original Schritt für Schritt beschrieben wie es funktioniert:

http://wiki.openwrt.org/toh/ubiquiti/routerstation

Hat bei mir nicht ganz so funktioniert und auch das Firmwareimage soll selbstverständlich auch jenes von OxFF sein. Also hier meine Vorgehensweise:

PC-seitige Vorbereitungen

Die Dateien werden über einen TFTP-Server, der auf dem Heimcomputer läuft, von Bootloader der RS geholt und auf der RS abgelegt. Wie man einen solchen TFTP-Server zum laufen bringt, ist im WWW nach zu lesen und nicht all zu kompliziert. Unter windows gibt es z.B. Pumpkin. Ich habe unter GNU/Debian Linux das program tftp verwendet. Installieren mit:

sudo apt-get install tftp

Nun wird die 0xFF Firmware benötigt, diese findet man unter

ftp://oe1xrw.ozw.wien.funkfeuer.at/Trunk/ar71xx/

und zwar die Datei

openwrt-ar71xx-ubnt-rs-squashfs-factory.bin

diese enthält das Dateisystem und gelichzeitig auch den Kernel

Diese habe ich nun in den Ordner

/srv/tftp

kopiert da dieser vom tftp server verwendet wird.

Damit die RS und der Computer auch aufeinander zugreifen können muss am PC folgende IP-Adresse vergeben werden 192.168.1.x mit 2 < x < 255 und nicht 20 da 192.168.1.20 die RS ist. Ich habe die 192.168.1.30 verwendet.

Hat man ein Pegelwandler zu Hand (z.B. MAX232 oder viel besser einen FTDI USB to Serial Wandler) kann man sich zur seriellen Schnittstelle der RS verbinden. Sehr informativ da die serielle Schnittstelle oft zum debuggen verwendet wird und hier alle wichtigen informationen drüber laufen. Ist aber lediglich optional zum flashen wird diese nicht benötigt. Einstellungen sind 115200 8N1.

Unter windows sollte das ganze ähnlich funktinoieren, mit der ausnahmen, dass man mit pumpkin einfach ein wenig rum klickt, aber achtung ich habs nicht ausprobiert

RS-seitige Vorbereitungen

Spannungsversorgung per POE herstellen und gleichzeitig den RESET-Taster gedrückt halten. Die RS geht nun in den Recovery Modus und wartet das sie auf der 192.168.1.20 per tftp die neue Frimware bekommt, sollte nach spätestens 10 Sekunden soweit sein. Man erkennt es daran, dass die ersten 3 LEDS (3.3V , RF, WAN) nach 10 sekunden dauerhaft leuchten und das auch so bleiben, kein blinken oder flackern (außer man schick was per über die WAN Schnittstelle hin und her). Unmittelbar nach dem Anstecken, leuchten alle LEDs auf und blinken irgendwie, aber nach 10 sekunden leuchten lediglich die ersten 3. Sollte das nicht so sein ist die RS nicht im Recovery Mode. Die RS muss über die WAN Buchse (mit POE) angelossen sein.

Flashen

Bei mir hat es wie folgt einwandfrei funktioniert:

Kommandozeile: Beschreibung

  • user@galactica:~:$ cd /srv/tftp In das Verzeichnis des tftp-servers wechseln
  • user@galactica:/srv/tftp$ tftp 192.168.1.20 Tftp-Programm starten und IP Addresse übergeben
  • tftp> binary In den Binary modus versetzen
  • fttp> put openwrt-ar71xx-ubnt-rs-squashfs-factory.bin Die Datei openwrt-ar71xx-ubnt-rs-squashfs-factory.bin senden
  • Sent 3146136 bytes in 3.2 seconds Bestätigung das die Daten angekommen sind
  • tftp> q Verlassen des tftp-Programms

Nun benötigt die RS noch ein weilchen (ca. 5 min) bis alle Daten auch richtig abgelegt und gespeichert sind. Die Daten werden nämlich zunächst lediglich in den RAM abgelegt was ziemlich schnell geht. Es muss jedoch alles noch richtig in den Flash geschrieben werden wozu noch einiges an Zeit benötigt wird da dieser um ein vielfaches langsamer ist als der RAM. Es ist kein Hardwarereset notwendig! Es wird automatisch ein Reset durchgeführt.

Sollte alles gut gehen ist die RS unter 192.168.1.1 auf der LAN1 Buchse (direkt neben der WAN (POE Buchse) erreichbar.


Relevante Links

http://wiki.openwrt.org/toh/ubiquiti/routerstation openWRT wiki Eintrag ftp://oe1xrw.ozw.wien.funkfeuer.at/Trunk 0xFF Firmware http://downloads.openwrt.org/backfire/10.03/ openWRT original Firmware http://ubnt.com/wiki/RouterStation ubnt wiki Eintrag

Country Code

Unter /etc/modules.d/50-madwifi

 ath_pci countrycode=860

Ist allerdings der country code von Uzbekistan, imho alle in AT erlaubten Kanäle sind freigeschalten, teilweise mit maximal 15db (5180..5320Mhz) ansonsten meist max. 17db was imho nicht weiter stört, und auch mit AFAIK mit 25mW erlaubte 5,8GHz Subband ist dabei (was in dem Band genau erlaubt ist, bitte selber nachprüfen, bevor man daran denkt, solche Frequenzen einzustellen,...)

Will man doch etwas korrekter sein dann:

ath_pci countrycode=276 outdoor=1

Damit hat man dann die 5Ghz Outdoor Kanäle, und halt eben den countrycode unsrer lieben Nachbarn eingestellt (DE). Will man Indoor-Kanäle, dann Outdoor weglassen. Beides gleichzeitig am selben Router gibts wohl nit *g

(Nebenbei geht mit diesem code auch turbo modus recht problemlos, sowohl in den Indoor- und Outdoor-Kanälen, während mit 860 hatte ich da keinen Erfolg)

AT hätte country_code von 040 aber damit gab es dann gleich nur noch 2.4ghz Kanäle )-;

Turbo Mode

Geht im station Betrieb klaglos, einfach den ap auf turbo mode stellen und madwifi scannt es von alleine und aktiviert turbo mode (zumindest auf den static turbo mode Kanälen).

iwconfig zeigt dann IEEE 802.11Ta an ansgtelle von 802.11a.

Ansonsten könnte man turbo mode auch manuell konfigurieren:

iwpriv athX turbo 1
iwpriv athX mode 5 (nur bei station mitunter notwendig, damit sie sich mit nem turbo-mode ap verbinden)

AP Forwarding

Auf 5Ghz gibts ja kaum adhoc taugliche Geräte (weil dann inkompatibel mit dfs), also bleibt in der Regel nur noch wds mit "echter" mesh Funktinoalität übrig, in der Regel hat wds aber eh nur Kompatibilitätsprobleme, oder macht eh wenig Sinn und ptmp ist eh genug bzw. zuviel *g ( ... an hidden stations *g).

Jedoch sollte in einem OLSR-Netz eben idealerweise nur auf Layer 3 geroutet werden und eben nicht vom ap die OLSR-Broadcast der einen Station wieder an die anderen Station repeatet werden und in Folge dann aller andere Traffic zwischen den Clients. Denn die link-Kosten des OLSR stimmen dann mit der realen Doppelbelastung des Mediums wiedermal nicht überein (im Grunde ist das sogar noch ein bisschen schlimmer als PTP 5Ghz bridges aneinander zuhängen).

Darum imho besser das forwarding/bridging am ap abdrehen.

iwpriv athX ap_bridge 0

Distance, Diversity, usw.

wie man derartige advanced wlan settings tatsächlich via /etc/config/wireless konfiguriert, sollt ma noch rausfinden/fixen.

Eventuell tun diese 3 zusammen was es soll:

option diversity 1
option txantenna 1
option rxantenna 1
#0 = auto, 1 = antenna a, 2 = antenna b

Fürs erste tuns aber cmdline utilities auch z.B.: http://wlanwifi.blogspot.com/2008/02/madwifi-utility-usage.html

Nützlich ists mal die distance einzustellen, sonst geht auf langen Strecken gar nix (denn default Setting ist für 301-600 Meter):

athctrl -i wifi0 -d 10000

Oder nachdem man genug rumprobiert hat (Einstellungen ändern sich nur in 300 Meter Schritten dann eben permanent in /etc/config/wireless in der wifiX section eintragen:

option 'distance' '10000'

Da manche minipci, zumindest bei broadcasts, mitunter diversity mässig groben Unfug treiben (paketweise abwechselnd Antenne A oder B).

Vermutlich weil sie normalerweise aufgrund der acks lernen, welche Antenne für welches Ziel besser wäre, aber bei broadcasts gibts keine acks und darum besser fix einstellen. Vor allem weil wir in der Regel eh nur eine einzige Antenne haben:

echo "1" > /proc/sys/dev/wifi0/txantenna # 0 auto, 1 antenna a, 2 antenna b

Oder im /etc/config/wireless in der wifiX Section:

option 'diversity' '0' # 0 off, 1 on
option 'rxantenna' '0' # Antenna identifier (0, 1 or 2) for reception.
option 'txantenna' '0' # Antenna identifier (0, 1 or 2) for emission.

Auch das Beschränken der Kanäle fürs Scannen macht Sinn (z.B. nur 5G wenn man ne 5G Antenne aber ne abg Card hat), sonst dauert das Scannen nach der Gegenstelle (nach einem disconnect) immer sooo lange *g (Allerdings hat untriges bis jetzt nie erwünschte Wirkung gezeigt, es wird weiterhin auch auf allen Frequenzbändern gescannt):

athchans -i ath0 1-2 #restrict channel search to 1-2

Oder man setzt wenigstens den mode im Konfigfile:

option 'hwmode' '11a'

OLSR

Läuft klaglos drauf und wenn man die Firewall abschaltet:

/etc/init.d/firewall disable

Oder eben die zu restriktiven forwarding Regeln abändert, dann passt alles, ansonsten ist ein kamikaze Router mit OLSR eben ein böses blackhole.

Weitere Details zur OLSR-Konfiguration

Allgemeines Howto für OLSR unter Linux

Unbricking

https://lists.openwrt.org/pipermail/openwrt-users/2009-May/000759.html