BenBE's humble thoughts Thoughts the world doesn't need yet …

19.05.2011

ARP-Roaming: Infrastruktur ohne Infrastruktur

Filed under: Software — Schlagwörter: , , — BenBE @ 23:18:12

Eine der anspruchvollsten Aufgaben in einem Netzwerk ist die Verwaltung der Teilnehmer und das Routing von Informationen zwischen diesen. Ist diese Aufgabe in klassischen verdrahteten Netzwerken noch vergleichsweise einfach zu bewerkstelligen, da sich die Netztopologie nur selten ändert und daher in den meisten Fällen statisch behandelt werden kann, herrschen in WLANs sehr dynamische Bedingungen vor. Zu jedem Zeitpunkt kann ein Client dem Netzwerk beitreten, zu einem anderen Zeitpunkt wieder verlassen, oder bei größeren Netzwerken, wie sie z.B. in Firmen und Universitäten vorkommen sogar von einem Zugangspunkt zu einem anderen umziehen.

Bei diesen vergleichsweise komplexen Netzwerken, handelt es sich immer in der Regel um Infrastruktur-Netzwerke, also solche, bei denen ein zentraler Zugangspunkt den Zugriff der Teilnehmer verwaltet, Zeitscheiben für die Datenübertragung zuteilt oder andere Management-Aufgaben, wie die Sitzungsverwaltung übernimmt. Aber nicht in jedem drahtlosen Netzwerk gibt es diese zentrale Instanz. Ein sehr gutes Beispiel hierfür sind sogenannte Ad-hoc-Netzwerke, die wie ihr Name bereits vermuten lässt ad-hoc aus dem Nichts aus aufgebaut werden können. Nehmen an solch einem Netzwerk wenige Clients teil, sehen sich diese in den meisten Fällen und abgesehen von der Vergabe der passenden Netzwerk-Parameter (BSSID, ESSID, IP der Clients, Netmask und Gateway) ist nicht sonderlich viel zu beachten.

Spannender wird es jedoch, wenn nicht mehr alle Teilnehmer jeden anderen sehen und das Ad-hoc-Netzwerk als ein Mesh-Netzwerk zu betrachten ist. Ein Projekt, was sich mit dem Betrieb solcher Mesh-Netzwerke beschäftigt, ist Freifunk, dass in einer ganzen Reihe von Städten bereits meist kleinere, teils aber auch größere Ad-hoc-Netzwerke aufzuweisen hat. In diesen Netzen muss typischerweise jeder am Routing teilnehmen, um ein Datenpaket vom Absender zum Empfänger zu befördern, da es im Gegensatz zu Infrastruktur-Netzwerken kein zentrales Routing gibt und daher sich die Clients untereinander kooperativ um alle Verwaltungsaufgaben kümmern müssen. Die Aufgabe des Routings ist dabei relativ unproblematisch über eine Reihe von Protokollen geregelt, von denen OSPF, OLSR und BATMAN die am Häufigsten eingesetzten sind. Diese funktionieren aber allesamt nur, wenn alle zu routenden Clients sich auch am Protokoll beteiligen und regelmäßig ihre Informationen dem Netz mitteilen.

Ein relativ neuer Weg, der derzeit vom Freifunk Chemnitz beschritten wird, ist es nun, auch Clients ohne Routing-Software den Zugang zum Netz zu ermöglichen. Die hierfür eingesetzte Technik des ARP-Roaming ähnelt ein wenig dem Vorgehen in Infrastruktur-Netzwerken, denn der Client wird von den Routern „verwaltet“ und wenn nötig zwischen diesen umgezogen, wenn sich seine Position im Netzwerk ändert. Damit dies auch ohne Infrastruktur-Modus in einem Ad-hoc-Netzwerk funktioniert, müssen jedoch eine Reihe von Bedingungen erfüllt sein.

Eine der wichtigsten Bedingungen, damit man einen Client ohne Probleme von einem zum anderen Router umziehen kann, ist, dass der Client möglichst wenig davon mitbekommt. Insbesondere der Standard-Gateway sollte aus Sicht des Clients an jeder Stelle des Netzes identisch sein. Zu diesem Zweck wird beim Freifunk Chemnitz im Ad-hoc-WLAN-Teil des Netzes mit einer Anycast-IP für den Standard-Gateway gearbeitet, die unabhängig vom Router, der die Anfrage des Clients empfängt immer identisch ist. Somit entfällt bei einem Handover eines Clients die Umkonfiguration von Netzwerk-Parametern.

