Hallo,
> From: Heiko Schlittermann <heiko(a)schlittermann.de>
> Koennte das so ein FIN_WAIT-Problem sein. M.W. ist beim Beenden einer
> TCP-Verbindung ein 3-Weg-Handshake notwendig, und das kann sehr lange
> dauern, wenn einer der Partner vorher abhandengekommen ist.
>
> Wahrscheinlich wirst Du entdecken, dass da der Port noch offen ist, im
> Zustand FIN_WAIT haengt (mit netstat ansehen) und kein Prozess mehr dazu
> gehoert.
jo, da heb ich jetzt mal nachgeschaut, das sieht bei mir etwa so aus:
root@mail: > netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 9724 dialin-194-29-60-2:1183 mail.okay.net:smtp
FIN_WAIT1
tcp 0 8264 dialin-194-29-60-2:1179 mail.okay.net:smtp
FIN_WAIT1
tcp 0 9724 dialin-194-29-60-2:1178 mail.okay.net:smtp
FIN_WAIT1
tcp 0 0 mail.elbvilla.ne:telnet k6.zuhause.net:1056
ESTABLISHED
tcp 0 126 mail.elbvilla.ne:telnet k6.zuhause.net:1055
ESTABLISHED
tcp 0 0 mail.elbvilla.ne:telnet k6.zuhause.net:1048
ESTABLISHED
udp 0 0 mail.elbvil:netbios-dgm *:*
udp 0 0 mail.elbvill:netbios-ns *:*
<---------snippel---------->
root@mail: > netstat a
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 9724 dialin-194-29-60-2:1183 mail.okay.net:smtp
FIN_WAIT1
tcp 0 8264 dialin-194-29-60-2:1179 mail.okay.net:smtp
FIN_WAIT1
tcp 0 9724 dialin-194-29-61-5:1178 mail.okay.net:smtp CLOSE
tcp 0 0 mail.elbvilla.ne:telnet k6.zuhause.net:1056
ESTABLISHED
<-----------snippel--------->
root@mail: > netstat a
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 8264 194.29.61.54:1179 mail.okay.net:smtp
FIN_WAIT1
tcp 0 0 mail.elbvilla.ne:telnet k6.zuhause.net:1056
ESTABLISHED
tcp 0 126 mail.elbvilla.ne:telnet k6.zuhause.net:1055
ESTABLISHED
tcp 0 0 mail.elbvilla.ne:telnet k6.zuhause.net:1048
ESTABLISHED
udp 0 0 mail.elbvil:netbios-dgm *:*
udp 0 0 mail.elbvill:netbios-ns *:*
<----------snappel--------->
das lustige ist, das die FIN_WAIT1 nach und nach sich selbst abbauen. Na ja.
Irgendwie hat sich die situation schon mal gebessert. Seltsam erscheint mir
aber, das es via Linux viel mehr Verbindungsfehler (smtp und POP) gibt, als
von einer Win-Kiste auf die selben accounts. Unter Linux passiert manchmal 1
Minute garnix, i4l legt auf und wählt sofort wieder, da das ganze geht von
vorne los.
> Dass es die alte IP-ist, mag daran liegen, dass Du den
> dynip_address_hack (oder so aehnlich) nicht eingeschaltet hast.
Habe noch nicht genau nachgeschaut, aber die standart suse-Kernels der 6er
generation habe das wohl schon fertig eingebaut.
> Das erste Paket einer aufzubauenden ISDN-Verbindung ist noch mit der
> ``alten'' IP des ISDN-Interfaces masqueradet, denn die neue IP hat das
> Interface ja erst nach der Einwahl beim Provider.
denke ich mal nicht. Eine andere Anwendung z.b. telnet weiß nix von der
alten IP und startet die Verbindungsanforderung mit der fake-IP des
isdn-Interfaces (192.168.0.99)
wie auch immer. In sendmail.cf sollte jedenfalls delivery_method (oder so)
statt 'defered' 'deferred' heisen, damit spart man sich schon mal eine Menge
Ärger :-|
Jetzt steht der Firmenserver erst mal in der küche und ich habe viel zeit,
mich damit auszutoben!
Gruß
Jens