Начало                               Наверх                              

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. Это сообщение также свидетельствует о проблемах в сети.

Per Hedeland:
"...

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.

..."