Gregory Shapiro wrote this message on Wed, Mar 26, 2014 at 09:23 -0700: > > > 11:57:56.539788 IP MyServer.com.41115 > Smarthost.com.smtp: Flags [S], seq 1001452351, win 65535, options [mss 1448,nop,wscale 6,sackOK,TS val 407239960 ecr 0], length 0 > > > 11:57:56.555262 IP Smarthost.com.smtp > MyServer.com.41115: Flags [S.], seq 1277075046, ack 1001452352, win 8192, options [mss 1452], length 0 > > > > It should look something like: > > 09:18:34.723280 IP jmgmac.funkthat.com.64724 > h2.funkthat.com.ssh: Flags [.], ack 177, win 33280, options [nop,nop,TS val 1854905469 ecr 3482476972], length 0 > > 0x0000: 4510 0034 d7ac 4000 4006 e1af c0a8 0003 E..4.._at_._at_....... > > 0x0010: c0a8 0004 fcd4 0016 7e48 238e d872 43dc ........~H#..rC. > > 0x0020: 8010 8200 7c08 0000 0101 080a 6e8f 9c7d ....|.......n..} > > 0x0030: cf92 61ac ..a. > > > > Notice the hex output... I didn't see any of that in your output... > > The last packet I was talking about is the last one that had length > > 1448 that your server sent... > > Willy mentioned that this only happened on mail with attachments. Could it be an MTU issue? Specifically, see: > > http://www.sendmail.com/sm/open_source/tips/path_mtu/ I don't see how it could be... If it is litterally only mail with attachments and not large emails w/o attachments, then it's definately not that issue.. He could just disable path_mtu on the server: sysctl net.inet.tcp.path_mtu_discovery=0 to test this, but I'd be surprised if it allows email through, since he's already getting 1448 byte packets through and acked before the hang up occurs... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."Received on Wed Mar 26 2014 - 15:37:48 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:48 UTC