Hallo wulf

Wenn die AccessPoints routen ist ARP nicht dein Problem, da dieses rein auf Layer 2 arbeitet. In dem Fall bekommt der WLAN-Client (Notebook, Smartphone o.ä.) beim AP-Wechsel auch eine neue IP-Adresse zugewiesen. In dem Fall müssen die Kommunikationspartner nicht den ARP-Cache "überarbeiten", sondern, sofern mit Namen gearbeitet wird, der DNS-Server die neue IP bekommen und die anderen Clients diese erneut abfragen - sprich den DNS-Cache flushen.

Sinnvoller wäre die AccessPoints als Bridge zu betreiben. Alle WLANs und das Kabelnetz bilden dann ein einziges Subnetz. Wenn dann Pakete nicht direkt zugestellt werden liegt es an der Switchtable im AccessPoint.

_________________
Reboot oder be root, das ist hier die Frage.

Danke für deine Antwort.
Leider ist das Routingprotokoll vorgegeben (OLSR), WDS soll nicht verwendet werden. Ich arbeite zur Zeit im Zuge meines Berufspraktikums für 15 Wochen an der Uni Klagenfurt im EU-Projekt BRIDGE mit.

Zitat :

Wenn die AccessPoints routen ist ARP nicht dein Problem, da dieses rein auf Layer 2 arbeitet.

Die AccessPoints routen, allerdings habe ich vergessen dazuzusagen, dass alle AccessPoints den selben Kanal, die selbe SSID und MAC Adresse haben. Damit soll eben sichergestellt werden, dass die Clients wirklich transparent zwischen den APs springen (ohne sich im neuen AP einloogen zu müssen). Zwar werden dadurch die Frames von mehreren APs angenommen und weitergeleitet, ist aber nicht so schlimm.
Das eigentliche Problem ist folgendes Szenario:
Zwei Clients sind im gleichen AP (beide sehen sich "lokal" auf MAC Ebene). Wenn sich jetzt Client A in einen anderen AP begibt, so glaubt Client B immer noch, dass Client A über die bisherige MAC Adresse ereichbar ist, und zwar so lange bis der ARP Eintrag verfällt (ca. 30 Sekunden). Das ist eine lange Zeit.
Deshalb müsste man jetzt von Client B den ARP Eintrag updaten, z.B. indem der AccessPoint von Client B den Eintrag auf sich verweisen lässt (und auf Layer 3 dann weiterrouten kann).
Und um eben diesen ARP Eintrag zu erneuern suche ich ein Tool. Wie gesagt, ARPing geht zwar, lässt aber kein spoofing zu, sprich: Der AP kann nur ARPing für MAC Adressen/IP Adressen ausführen die er selber auch hat.

Ich hoffe ich konnte das Problem nun verständlicher beschreiben.

DNS wäre zwar eine Möglichkeit, verhindert aber nicht, dass TCP Verbindungen abbrechen, da die Sockets im Client im laufenden Betrieb ja nicht die IP ändern können. Und selbst wenn, wir bräuchten eine Art verteiltes DNS, da das Netz einen Ausfall von Knoten tolerieren muss. Da wäre ein zentraler DNS Server eine schlechte Lösung.

Grüße
Simon

[ Diese Nachricht wurde geändert von: wulf am  9 Mär 2013 23:22 ]

Zitat :

DNS wäre zwar eine Möglichkeit, verhindert aber nicht, dass TCP Verbindungen abbrechen, da die Sockets im Client im laufenden Betrieb ja nicht die IP ändern können. Und selbst wenn, wir bräuchten eine Art verteiltes DNS, da das Netz einen Ausfall von Knoten tolerieren muss. Da wäre ein zentraler DNS Server eine schlechte Lösung.

Du schreibst, die APs routen. Dann wäre der ARP-Eintrag ja unwichtig.
Dann schreibst du hier das sich die IP-Adresse ändert. Wieso sollte sie das?

Die IP wird ja anhand der Client-MAC idr. von einem zentralen DHCP-Server verteilt. Dieser gibt dem Client logischerweise beim Handover wieder die Selbe, bzw wird er garnichterst gefragt weil der Client ja im selben Netz verbleibt.

Bei vielen Geräten kannst du "Client Isolation" einschalten, d.h. der Traffic zwischen 2 angemeldeten Clients läuft _immer_ über den AP. Damit würdest du erstmal dein Problem der C2C-Kommunikation lösen können.

Was du nun mit dem DNS erreichen willst erschließt sich mir hingegen noch weniger...

Welche APs nutzt ihr da?
Profi-Kram der für soetwas ausgelegt ist?

Ich kenne z.B. die Unifi-Teile von Ubiquiti, die sind zentral verwaltbar und selbst da ist Handover nicht so ohne weiteres möglich.

