3. Сообщение в maillog: 0: fl=0x0, mode=20666: CHR: dev=0/0, ino=235940, nlink=1, u/gid=0/3, size=0
Вся информация, представленная на этой странице, взята из sendmail-конференции и с сайта www.sendmail.org.
1. Это сообщение также свидетельствует о проблемах в сети.
Well, it's surely not a sendmail problem, since a user-level program
basically can't produce such a behaviour from the TCP/IP stack (or at
least it would have to try *really* hard:-). That doesn't rule out the
possibility that changed sendmail behaviour may be more likely to
trigger the problem though.
My first question would be whether there is some firewall involved
(separate box or local to either host)? I've seen something similar when
using ipfilter in overly paranoid mode - it was set up to send RST in
response to TCP packets that weren't allowed by one of the "holes" or
matched an existing session via kept state, but this rule triggered also
for packets that *did* belong to an existing session but were outside
(ipfilter's idea of) the TCP window.
Other things that strike me as odd in the trace are the short packet
size (1420 rather than the normal 1500 on Ethernet), and the fact that
the last packet sent is shorter still (1332). Is there some tunneling,
weird stuff like PPPoE, or manual setting of MTU or MSS at either or
both ends? The extra-short packet would seem to imply that it was
actually the final DATA packet, but that can't be right if the SIZE
is. It could perhaps also be due to the sender thinking that the window
didn't allow for sending more - that seems unlikely given the following
ACKs, but only looking at the last preceding ACK would say for sure.