David Hoffman wrote:
I left ethereal running overnight and caught several packets that were tripping this log event. Out of the 7 events that I caught, 6 of them showed [TCP ZeroWindow] and [INCORRECT CHECKSUM] in the packet info. There are other places where I would see the ZeroWindow message that did not trip the log, but there were no other places where I would see the INCORRECT CHECKSUM. The seventh entry that showed up in the log did not have an info line that matched either the ZeroWindow or Checksum message, but it was the last packet received from the host and the info simply stated: 4257 > smtp [RST] Seq=93 Ack=1545503494 Win=0 Len=0
My guess is that kernel is going to drop malformed packets (incorrect checksums for example) as soon as it detects them. This might or might not be at the root of your problem.
I think I understand what you mean about seeing an RST AFTER Postfix closes the connection. Maybe I should look at what Postfix sends when it closes the connection. If Postfix sends the RST, then should the other end send anything back at all? Maybe an ACK? Does Netfilter simply look for the first RST (from either side) and then consider it a closed connection?
The question here is, is Postfix closing the connection, or simply sending error code to the remote end, and than expecting remote end to close the connection. One way to check this would be to do an netstat -an and grep for port number from log as soon as log entry is generated in logs. This would show if kernel and postfix still consider connection being in ESTABLISHED state (not to be confused with Netfilter's ESTABLISHED state, two different and independent things).
Of course, tcpdump/ethereal logs would show this too. If you are seeing this only from one host, and if that host is not generating a lot of traffic, try doing "tcpdump -i eth1 -s 0 -w hostname.dump host hostname" and let it run overnight. Replace string "hostname" with remote host's name or IP address. "-s 0" will catch and save entire packets, so you can completely reconstruct what is going on on the SMTP level too. You can load hostname25.dump file into ethereal GUI later on to analyze it, or print it onto screen with tcpdump using "-r" option. You can run this tcpdump on both your mail server and your NAT firewall external and internal interfaces (three tcpdumps) and see if there is any difference in packets captured (tcpdump listens on the wire, so if you see packet on NAT firewall's external interface, but not on internal interface, or vice versa, it means something ate it on that machine).
-- Aleksandar Milivojevic <amilivojevic@xxxxxx> Pollard Banknote Limited Systems Administrator 1499 Buffalo Place Tel: (204) 474-2323 ext 276 Winnipeg, MB R3T 1L7
