IPSec - Destination/Peer down - sockets haengen

[Jan 'RedBully' Seiffert]

Florian Lohoff wrote:
> On Thu, Jun 18, 2009 at 04:23:03PM +0200, Jan 'RedBully' Seiffert wrote:
>> Hmmm, mal als bloede vermutung:
>>
>> Das connect mit einem Fehler zureuck kommt basiert entweder auf internem Kernel
>> Zustand (kein Speicher, keine Route, etc.) oder auf einer Meldung der
>> Gegenseite, so auf ICMP/TCP ebene (ICMP port closed, oder RST).
>> Ich denke das Problem ist mit IPSec, das die Packete durch das Routing da
>> reingehen, aber NICHTS zurueck kommt (der Userspace Daemon ist noch am
>> rumhaeulen, es wird nichts ge-forwarded im Kernel, usw.). Ein Black hole.
>> Das einzige was jetzt connect davon abhaelt ewig zu blocken ist ein genereller
>> timeout. Nur entweder:
>> - verhindert IPsec den Timer, da ja alles "in bearbeitung" ist
>> - der ist sooo lang eingestellt (10 Minuten oder sowas), das Bind zuerst auf die
>> Idee kommt, es wuerde fatal haengen (z.B. 2 Min)
>> - der ist kaputt/es gibt ihn nicht
> 
> Das ist definitiv eine IP Sec geschichte - Ein Datagram socket connecten
> bedeutet nur das der Kernel sich die Destination fuer die zukuenftigen Pakete
> merkt - d.h. es duerfte unter keinen umstaenden blocken (Anders als bei TCP das
> einen connection versuch unternimmt).
> 

Im connect fall fuer datagram sockets wird schon mehr gemacht.
Er konntrolliert denke ich die Route (fuer ENETUNREACH). Und er alloziert einen
Port (noetig fuer ungebundene Sockets) auf dem interface (connect(2): EAGAIN -
No more free local ports or ...).

Und ich denke da haengt er.
Moeglich dass das IPSec geraffel in dem Fall da irgend einen Lock haelt.

> Und bei IPSec gehen eben ueberhaupt keine Pakete raus wenn die keys nicht
> verhandelt sind - D.h. die Socket policy ist block im falle von nicht aufgebauten
> associations ...

Alles was der Kernel weiss ist, das der Userspace teil da noch am Handshaken ist.

Potz Blitz. Wilde Spekulation:
Aehnliches gehaenge hab ich schon mal festgestellt wenn ein PPP-Interface mit
On-Demand-Dail nicht "hochkommt" (T-Offline und seine Radius Server...). Der
pppd gibt nur irgendwann auf.
Bei meinem minimalen IPSec use hab ich auch ein On-Demand-Dail verhalten
festgestellt (Irgend eine Option? keine Ahnung, hab das nur kopiert wegen "damit
laeuft es"), vielleicht spielt das hier Boese mit. Der Kernel gibt deshalb
vielleicht nicht sofort einen Fehler zurueck da er erwartet das ja gleich eine
Verbindung da ist.

>>> Hat jemand da eine loesung fuer?
>>>
>> Ich denke man muesste ertstmal rausfinden was Bind toetet. Ich tippe er sich
>> selbst durch irgend eine Art Watchdog timeout.
> 
> Nope - es haengt noch mehr - munin auch - der versucht u.a. auch von der kiste
> zu pollen am anderen ende vom IPSec - die kiste stirbt einen langsamen tod
> wenn das IPSec weg ist ...
> 

-v
Tod im Sinne von kill/Prozess ende oder Tod im Sinne von haengt?
Bei ersterem ist die Frage was das ausloest.
Letzteres ist nur programmatisch zu loesen in dem man allen Programmen beibringt
 nicht ewig zu blocken damit die Ausfuehrung nicht zum Stillstand kommt
(nonblocking-multiplexing, fuer connect & tcp mag das noch gehen, fuer
send/sendto ist das bei datagram sockets kontraproduktiv, denn du moechtest
meist keine partiellen/fragmentierten Datagramme schicken).

> Flo
Gruss
	Jan

-- 
Infolge des gekürzten Budgets und der gestiegenen Unkosten für Gas,
Öl und Strom wurde das Licht am Ende des Tunnels abgeschaltet. Wir
entschuldigen uns für die dadurch entstandenen Unanehmlichkeiten.