l3roamd.org

Ideen zum l3roamd

Das mit den unbekannten Routen zu den Zielen

Clientnetz auf ein tun-Device routen

Gefundene Routen sind spezifischer und gehen direkt zum peer

Daemon auf tun-Device findet ansonsten die Route und wartet, dass sie eingetragen wird

• Nachfrage nach Route per Broadcast ähnlich AHCP
• jeweil Broadcasts 3x senden
• später irgendwie per Multicast optimieren

wenn vorhanden, wird das Paket nochmal gesendet

• über das tun interface

Die neue Adresse

Knoten macht neighbour discovery auf br-client

ndisc6 -q $IP br-client Wichtig wäre nur, ob es überhaupt eine Antwort gibt (und dass die IP passt). Sollte man wahrscheinlich 3 mal wiederholen.

Bei antwort (netlink event?) route in Tabelle eintragen

Babel verteilt dann

Frage: Wann vergisst man eine Adresse und somit Route wieder?

Frage: Wann überschreibt ein anderer Knoten diεRoute und Adresse?

Bei IPv4: einfach mappen und ARP machen?

Zuordnung (MAC, (IP, $timeout)) muss auch noch per Broadcast verteilt werden, für Roaming

Ein Client roamed

Der neue Knoten bemerkt eine neue MAC

Er hat hoffentlich eine (MAC, [(IP, $timeout)]) Tabelle

…und announct dann einfach die entsprechenden Routen

Jetzt muss er den vorherigen Knoten nur noch ausreden die Routen auch zu announcen

Frage: Wie erreicht er ihn?

Daemons

Der Daemon, der auf dem tun-Interface lauscht

“liest die Routingtabelle”

• muss keine Prefixe kennen. Das geschieht implizit über die Route.

und Pakete puffert

auf Änderungen der Routingtabelle lauscht

• passendes Prefix mit passendem Protokoll (babel)

Pakete weiter schickt

Neighbour Solicitations anstößt

ggf. Host unreachable meldet

Der Daemon, der Neighbor Solicitations tut

“schreibt die Routingtabelle”

auf Änderungen der Neighbours lauscht

Routen für Neighbours in die Routingtabelle einträgt (babel tut den Rest)

testen, ob eine route zum ziel vorhanden ist. dann paket ignorieren

neighbour solicitations weiterleitet (broadcast)

neighbour solicitations an br-client schicken und auf antwort warten

neighbours änderungen (MAC, (IP, Timestamp)) broadcasten

• Timestamp ist, wann der Client gesehen wurde

lauscht auf WLAN interfaces, und ggf. anderen nach neuen MACs (reicht da RTN_NEIGH?)

Was weiß er, wenn ein Client auftaucht?

• Wie “jung” er ist

(MAC, (IP, Timestamp)) wird gebroadcastet

• ein Knoten, der glaub MAC zu haben aber bei dem Timestamp älter ist gibt alle IPs der MAC frei
• ist die MAC jünger, broadcasten wir selber nochmal (MAC, (IP, Timestamp))
• bei Konflikt direkt per Unicast einigen. Was wird dann getan? Welcher Fall ist das?
• Das ist ähnlich wie DDHCP!
• Wenn sich nicht per Unicast geeinigen werden kann, was dann?
• Sollten beide Knoten den Client “vergessen”?
• Sind dann beide Routen im Mesh?
• Wenn ein Knoten einen Client nicht freigeben will, kann man sowieso wenig tun.

Wenn eine IP ein Timeout hat, wird die Route als deprecated markiert

…und dann, nach einer Weile, entfernt Wäre es schlimm viele solcher Routen im Mesh zu haben oder hilft es sogar?

Was wäre dann Roaming?

• ein Broadcastpaket (MAC, [(IP, Timestamp)]) “Ich hab jetzt den Client!”
• ggf. noch so ein Paket “Nein, das ist meiner!”
• ggf. eine Einigung per Unicast

Wie wird ein Client gefunden?

• ein Broadcastpaket “Wer kann zum Client mit $IP routen?”
• Antwort erfolgt indirekt über babel

[11/40] l3roamd

• erstmal ein statisches prefix
• später einen mix aus statischen und dynamischen prefixen

Datenstrukturen

Für Pakete, die noch gesendet werden müssen

Hashtable(IP, (Timeout, nTry, [Paket]))

Tunnel device öffnen und Ziel-IPs dumpen

