Quoting Alex <mysqlstud...@gmail.com>:
Hi,
I have a few postfix-2.8.7 systems on fedora15 that connect with
another postfix-2.8.7 system. I'm receiving the following messages
periodically in the logs:
Apr 24 16:24:43 mailrelay postfix/smtpd[8814]: timeout after DATA
(9832 bytes) from mail02.example.com[68.XXX.YYY.45]
tcpdump will show if this is an MTU problem, mis-handling of TCP
window scaling in a buggy firewall, or something else.
You can set the MTU with ifconfig commands; and Postfix has
tcp_windowsize parameter that allows you to prevent window scaling.
One of the network admins responsible for an Exchange server which
also connects to this relay server and is also having difficulty, has
reported the MTU is set correctly to 1500.
I've done a little investigation of my own, and I'm finding what I
believe are a lot of incorrect checksums?
# tcpdump -n -i em1 -v port 25
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size
65535 bytes
22:58:47.240297 IP (tos 0x0, ttl 64, id 42727, offset 0, flags [DF],
proto TCP (6), length 60)
172.31.1.25.39996 > 65.211.178.22.smtp: Flags [S], cksum 0xa150
(incorrect -> 0x7f01), seq 1065884188, win 14600, options [mss
1460,sackOK,TS val 807651512 ecr 0,nop,wscale 6], length 0
Am I reading that correctly? Is the "mss 1460" the indication of the
MTU? If not, how can I have it return the MTU? I've searched quite a
bit and really unable to find any reference on how to display that.
Try a tracepath to the other server.
Just cause you and the other side have *correct* MTU settings of 1500,
doesn't not mean everything between you two, also can handle 1500 mtu.
Famous for causing these issues is ipsec and dsl connections.
All it takes is for one link between you to not have a mtu equal to,
or larger than either of you, and someone to block icmp, then path-mtu
will fail, and your have these types of issues.