Ein weiteres Problem, was sowohl mit dem Routing zusammenhängt, aber auch die Verwaltung der Clients betrifft ist zudem die IP-Adress-Vergabe. Man könnte theoretisch zwar einen zentralen DHCP-Server nehmen und auf Layer 2 (Ethernet-Ebene) routen, hätte dann aber sofort einen Netzausfall, wenn der Client sich in einem Teil des Netzwerkes anmeldet, der gerade keine Verbindung zum DHCP-Server besitzt. Der gegenteilige Weg, also dass jeder Router auch gleichzeitig DHCP-Server spielt, scheint zwar übertrieben, birgt aber andererseits einen Reihe essentieller Vorteile, die man für die Netzwerk-Verwaltung benutzen kann. Damit nun auch ein einzelner, nicht gerade mit dem Rest des Netzwerkes verbundener Knoten noch operativ bleibt, muss jeder der DHCP-Server autark und autoritiv entscheiden können. Da er dies für den gesamten im Netzwerk verwendeten Adressbereich nicht autark tun kann, muss jedem DHCP-Server ein eigener Adressbereich zugeteilt werden, den dieser autonom verwalten darf. Zu diesem Zweck wird der gesamte für das WLAN vorgesehene Adressbereich noch einmal in Subnetze unterteilt. Im Fall von Freifunk Chemnitz handelt es sich hierbei um ein /17-Netz für WLAN, welches in /28-Netze für jeden Router aufgeteilt wird. Da sich einige Clients etwas zickig haben, wenn der DHCP-Server aus einem anderen Subnetz kommt, ist eine der IPs dieses /28-Netzes für den DHCP-Server des Routers zugewiesen.

Wäre noch ein letzter Aspekt kurz zu erwähnen: Nämlich das Backbone-Netzwerk, welches von den Nodes untereinander verwendet wird, um das Netz auch beim Zusammenbruch direkter Funkstrecken (z.B. Sichverbindungen, Richtfunk) über alternative Wege, wie eine VPN-Verbindung über UMTS) am Leben zu halten. Da auch diese Struktur sehr dynamisch sich ändert, wird dieser gesamte Netzbereich (beim Freifunk Chemnitz ein /21) mit OLSR verwaltet.

Somit besitzt jeder Node, der am Routing teilnimmt folgende 4 Angaben:

  1. Seine Node-IP: z.B. 10.8.40.42
  2. DHCP-Range: z.B. 10.8.130.144/28
  3. DHCP-Server-IP: z.B. 10.8.130.145
  4. Gateway-Anycast: z.B. 10.8.255.254

Diese gehören zu den folgenden 2 Netzwerken:

  1. Backbone/Routing: 10.8.40.0/21
  2. WLAN/Roaming: 10.8.128.0/17

Betrachtet man sich das Netzwerk bisher, so ist dieses noch sehr unflexibel: Möchte ein Client umziehen, muss er, trotz dem er an jedem Router Pakete in das Netzwerk senden kann, zum Empfang der Antwort immer in Reichweite des Knotens bleiben, der ihm seine IP zugeteilt hat, da bedingt durch die im Routing bekanntgegebenen Subnetze alle Pakete des WLAN immer wieder zu dem Knoten, der die IP vergeben hat, zurück geroutet werden.

Soviel zum Vorgeplänkel; tut mir echt leid, dass ich etwas ausholen musste, aber der spannende Teil kommt nun!

OLSR bietet nun die Möglichkeit, die an jedem Knoten angeschlossenen „Netzwerke“ – sogenannte Host-Network Associations – bekanntzugeben. Neben ganzen Subnetzen funktioniert dieser Mechanismus nun auch für einzelne IPs, womit es möglich wird, einen Client, der von seinem Heimat-Knoten entfernt im Netzwerk lebt – ähnlich dem Roaming im Telefonnetzen – an seiner fremden Basisstation zu erreichen. Dies funktioniert, weil Hostrouten immer Vorrang vor Netzwerk-Routen haben und diese somit überschreiben.

