IPSec - Destination/Peer down - sockets haengen

Thu Jun 18 16:23:03 CEST 2009

Florian Lohoff wrote:
> Hi,
[snip]
> 
> hydra:~# ping 4.4.4.4
> PING 4.4.4.4 (4.4.4.4) 56(84) bytes of data.
> ^C
> --- 4.4.4.4 ping statistics ---
> 2 packets transmitted, 0 received, 100% packet loss, time 1013ms
> 
> Ist eine nicht erreichbare/nicht existente adresse - Die adresse zu hause:
> 
> hydra:~# ping 193.189.251.193
> ^C
> 
> D.h. nicht mal der header wird ausgegeben. Strace:
> 
> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4
> connect(4, {sa_family=AF_INET, sin_port=htons(1025), sin_addr=inet_addr("193.189.251.193")}, 16^C <unfinished ...>
> 
> Und es blockt bis in alle ewigkeiten - das scheint der bind gar nicht zu moegen.
> 

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

> 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.

> Flo
> 
Gruss
	Jan
-- 
The only problem with troubleshooting is that sometimes,
trouble shoots back.