Hallo,

From: Heiko Schlittermann heiko@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