Wenn man nun einen Client von einem zum anderen Knoten im Netzwerk umziehen kann, ist als letzter Schritt für eine Automatisierung dieses Vorgangs zu sorgen, da der Client möglichst nichts davon mitbekommen soll. Damit man aber von Seite der WLAN-Knoten weiß, dass nun plötzlich ein Knoten in Reichweite ist, muss eine Möglichkeit gefunden werden, die Clients der Umgebung zu beobachten und die Verbindungsqualität zu bewerten. Ein einfacher Ansatz ist derzeit bereits im Netz von Freifunk Chemnitz umgesetzt und betrachtet den Inhalt der ARP-Tabelle der Router als Quelle für neue Clients. Wird dort ein neuer Client entdeckt, wird durch einen ARP-Ping geprüft, ob dieser wirklich in der Nähe ist und im Erfolgsfall als Client im OLSR registriert, um dem Netzwerk Bescheid zu geben, dass dieser Knoten den neu gesichteten Client empfangen kann. Schlegt ein ARP-Ping fehl, so wird nach einem Timeout erneut versucht diesen Client zu erreichen bzw. nach einer einstellbaren Anzahl Fehlversuche der Client als unerreichbar wieder entfernt.

Auch wenn dieser bisher noch recht passive Versuch der Client-Erkennung beim Umzug von Clients eine Reihe kleinerer Nebenwirkungen besitzt, was sich i.d.R. durch Nicht-Erreichbarkeit des Clients äußert, funktioniert dieser Ansatz in der Praxis bereits vergleichsweise gut für das noch sehr frühe Entwicklungsstadium: Immerhin wird hier auf Software-Ebene nachgebildet, was typischerweise die Netzwerk-Hardware erledigt. Weitere Ausbaustufen umfassen daher auch Dinge wie eine verbesserte Erkennung neuer Clients bereits anhand ihres Traffics, bzw. ein dem ARP-Spoofing entlehntes zwangsweises Umziehen des Standard-Gateway für einzelne Clients. Auch eine proaktive Erkennung der Bewegung eines Clients zwischen den Routern und eine dieser Bewegung angepasste vorausschauendes Handover des Clients sind Dinge, die auf der Wunschliste bereits heiß diskutiert werden und in spätere Versionen durchaus einfließen werden. Mehr dazu aber in einem gesonderten Beitrag, da jedes dieser Themen eine ganze Menge Aspekte berührt, die weit über den Umfang dieses Eintrags hinausgehen würden.

Flattr this!

10.04.2011

Dropbox und Verzeichnis-Listings

Filed under: Software — Schlagwörter: , , , — BenBE @ 00:13:45

Manche Leute nutzen ja ihre Dropbox ja als Fileserver. Was in dem Zusammenhang aber etwas störend ist, sind die Fehlenden Directory-Indizes. Aber da lässt sich, auch ohne einen lauffähigen Apache, schnell Abhilfe schaffen. (more…)

Flattr this!

08.04.2011

Sichere Updates

Filed under: Software — Schlagwörter: , , , , , , , , , , , — BenBE @ 20:45:40

Heute hatte ich wieder einmal eine recht spannende Diskussion. Anlass dieser war, dass Palemoon in Version 4 einen Bug im Updater hat, der dazu führt, dass auch vorhandene Updates nicht gefunden werden. An sich nicht weiter schlimm, könnte man meinen, denn das mit den Updatern haben schon ganz andere Leute nicht hinbekommen. Was mich an der Stelle aber etwas aufgeregt hat, war „die Lösung“ bzw. der vorgeschlagene Würgaround: „Schaltet einfach SSL ab“. Gute Nacht, Sicherheit! (more…)

Flattr this!

04.03.2011

mIRC 6 mit IPv6

Filed under: Software — Schlagwörter: , , , , , , — BenBE @ 16:53:21

ein relativ guter, wenn auch teilweise bereits in die Jahre gekommener IRC-Client für Windows ist mIRC in der Version 6. Dieser tut selbst auf etwas älteren Systemen noch genau das, was er soll: Funktionieren. Da ich jedoch so langsam aber sicher versuche, überall wo möglich auf IPv6 umzustellen, war die Frage, wie man mIRC dazu bewegt bekommt, mit dem neuen Protokoll zu arbeiten. (more…)

Flattr this!

01.03.2011

Parser-Bau für Einsteiger

Filed under: Software — Schlagwörter: , , , — BenBE @ 17:56:05

Wenn man in seinem Programm mathematische Ausdrücke, die vom Nutzer eingegeben wurden, auswerten möchte, so kann man dies entweder mit Hilfe bösartiger Konstrukte tun, oder aber, mit Hilfe eines Parsers, die Ausdrücke selber auswerten und dann in einer kontrollierten Umgebung ausführen. Die Möglichkeit einer solchen kontrollierten Ausführung ist in Script-Sprachen wie JavaScript notwendig, kann aber auch in Template-Systemen gute Dienste leisten, wenn mit den dem Template übergebenen Daten noch Berechnungen zu erledigen sind, oder einfache Transformationen zu implementieren sind. (more…)

