Quelltext der Seite Benutzer:P424D0X/Blog:2010 August 19 23:48:33 CEST

=== IPv6 Versuche mit AHCP / OLSR ===

Mein letzter Blog liegt schon fast ein Jahr zurück (23. September 2009) und ich möchte, bevor Jemand etwas falsches von mir denkt und meint, daß das Projekt mit einem IPv6-ONI-Backbone gestorben ist, über den Fortschritt meiner Arbeiten in Form eines Blogs kund tun.. Es scheint, als hätte ich mein Vorhaben einige Zeit "auf Eis gelegt", da lange Zeit kein Statement von mir zu lesen war.. Doch habe ich vor meinem (wohlverdienten) Jahresurlaub u.a. auch an meinem WLan-IPv6-Labornetz weiter gebastelt und ich kann versichern, da wir auf einen guten Weg zu IPv6 sind.. Mich haben zwei, nein besser drei Gründe dazu bewogen, weiter in diese Richtung zu experimentieren.. Die Nachricht, das T-Mobile in den USA seinen Kunden bereits IPv6 anbietet, war für mich Grund genug zu denken, das es wohl nun nicht mehr lange dauern wird, bis natives IPv6 auch in Deutschland verfügbar sein wird.. Auch [[Benutzer:FischLan-Darss|Silvio]] hat mit seiner eMail das Thema mit IPv6 "neu angestoßen".. Und der letzte Grund, weshalb es nun mit IPv6 weiter geht ist der, das nun auch das Problem mit dem Kernel-Crash bei der Aktivierung einer WLan-Karte für IEEE802.11a von Seiten OpenWrt gelöst ist, sodaß ich mich voll und ganz nun IPv6 konzentrieren kann.. Aber genug der langen Worte!! Wie sieht es denn aus technischer Sicht aus, welche Hürden galt es zu überwinden und was habe ich bisher erreicht?!

Nun, aus meinem Urlaub zurückgekehrt, wurde das Problem mit dem Kernel-Crash durch die Entwickler bei OpenWRT bereits gelöst.. Dieses Problem trat auf, wenn versucht wurde ein Wifi-Interface unter dem neuen 2.6'er-Kernel zusammen mit den ath-Treibern in den IEEE802.11a-Modus zu bringen.. Die Maintainer hatten ziemlich lange an einer Lösung gebastelt, welche kurz nach meinem Urlaub fertiggestellt war.. Also habe ich mir den aktuellen OpenWRT Backfire svn branch aus dem Internet geladen, die Konfig entsprechend angepaßt, compiliert und geflasht.. Alles, wie gewohnt, ohne Probleme; bis dahin.. Meine Konfiguration für die IPv6-AP's hatte ich ja noch und lud die entsprechenden Dateien hoch, reboot und gucken, was auf dem Display meines Notebooks so alles zu lesen ist.. Anders als erwartet wurden die Konfigurationsdateien scheinbar nicht eingelesen, denn die Eingabe von iwconfig und ifconfig erbrachte für mich die Erkenntnis, das nichts konfiguriert wurde.. Doch UCI zeigte mir ein anderes Bild.. Die Konfigurationsdateien wurden zwar eingelesen, aber das System hat die Vorgaben aus UCI einfach nicht übernommen.. Das zeigte auch der Hostname.. Hätte eigentlich AP220 oder AP169 lauten müssen, war aber openwrt.. Also habe ich die alte .config über Board geschmissen und auch das Verzeichnis /usr/local/src/backfire entfernt.. Nun also kein Update, sondern alles von vorn.. Aktuellen OpenWRT Backfire svn branch nach /usr/local/src/backfire geladen, die feeds konfiguriert und Pakete nachgeladen, neues nach meinen Vorstellungen angepaßte .config erzeugt und das Image kompiliert und geflasht.. Siehe da, alles funktioniert wieder so, wie es soll; zumindest das einlesen der Konfigurationsdateien, nachdem einige Fehler beim einlesen der network und wireless bereinigt worden sind.. Was lernen wir daraus?! Besser neues svn-branch laden, als upzudaten!! ;-)

Jetzt gab es aber das nächste Problem mit dem CRDA; also der RegDom!! Es führte augenscheinlich kein Weg daran vorbei, daß das System die RegDom auf "AM" setzt.. Damit konnte ich auf Ch:140 und einigen weiteren keinen IBSS-Mode aktivieren.. Auch der Trick, die RegDom als Parameter an cfg80211 zu übergeben half nichts, bis ich herausgefunden habe, das der Fehler nicht in der Konfiguration zu suchen war, sondern im Image selbst.. Wieder hieß es neu kompilieren!! :-/ Doch nun gab es nach aktivieren der Wifi-Karten schon wieder einen Kernel-Crash!!  :-(  Wieso?? Ich hatte angenommen, das Problem mit IEEE802.11a unter Linux-2.6 und ath5k/ath9k sei behoben!! Da ich mich schon einige Stunden mit der Software beschäftigt hatte und keine Fehler fand, war mir danach an der Hardware weitere "Erkundungen" anzustellen.. Also habe ich die installierten CM9 gegen andere CM9 ersetzt, deren MAC einen möglichst großen Unterschied hatten.. Und was meint ihr, soll dadurch das Problem mit dem Kernel-Crash behoben sein?! JA!! Unglaublich, aber mit den CM9, welche diesen Crash verursachten, muß irgendetwas sein - ich werde später mal genauere Untersuchungen anstellen.. Was lernen wir daraus?? Nicht immer ist bei der Software der Fehler zu suchen, auch wenn er scheinbar von der Software herzukommen scheint.. ;-) Aber es hat sich ausgezahlt!! Alle WiFi-Interfaces werden korrekt konfiguriert:

Freq: 5.7GHz
Ch: 140
ESSID: ipv6.opennet-initiative.de
BSSID: 13:CA:0A:64:23:E7
Mode: IBSS

Bis hier hin meine Fortschritte bis zu einer lauffähigen physikalischen Verbindung.. Jetzt der noch nicht vollständig funktionierende Netzwerkteil.. Vielleicht ist unter den Leuten, welche diesen Blog lesen, jemand dabei, der sich mit IPv6 ein wenig auskennt und mir bei meinem Problem einen nützlichen Rat geben kann.. Ich wäre für jede Hilfe sehr dankbar.. Mein Problem hat aber nur am Rande mit IPv6 zu tun.. In erster Linie scheint es ein "hausgemachtes" Problem mit AHCP (AdHoc Configuration Protocol).. Ein Versuch mit statischen IPv6 ULA's und OLSR zeigt, das es sehr gut funktioniert; wie vor gut einem Jahr bei einem Laborversuch in der Frieda23.. Jetzt kommt zu OLSR mit IPv6 noch die Komponente AHCP hinzu.. Also AHCP und OLSR (AHCP/OLSR) zusammen.. Und genau hier tauchen meine Probleme beim automatischen generieren einer ULA für jedes Interface auf (ähnlich dem DHCP bei IPv4).. Jedem WLan-Interface sind einige Multicast-Adressen zugeordnet.. Einige, welche beim aktivieren des Interfaces automatisch angelegt werden (FF02::1, FF02::2 etc.), aber auch jeweils eine Multicast von den Prozessen OLSR und AHCP.. Die Frage, um welche sich meine Kopfschmerzen drehen ist die, warum die Interfaces keinen Präfix vom AHCP-Server erhalten (um daraus eine ULA zu erzeugen), obwohl alle Schnittstellen die korrekte Multicast besitzen und der AHCP-Server läuft und auch erreichbar ist.. Der AHCP-Server läuft auf AP169, und alle vier WLAN-Schnittstellen besitzen die Multicast vom AHCP-Prozess, doch ist auf allen Interfaces nur die LinkLocal (fe80::/16) zu sehen.. Auf dem Nachbar-AP (AP220) fast genau das gleiche Spiel..  Auf allen WiFi-Interfaces ist die korrekte Multicast (AHCP) eingestellt, doch nur das letzte WLAN-Interface generiert daraus eine ULA.. Bei den restlichen Schnittstellen (wlan0 - wlan2) genau das gleich, wie das bei AP169 gesagte.. Trotzdem bringt die Eingabe von "ip -6 neigh show" (ähnlich dem ARP bei IPv4) schon gute Resultate.. Es sind zwei bis drei Nachbarn zu sehen.. Natürlich nur vom AP gegenüber, aber auf verschiedenen WiFi-Interfaces.. Und selbst ein Ping klappt.. Natürlich noch nicht mit der ULA, weil nur eine einzige ULA erzeugt wurde (s.o.).. Aber ein Ping mit der LinkLocal-IP vom Nachbar-AP funktioniert schon sehr gut, obwohl die Laufzeiten sehr schwanken.. Das mag aber daran liegen, das an die CM9-Module nur Pigtails als Antennen angeschlossen sind.. Es ist auf dem Weg zum ONI-IPv6-Backbone wohl nun nur noch das bestehende Problem mit AHCP zu lösen.. Ich werde die Tage weiter daran basteln..  Stay tuned!!!

Wie wird es weitergehen, wenn IPv6 mit AHCP/OLSR zufriedenstellend funktioniert?!  Ich habe mir überlegt, einen eigenständigen IPv6-Backbone innerhalb des Opennet aufzubauen, aber vollkommen unabhängig voneinander.. Dieser Backbone führt von DB0HRO nach AE21 via KKW und Z10.. An den IPv6-AP's bei den genannten Standorten wird nichts weiter angeschlossen, außer weitere IPv6-Verbindungen.. Das Produktivnetz muß von der IPv6-Insellösung vollkommen unbeeinflußt bleiben!! Zunächst werde ich das Avila bei DB0HRO (AP169) wieder in die Masthalterung einbauen.. Die WLan-Antennen bei DB0HRO wurden m.w. nicht gedreht oder gar abgebaut.. Von daher nur Plug und hoffentlich Play.. Gleichzeitig wird auf KKW-Seite ein zusätzlicher AP (Avila aus Vereinsbestand von meinem IPv6-Laborversuchen) ausschließlich für IPv6-Verbindungen installiert (AP220??/AP70??).. Ich Plane das ganze eine Woche laufen zu lassen um dann zu gucken, ob ein Ping auf die Gegenseite immer noch funktioniert (Langzeittest).. Bei Erfolg werde ich mein drittes und letztes Avila aus Vereinsbestand von den IPv6-Laborversuchen für die Installation bei Z10 vorbereiten und installieren.. Ich erwarte hier keine neue Probleme.. Ein Ping6 von DB0HRO nach Z10 sollte problemlos funktionieren.. Erst dann sollten wir die IPv6-Verbindung zwischen Z10 und AE21 realisieren und versuchen, Titan irgendwie als Gateway zwischen IPv6-Internet und IPv6-Opennet zu konfigurieren.. Außerdem wäre es von Vorteil, wenn bei AE21 ein weiterer AHCP-Server läuft.. Falls der eine bei DB0HRO mal ausfällt, ist immer eine Redundanz geschaffen.. Ich persönlich wäre sehr dafür, das auf jedem GW ein AHCP-Server läuft.. Ist dieser Anfang ersteinmal gemacht, wird das Opennet mit der Zeit; wie soll ich sagen?; sich selbst migrieren.. ;-)

Fragen, Anregungen und Kritiken bitte der Mailinglist, eMail oder im Gespräch beim Grillen..