[WLANnews] Verschlüsselung (und mehr Fragen)

[Daniel Nitzpon]

eigentlich dachte ich, zu den meisten sachen stehen genug infos im netz 
und in archiven, sind die so unklar/schwer zu finden?

also kurz im schnelldurchlauf:

Lars Scheithauer wrote:
> Naja, das PPA ist da eigentlich recht deutlich... Außerdem ist das 
> Beobachten (auch automatisch) von Netzwerkverkehr in Deutschland 
> rechtlich sehr stark eingeschränkt und ich denke nicht, dass man für die 
> paar Leute tatsächlich so einen Aufwand betreiben muss - und sich zudem 
> noch in eine Grauzone begibt. Von daher würde ich die Sache vergessen.

das ppa bezieht sich nicht darauf. wirklich ;-)
rechtlich weiss ich nicht genau, würde ich aber auch nicht pauschal 
überzeugt sein, dass es dort probleme gibt, ohne das genauer anzuschauen.

> geeignet hält, Node Y zu erreichen. Dieses Node (off-optic: ist Node 
> eigentlich männlich, weiblich oder sächlich? ;) ) 

sächlich auf keinen fall :-)

> Frage ist jetzt, ob sich jede Node eine Sequenznummer o.Ä. merkt, um 
> eine (für den Augenblick) stateful Route aufzubauen (z.B. für die 
> Antwort von Node Y an Node X), oder ist die Route komplett stateless 

die route (bzw. der nachbar, bei dem diese beginnt) wird ständig neu 
berechnet, aber diese berechnung durchaus dauerhaft (stateful) vorgehalten.

> (d.h. dass die ganze Prozedur für die Antwort von Node Y an Node X 
> wiederholt wird)?

routen gelten in eine richtung. der rückweg kann (theoretisch) eine ganz 
andere geschichte sein.

> Die nächste Frage wäre, ob es eigentlich schon ein Testbed (also eine 
> Java-Umgebung oder so) für das Protokoll gibt. Zumindest habe ich beim 
> Statusbericht[1] bisher nur über eine Simulation über Virtuelle 
> Maschinen gelesen, wobei kein Packetloss und auch keine bewegenden Nodes 
> simuliert wurden.

man kann sowas in netzwerksimulatoren klatschen und das haben leute auch 
schon getan, aber erfahrungsgemäß wird man um was in vernünftiger zeit 
rechnen zu können soweit abstrahieren müssen, dass die ergebnisse wenig 
aussagekräftig sein werden.

> Zum Thema Multicast: Wäre es nicht sinnvoll, zu Testzwecken auch einen 
> kompletten Broadcast (ab Debuglevel 3 oder so) zu erlauben, um einen 
> Status des gesamten Netzes zu erfahren? Dadurch könnte man deutlich 
> besser das Verhalten des Netzes während der Experimentierphase beobachten.

es macht mehr sinn, die ergebnisse / status von den nodes schon 
akkumuliert abzufragen, das passiert auch (siehe z.b. 
db.leipzig.freifunk.net).

> Thema Interfaces:
> Soweit ich das verstanden habe, verbindet sich jeder Node mit genau 
> einem Interface auch nur mit genau einem weiteren Node (durch den 
> Ad-Hoc-Modus). Bedeutet das dann, dass ein solcher Node auch nur genau 
> einen Nachbarn hat / sieht oder wird vorher / in regelmäßigen Abständen 
> ein Scan aller verfügbaren Nachbarn durchgeführt, und dann erst bei der 
> Auslieferung von Paketen eine Ad-Hoc-Verbindung hergestellt?

ich weiss nicht, was du genau unter einer ad-hoc-verbindung verstehst. 
alle befinden sich im selben netz und schicken dort ständig sowohl 
broadcasts für die routenfindung als auch unicasts für den datentransfer.

> Last Question: Gab es schon Überlegungen, anstatt statische 
> IPv4-Adressen für die Nodes lieber den Auto-Negotiation-Modus von IPv6 
> zur "Zuweisung" von Adressen zu benutzen? Dazu könnten die Meshes sich 
> Lokale Adressen verteilen (was ja auch organisatorisch korrekter wäre 
> als den öffentlichen Bereich zu verwenden) und man würde es für DAUs 
> einfacher (und attraktiver) machen, die Wolke zu vergrößern.

gibt es und gab es, scheitert aber meist schnell an den komplikationen 
mit der nutzung von ipv6.