Flattr this!

11.02.2011

GeSHi getting signed

Filed under: GeSHi — Schlagwörter: , , — BenBE @ 23:10:08

Because of a recent attack against SourceForge all the GeSHi releases will be available signed to allow for verification of authenticity of the released files. (more…)

Flattr this!

25.01.2011

SVN und seine Eimer-Brigaden

Filed under: Server — Schlagwörter: , , , , , — BenBE @ 22:06:29

Die wohl mysteriöseste Fehlermeldung, die mir beim Apache bisher untergekommen ist (abgesehen von nichtssagenden SegFault-Meldungen, wenn plötzlicher Kindstot auftritt, liefert das SVN-Modul, in Verbindung mit WebDAV. Glaubt ihr nicht? (more…)

Flattr this!

23.01.2011

Bezahlt eure Webentwickler

Filed under: Fun — Schlagwörter: , , , — BenBE @ 16:06:44

Was passiert, wenn man seine Webentwickler nicht bezahlt?

Eine Firma hat das Experiment gemacht, damit andere es nicht mehr tun müssen:

Please pay your fair share 😉

(via)

Flattr this!

18.01.2011

Final crafting on GeSHi 1.0.8.10

Filed under: GeSHi — Schlagwörter: , , , , , — BenBE @ 03:24:46

After a somewhat longer period of silence from my side, due to some vacation I took, I’m proud to announce that there have quite some changes for the next release of GeSHi accumulated in the SVN trunk which will be the basis for the next release of GeSHi. As most of you might already have guessed the next release will be version 1.0.8.10, which is the first version of GeSHi in 2011 and also the first version since half a year. So what’s new with this version?

Well, the question is a bit complicated to answer, so let me split this into three parts. The first of which is all the changes to the parser of GeSHi itself. One of the changes here is a change of the handling of dashes when creating regular expressions which are used internally for GeSHi to speed up the highlighting of keywords. The problem here was that in some occasions dashes were left unescaped as part of the regexp and thus got a special meaning within character groups causing unpredictable behaviour. Although this couldn’t be used for malicious activity it was an annoying side effect causing GeSHi to crash when encountering language files which used dashes in their keywords. COBOL is one of them, Scheme another.

But let’s stay with the internal changes for another moment: There was another bug this time which affected e.g. PHP, but actually quite a bunch of other languages too. The reason for this bug is a bit more complicated to explain though, as it involves some of the internas and the precautions of GeSHi to avoid XSS attacks by the code that should be highlighted. When you look at the code sample provided there you will notice the semicolon before the offending if, right? Now, as we all know, GeSHi tries to output HTML code. This fact is important here because the semicolon – even though it doesn’t need escaping is crucial for valid HTML as it terminates escape sequences and therefore needs special treatment as we can’t simply go ahead and markup every ; we find: It might be part of an escape sequence. Luckily GeSHi works around the problem here and escapes two characters not which their HTML entity, but with something else: | with <PIPE> and – you guessed ; with <SEMI>, avoiding this disambiguity this way. Now for the problem: The default boundary checks for keywords didn’t take these replacements into account and thus hadn’t had < and > in them and therefore did NEVER match any keyword accompanied by one of those two characters. Literal < and > BTW are escaped beforehand and thus appear as &lt; and &gt; in the source when checking boundaries. Coming with this release also < and > are part of the default lists of characters allowed as boundary of a word and thus enabling the proper highlighting of the sample code in the bug report linked above.

The third issue regarding the parser is not a change of the parser itself, but rather a convenience check added to the language file checking script which didn’t verify filenames properly and thus sometimes returned invalid filenames to be checked. This bug didn’t allow for code execution, but rather produced annoying error messages when some temporary files clobbered up your language file directory.

After we’re now done with the changes to the parser let’s discuss the changes to existing language file since we have quite a few already and I’m sure I did miss even some more in the depths of my inbox! So here we go: Users of Algol68 might like the greatly improved language file by Neville Dempsey which didn’t make it into the previous release since there were some issues I needed feedback on. But even having the language file in a bit later should be early enough for you to enjoy.

Another language file which only got updated in this release is J, which is maintained by Ric Sherlock and uses one of the features fresh introduced in the previous release and now highlights all the numbers of the language J correctly, which are quite an oddity and thus needed a small adjustment of the parser to work. Or better: A tweak to make the parser look for some numebers which don’t contain digits – which actually exist in J with negative Infinity being one such example.

All friends of GDB might be in this release too, because Milian Wolff contributed an reworked and improved version for highlighting GDB stacktrace outputs making them by far more readable – believe me! So if you get the next blob of GDB output you can’t work your way through: Maybe ask GeSHi for a bit more insight. No pun intended!

Actually a bug spawning accross two language files was related to the handling of multiline comments in Javascript (and therefore also ActionScript) which both try to highlight regular expressions if they happen to detect them. The initial report for this issue was by Kevin Day who pointed me to the problem with ActionScript which could, by backporting the fix to JavaScript also be solved there. Unfortutnally I forgot one condition for JS: Multiline comments and regular expressions look SOOO close to each other, /*don’t they/ 😉 Another bug of this kind was related to F# and its prefix operators, which – you guessed it – can under certain conditions look like comments:

(*) 6 9 (* Just for reference: This comment answers questions ;-) *)

Another update to language files the new release got is related to the language GO which got some of the LangCheck warnings fixed which slipped in. Usually those don’t mean too much harm, but in regards to maintainability and consistency to what I expect from language file contributors the release should go on ahead and follow the rules, which it thanks to this patch now does.

Furtheremore in the section of updates to language files we have updates of the keyword lists for Objek (Randy Hollines), Liberty BASIC (Chris Iverson), TeraTerm (Boris Maisuradze) and Apache Configuration files (now supporting another module’s configuration options). And last but not least there are some additional comment styles for SAS (ahnolds) and fixed handling of escape sequences for CSS (yecril71pl).

And since there’s always news to report on brand new language files: here they are!

  • BASCOM AVR (Michal Goralczyk)
  • C: Loadrunner dialect (Stuart Moncrieff)
  • CoffeeScript (Trevor Burnham)
  • EPC (Thorsten Muehlfelder)
  • Falcon (billykater)
  • LLVM (Azriel Fasten)
  • UnrealScript (pospi)
  • YAML (Josh Ventura)

The two more famous of those new language probably are LLVM, an hardware-independent assembler language used as a textual representation of the intermediate code generated by the compiler framework of the same name, and YAML, which (given it’s name) ain’t markup, but serialization of data structures.

Also we have BASCOM AVR, which is used for microcontroller programming, and UnrealScript, the Scripting language used in the Unreal Engine (usually producing unreal results if you don’t know what you have to expect from your code).

So much from my side for now. Until the actual release arrives some more changes might get into, but those are definite. So look forward for the next release which will be out as soon as I manage to wrap things up.

Flattr this!

16.01.2011

Resourcenschonendes Upload-Tracking

Filed under: Server — Schlagwörter: , , , , — BenBE @ 21:25:28

Wenn man auf einer Web-Oberfläche Dateien hochladen möchte, so gibt es hierfür im wesentlichen zwei sehr verbreitete Möglichkeiten: Während die erste Version gemäß dem HTTP-Standard und dem application/x-www-form-urlencoded-Encoding die Datenüberträgt, was jeder heutige Browser unterstützt, so findet man an verschiedensten Stellen sogenannte Flash-Uploader, die zwar im Wesentlichen das Gleiche tun, jedoch versuchen verschiedene Funktionen nachzurüsten, die in vielen Browsern fehlen. Eine dieser Funktionen ist das Anzeigen des Upload-Fortschritts oder die Anzeige der Upload-Geschwindigkeit.

Im Internet findet man für diese Funktion auch verschiedene Ansätze, die jedoch meist darauf hinauslaufen, auf dem Server ein zusätzliches Perl-Script zu installieren, was dann versucht aus dem Temp-Verzeichnis von PHP die Daten zusammenzukratzen. Dies ist nicht nur ineffizient, da für jede Fortschrittsabfrage eine vollständige Perl-Instanz gestartet werden muss, sondern oft auch reichlich wacklig, wenn es um neuere Versionen von Scripten geht.

Eine wesentlich bessere Lösung wäre hier, wenn der Server sich um das Tracken von Uploads kümmern könnte und man somit keinen zusätzlichen Speicher für derlei Fortschrittsabfragen verwenden muss. Zusätzlich kann durch den Wegfall solcher externen Programme deren Ladezeit eingespart werden, wenn der Server dies bereits selbst verwaltet.

Und genau hier setzt mod_upload_progress an, der als Apache-Modul alle laufenden Upload-Vorgänge verfolgt und deren Status abfragbar macht. Diese lässt sich mit wenigen Schritten installieren und zusätzlich an die eigenen Wünsche anpassen. Aber der Reihe nach. (more…)

Flattr this!

« Newer PostsOlder Posts »

Powered by WordPress