On Fri, Feb 12, 1999 at 09:47:14PM +0100, Harald Hanche-Olsen wrote:
> - Paul Farber <[EMAIL PROTECTED]>:
>
> | Hello all, got a new one for qmail 1.03 users everywhere.
> |
> | I've had these connections for about a day now. qmail-qread says these
> | messages are not in the que, and qmail-qstat equalled the number of
> | messages that qmail-qread displayed.
> |
> | I stopped and restarted the qmail-smtpd daemon (im on a RH 5.1 box so I
> | gave it a qmail-smtpd restart. It stopped the tcpserver, supervise, and
> | smtpd daemon... but these guys are still here.
> |
> | Any way of figuring our why they are lingering or how to kill them short
> | of a reboot?
> |
> | BTW... man netstat did not explain the LAST_ACK signal.
> |
> | Thanks!
> |
> | tcp 65 25365 mail.f-tech.net:28934 mail.hotmail.com:smtp
> | LAST_ACK
> | tcp 65 24665 mail.f-tech.net:29812 mail.hotmail.com:smtp
> | LAST_ACK
>
> LAST_ACK is not a signal, it's a TCP state. It means the connection
> is practically closed down, your end is just waiting for the other
> side's ACK of your FIN. Check the TCP connection state diagram in
> figure 6, RFC 793. If hotmail.com generates a lot of connections in
> this state they sure have a problem. I don't know what you can do
> about it, though, as I am no networking expert.
>
> But as far as I can figure out, your host should be retransmitting
> that FIN packet once in a while. If the host at the other end is
> down, or has been down and come back up, I would expect an ICMP packet
> to come along to explain that the connection just isn't there, after
> which your side can abort the connection and clean up. But this is
> clearly not happening, and here my advice runs dry.
Well there's the exact problem. Hotmail filters _all_ ICMP at their firewall.
Greetz, Peter.
--
.| Peter van Dijk
.| [EMAIL PROTECTED]