Problem beim Handover ist immer das es im Client stattfindet. Der Client sucht sich seine Netze und wechselt wenn er darauf Lust hat. Auf die Logik hast du wenig Einfluß. Bei GSM/UMTS ist das etwas anderes.

Du könntest nun höchstens eine Logik implementieren die die Verbindungsqualität der einzelnen APs zu den Clients überwacht und bei Bedarf den Client zum Neuverbinden nötigt. Alles in Allem mit WLAN eher schlecht als recht zu machen.

Auf keinsten Fall würde ich hier wahllos ARP-Flooding betreiben.

Analysiere doch erstmal genau den Handover-Ablauf und beschreib den, zusammen mit der Topologie hier im Forum. Dann fällt uns vielleicht etwas ein.

Gruß, Stephan

_________________
gruß, Stephan

sudo make me a sandwich

So, jetzt komme ich endlich zu einer Antwort.

Ich habe mal ein Bild des Netzaufbaus angehängt um einen besseren Überblick zu geben.
Das Routing geschieht über Layer 3.
Roaming von AP zu AP funktioniert aber nur wenn der Client von jedem AP GENAU die selben Daten bekommt. D.h. jeder AP hat die selbe IP Adresse, MAC Adresse und SSID. Wenn das nicht der Fall wäre geht Roaming schon mal nicht weil der Client dann die APs unterscheiden kann und beim Wechsel in einen anderen AP die Verbindung ab- und neu aufbaut. Das überleben TCP Verbindungen nicht.

Zitat :

Du schreibst, die APs routen. Dann wäre der ARP Eintrag ja unwichtig. Dann schreibst du hier das sich die IP-Adresse ändert. Wieso sollte sie das?

Ich schrieb nirgends, dass siech die IP Adresse ändert.
Der ARP Eintrag ist in dem von mir beschriebenen Szenario sehr wohl wichtig, und zwar im Client.

Zitat :

Die IP wird ja anhand der Client-MAC idr. von einem zentralen DHCP-Server verteilt. Dieser gibt dem Client logischerweise beim Handover wieder die Selbe, bzw wird er gar nicht erst gefragt weil der Client ja im selben Netz verbleibt.

Da es sich hier um ein verteiltes Netz handelt gibt es schon mal gar nichts zentrales, sollte ein DHCP Server dazu kommen, wird das über ein verteiltes (selbstgeschriebenes) System gelöst.
In der zwischenzeit dürfen die IPs der Clients als statisch angesehen werden.

Zitat :

Bei vielen Geräten kannst du "Client Isolation" einschalten, d.h. der Traffic zwischen 2 angemeldeten Clients läuft _immer_ über den AP. Damit würdest du erstmal dein Problem der C2C-Kommunikation lösen können.

Leider löse ich damit mein Problem nicht, das habe ich schon versucht. Die ARP Einträge sind trotzdem vorhanden und die Clients wissen auf Layer 2 voneinander, egal ob "Client Isolation" ein oder aus ist.

Zitat :

Was du nun mit dem DNS erreichen willst erschließt sich mir hingegen noch weniger...

Mit DNS will ich nichts erreichen, ich hatte nur geschrieben warum DNS NICHT wirklich eine Lösung ist.

Zitat :

Welche APs nutzt ihr da? Profi-Kram der für soetwas ausgelegt ist? Ich kenne z.B. die Unifi-Teile von Ubiquiti, die sind zentral verwaltbar und selbst da ist Handover nicht so ohne weiteres möglich.

Es sind "Consumer" Geräte, TP-Link TL-WDR3600 mit OpenWrt als Firmware.

Zitat :

Problem beim Handover ist immer das es im Client stattfindet. Der Client sucht sich seine Netze und wechselt wenn er darauf Lust hat. Du könntest nun höchstens eine Logik implementieren die die Verbindungsqualität der einzelnen APs zu den Clients überwacht und bei Bedarf den Client zum Neuverbinden nötigt.

Durch unsere Konfiguration (gleiche IP, MAC, SSID) verbindet sich der Client NICHT neu. Welcher AP den Client dann wirklich bedient/routet machen die sich dann über ein Protokoll aus das selbst programmiert würde.

Zitat :

Auf keinsten Fall würde ich hier wahllos ARP-Flooding betreiben.

Sprach ich irgendwo von ARP Flooding? Hier geht es um gezieltes manipulieren einzelner Einträge in den ARP Tabellen der Clients.

Zitat :

Analysiere doch erstmal genau den Handover-Ablauf und beschreib den, zusammen mit der Topologie hier im Forum. Dann fällt uns vielleicht etwas ein.

Handover gibt es keinen, der Client ist gleichzeitig auch in mehreren APs aktiv.
Der Netzaufbau ist im Bild zu sehen.

_________________
Simon
IW3BWH

[ Diese Nachricht wurde geändert von: wulf am 12 Mär 2013 16:01 ]

Hat denn niemand eine Idee?

_________________
Simon
IW3BWH