• State “DONE” from “TODO” [2015-08-22 Sa 01:44]

Auf NETLINK socket nach neuen Routen lauschen und dumpen

• State “DONE” from “TODO” [2015-08-24 Mo 00:49]

ICMP6 socket

• State “DONE” from “TODO” [2015-08-24 Mo 23:03]
• ndisc senden
• ndisc empfangen, whitelist für prefixe

forwarding

• State “DONE” from “TODO” [2015-08-25 Di 12:16]
• [X] testen ob paket schon bearbeitet wurde
• [X] per ndisc nachfragen
• [X] anfrage weiterbroadcasten

intercom: mehrere interfaces

• State “DONE” from “TODO” [2015-08-25 Di 17:20]
• [X] mehrere interfaces unterstützen
• [X] sendto über alle interfaces
• [X] netlink socket, neue interfaces erkennen und multicast joinen

neue macs mitbekommen

• State “DONE” from “TODO” [2015-08-27 Do 01:05]

routen irgendwo merken

• State “DONE” from “TODO” [2015-08-27 Do 01:05]

Datenstruktur für Clients bauen

• State “DONE” from “TODO” [2015-08-27 Do 01:05]
• index mit MAC
• last seen
• last known node’s IP
• liste von IPs

ndisc empfangen

• State “DONE” from “TODO” [2015-08-27 Do 01:06]
• [X] route eintragen
• [X] client merken*

iw events auswerten, neue clients dumpen

• State “DONE” from “TODO” [2015-08-27 Do 01:07]
• libnl-tiny verwenden
• braucht eine liste von ifindexes
• also auch irgendwie libnetlink foo

neighbour advertisement ohne mac? kommt das vor? ja -> abfangen

• State “DONE” from “TODO” [2015-08-27 Do 19:46]

wifistations auf interfaces filtern!

Protokollformat überlegen / dokumentieren

• generelles broadcast format bauen mit ttl, random nonce, absender IP, node id (eui-64)

IP Suchen

• ttl
• random nonce
• gesuchte IP

MAC-IP Zuordnungen

• ttl
• random nonce
• MAC
• lastseen (relativ)
• liste von Client IPs

Logging, sinnvolle Infoausgaben

Code aufräumen

• [ ] funktionsnamen
• [ ] variablennamen

routen nach timeout entfernen (30min)

• nach halben timeout ndisc machen und ggf. erneuern?

now “global” in loop setzen und durchreichen

variabel auf interfaces zum meshen reagieren

Fehler von inet_* abfangen

Fehler von bind abfangen

client interface sollte optional sein (z.B. auf servern)

• dann kein ndisc machen

speicherlecks suchen und beheben

eigener ctx für icmp6

clients verwalten

• verwaltet die clients
• verwaltet auch die routen
• bekommt neue Clients (wifistation, ndisc) mit
• bekommt client roaming pakete von anderen knoten mit

Wie mitbekommen, dass ein Client noch da ist?

Wenn seine Adressen gesehen wurden. = max(map(lastseen, addresses))

Wie Routen zu Clients entfernen?

Muss das in der Datenstruktur abgebildet werden?

clientmgr timer für lastseen und (halbe zeit)

• IPs (und routen) entfernen
• client ganz entfernen

hashmap statt Vector an vielen stellen verwenden

• find_entry (main.c)
• clientmgr.c
• usw…

alle TODOs in den C-Dateien durchgehen!

l3ctx.clientprefix in den clientmgr_ctx schieben

typedef struct loswerden

clientmgr bei neuen macs auslösen

bind icmp6 socket to client interface!

clients müssen irgendwie permanent synchronisiert werden

falls ein knoten mal neustartet

• nachbarn nach deren client tables fragen
• antworten per unicast

Neuer Knoten

• muss mitbekommen, dass er neue Nachbarn hat
• muss nachbarn auch mal vergessen

Routen entfernen klappt noch nicht gut

babel sollte throw routen ignorieren

IPv6 Neighbour Table Einträge beim Roaming entfernen

routes.c nochmal überarbeiten

Welches Raceconditions können auftreten?

babel abgewöhnen unreachable routen anzulegen

• Routen ganz entfernen

Wer genau muss beim Roaming informiert werden?

Wenn eine station verschwindet, auch routen entfernen (timeout sozusagen)

pakete nicht buffern. bufferbloat und so

verteilte Datenkbank für MAC/IP auslagern

ist hostapd iapp nützlich?