P2P mit AES Verbindung bricht weg

[langewiesche]

Hin und wieder bricht die Verbindung einer Punkt zu Punkt Verbindung weg. Ein Reboot des Master APs hilft. 5 Sekunden spaeter ist die Verbindung wieder da. Der Slave rennt super. Vorher war die Verbindung offen da gab es keine Probleme ich ueber lege das WPA/AES von der Verbindung wieder runter zu nehmen, jemand eine Idee?
2 x L54g (ca 300 Meter)

[alf29]

Moin,

das kann passieren, wenn der Master die Beacons des
Slaves für einige Sekunden nicht gesehen hat. Dann
verwirft der Master den ausgehandelten Schlüssel und
läßte erstmal keine Pakete vom Slave durch, bis dieser
eine Neuverhandlung anstößt (was er bei dem ersten
Paket gesagt bekommt, das er an den Master schicken
will). Probleme kann es geben, wenn der Slave diese
Situation nicht mitbekommen hat und momentan keine
Pakete an den Master zu senden hat - dann ist der
Slave von der Master-Seite erstmal nicht erreichbar.

Man kann den Timeout in den Interpoint-Einstellungen
hochdrehen, oder aber auch vom Slave aus regelmäßig
pingen. Theoretisch sollten dies schon die IAPP-Announces
von Slave bewirken, aber die kommen per Default nur
alle 2 Minuten.

Gruß Alfred

[langewiesche]

es sollten immer eine handvoll aktiver verbindungen daten uebertragen, da ein ipsec tunnel ueber die verbindung einen rs-232 uebertraegt zu einem terminal. wo immer daten fliessen.
Oder hat das pingen noch eine andere Bedeutung?

[alf29]

es sollten immer eine handvoll aktiver verbindungen daten uebertragen, da ein ipsec tunnel ueber die verbindung einen rs-232 uebertraegt zu einem terminal. wo immer daten fliessen.
Oder hat das pingen noch eine andere Bedeutung?

Entscheidend ist, ob irgendein Paket vom Slave in Richtung
Master fließt. Eine TCP-Verbindung kann durchaus in
dem Zustand sein, daß von einer Richtung Daten kommen,
die aber nicht durchkommen, und aus der anderen
Richtung keine ACKs kommen, weil auch keine Daten
erwartet werden...

Gruß Alfred

[Jirka]

Hallo Alfred,

hier http://www.lancom-forum.de/ptopic,2600,iapp.html#2600 schreibst du folgendes:

Normalerweise regelt sich das spätestens nach etwa
2 Minuten, wenn IAPP aktiviert ist und der Slave das
nächste Announce in alle Richtungen ausstrahlt. Hast
Du den Roaming-Support ausgestellt, dann klappt es
so naturgemäß nicht - LANCOMs sind von Hause aus
nicht so 'gesprächig' wie Windows...

Mit der nächsten Firmware ist eine Erweiterung drin, daß
ein Slave die ausgehandelten Schlüssel auch verwirft,
wenn er seinen Master für ~4 Sekunden nicht 'gesehen'
hat. Dann sollte's sofort wieder gehen, wenn der Slave
den Master wieder 'sieht'.

Was ist aus dieser Erweiterung geworden?
Falls sie inzwischen existieren sollte, verstehe ich deine Antwort

Dann
verwirft der Master den ausgehandelten Schlüssel und
läßte erstmal keine Pakete vom Slave durch, bis dieser
eine Neuverhandlung anstößt (was er bei dem ersten
Paket gesagt bekommt, das er an den Master schicken
will). Probleme kann es geben, wenn der Slave diese
Situation nicht mitbekommen hat und momentan keine
Pakete an den Master zu senden hat - dann ist der
Slave von der Master-Seite erstmal nicht erreichbar.

nicht so recht.
Ich wollte auf Exklusiv-P2P-Strecken eigentlich das IAPP ausstellen, wenn ich das hier so lese scheint das eher nicht sinnvoll zu sein. Ich hätte es für sinnvoll erachtet, weil es eigentlich nichts bringt und ich es irgendwo nicht mag, wenn evt. an "offenen Enden" (APs mit bzw. sogar ohne WEP) meines Netzes sowas rausgepostet wird.

Viele Grüße,
Jirka

[alf29]

Moin,

diese Erweiterung ist seit Firmware 4.12 drin. Die 4 Sekunden sind
aber konfigurierbar.

Gru Alfred

[Jirka]

Moin Alfred,

aha - danke für die Info.

So, aber wenn diese Erweiterung denn nun drin ist, dann verstehe ich nicht die Notwendigkeit, dass ein Paket vom Slave in Richtung Master unterwegs sein muss. Dann sollte es sich doch auch ohne 1) Pakete von Slave zu Master oder 2) ohne IAPP oder 3) ohne regelmäßige Pings vom Slave aus wieder alles von alleine einregeln. Oder verstehe ich irgendetwas falsch?

Vielen Dank und viele Grüße,
Jirka

[alf29]

So, aber wenn diese Erweiterung denn nun drin ist, dann verstehe ich nicht die Notwendigkeit, dass ein Paket vom Slave in Richtung Master unterwegs sein muss. Dann sollte es sich doch auch ohne 1) Pakete von Slave zu Master oder 2) ohne IAPP oder 3) ohne regelmäßige Pings vom Slave aus wieder alles von alleine einregeln. Oder verstehe ich irgendetwas falsch?

Es muß ein Paket vom Slave in Richtung Master unterwegs
sein, damit der Slave mitbekommt, daß die
Verschlüsselung neu ausgehandelt werden muß.

Wenn in dieser Situation aber nur von der Master-Seite
her versucht wird, Verbindungen aufzubauen, dann kriegt
die Slave-Seite das nicht mit, weil die Pakete vom Master
ohne ausgehandelten Schlüssel ja erst gar nicht in die
Luft geschickt werden - so eine Art Deadlock.

Im Prinzip hat man bei einer Client-Verbindung genau
das gleiche Problem. Verwirft der AP einen Client z.B.
wegen Idle-Timeout, so weiß der Client davon auch
erstmal nicht unbedingt etwas, aus seiner Sicht ist der
AP ja noch da, weil er dessen Beacons noch sieht.
Trotzdem wird der AP keine Pakete für diesen Client
mehr ins WLAN weiterleiten, und der Client bekommt
diese Situation erst dann mit, wenn er von sich aus
versucht, Daten an den AP zu schicken, woraufhin er
vom AP gesagt bekommt, daß er sich erstmal wieder
einbuchen muß.

Gruß Alfred

[Jirka]

Hi Alfred,

ich glaube so langsam habe ich das verstanden ... DANKE.

Viele Grüße,
Jirka