lost connection while sending end of data

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

lost connection while sending end of data

Stef Morrell
Hello,

Using 2.5.1 I've got what appears to be a common problem, multiple
instances of

lost connection with site.com [xxx.xxx.xxx.xxx] while sending end of
data -- message may be sent more than once

The server is not firewalled, has a public IP on the outgoing interface
and goes out via leased line connection.

The problem is particular to one site, who use postfix 1.1.12, going out
via watchguard firewall, through a zyxel prestige to ADSL.

Size of email doesn't seem to matter. Some emails are delivered fine,
whilst some stick for no apparent reason.

I've considered MTU issues, however my understanding is that my end
should fragment on request. Nevertheless I've gone as far as disabling
path MTU discovery (linux: echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc)
and this hasn't helped. I've also tried lowering the MTU at the
receiving end (and my end come to that!) down as low as 1000 but this
doesn't help either.

The site in question does tend to experience a lot of timeouts on
sending email, particularly large ones, so I am wondering if there's a
bandwidth issue going on. Equally possibly there is an issue in the
firewall with ICMP blocking, but I'm reliant on the sysadmin at the
remote end for admin of the watchguard.

I've got a tcpdump available at http://mort.level5.net/dump.gz of the
failing emails. Hopefully this will give a clue to the problem.

Many thanks.

Stef
Stefan Morrell          | Operations Director
Tel: 0845 3452820       | Alpha Omega Computers Ltd
Fax: 0845 3452830       | Incorporating Level 5 Internet
[hidden email]         | [hidden email]

Alpha Omega Computers Ltd, Unit 57, BBTC, Grange Road, Batley, WF17 6ER.
Registered in England No. 3867142.  VAT No. GB734421454
Reply | Threaded
Open this post in threaded view
|

Re: lost connection while sending end of data

Victor Duchovni
On Tue, Jun 24, 2008 at 07:26:40PM +0100, Stef Morrell wrote:

> Hello,
>
> Using 2.5.1 I've got what appears to be a common problem, multiple
> instances of
>
> lost connection with site.com [xxx.xxx.xxx.xxx] while sending end of
> data -- message may be sent more than once
>
> I've got a tcpdump available at http://mort.level5.net/dump.gz of the
> failing emails. Hopefully this will give a clue to the problem.

Some firewalls lose with window scaling.

    $ tcpdump -n -r dump 'tcp[13] & 0x12 == 0x2'
    13:20:08.355925 194.168.159.3.47510 > 84.45.179.178.25: S 3237125172:3237125172(0) win 5840 <mss 1460,sackOK,timestamp 1850561237 0,nop,wscale 7> (DF)
    13:20:08.355958 194.168.159.3.47511 > 84.45.179.178.25: S 3235363692:3235363692(0) win 5840 <mss 1460,sackOK,timestamp 1850561237 0,nop,wscale 7> (DF)
    13:20:08.364030 194.168.159.3.47512 > 84.45.179.178.25: S 3250245878:3250245878(0) win 5840 <mss 1460,sackOK,timestamp 1850561238 0,nop,wscale 7> (DF)
    13:20:08.364221 194.168.159.3.47513 > 84.45.179.178.25: S 3259539676:3259539676(0) win 5840 <mss 1460,sackOK,timestamp 1850561238 0,nop,wscale 7> (DF)

Your Linux system (2.6 or later) enables window scaling by default,
this could be an issue.

Looking at a specific session:

$ tcpdump -X -ttt -n -r dump tcp port 47512

000000 194.168.159.3.47512 > 84.45.179.178.25: S 3250245878:3250245878(0) win 5840 <mss 1460,sackOK,timestamp 1850561238 0,nop,wscale 7> (DF)

025505 84.45.179.178.25 > 194.168.159.3.47512: S 1547218149:1547218149(0) ack 3250245879 win 960 <wscale 0,nop,mss 960> (DF)

000014 194.168.159.3.47512 > 84.45.179.178.25: . ack 1 win 46 (DF)

3-way TCP complete.

070216 84.45.179.178.25 > 194.168.159.3.47512: P 1:47(46) ack 1 win 65535 (DF)
0x0020   5018 ffff 1e83 0000 3232 3020 736c 6f78                220.slox
0x0030   2e67 736d 7072 696d 6f67 7261 7068 6963        .gsmprimographic
0x0040   2e63 6f2e 756b 2045 534d 5450 2050 6f73        .co.uk.ESMTP.Pos
000010 194.168.159.3.47512 > 84.45.179.178.25: . ack 47 win 46 (DF)

000055 194.168.159.3.47512 > 84.45.179.178.25: P 1:28(27) ack 47 win 46 (DF)
0x0020   5018 002e 69c1 0000 4548 4c4f 206d 6169                EHLO.mai
0x0030   6c72 656c 6179 2e6c 6576 656c 352e 6e65        lrelay.level5.ne
0x0040   740d 0a                                        t..

002401 84.45.179.178.25 > 194.168.159.3.47512: P 47:131(84) ack 28 win 61440 (DF)
0x0020   5018 f000 124c 0000 3235 302d 736c 6f78                250-slox
0x0030   2e67 736d 7072 696d 6f67 7261 7068 6963        .gsmprimographic
0x0040   2e63 6f2e 756b 0d0a 3235 302d 5349 5a45        .co.uk..250-SIZE

000082 194.168.159.3.47512 > 84.45.179.178.25: P 28:78(50) ack 131 win 46 (DF)
0x0020   5018 002e 69d8 0000 4d41 494c 2046 524f                MAIL.FRO
0x0030   4d3a 3c65 6469 746f 7240 7275 6e6e 6572        M:<editor@runner
0x0040   7377 6f72 6c64 2e63 6f2e 756b 3e20 5349        sworld.co.uk>.SI

012058 84.45.179.178.25 > 194.168.159.3.47512: P 131:139(8) ack 78 win 61390 (DF)
0x0020   5018 efce 414d 0000 3235 3020 4f6b 0d0a                250.Ok..

000122 194.168.159.3.47512 > 84.45.179.178.25: P 78:127(49) ack 139 win 46 (DF)
0x0020   5018 002e 69d7 0000 5243 5054 2054 4f3a                RCPT.TO:
0x0030   3c6b 6569 7468 7269 6368 6172 6473 6f6e        <XXXXXXXXXXXXXXX
0x0040   4062 7265 636f 6e2e 6773 6d67 726f 7570        @brecon.gsmgroup

011967 84.45.179.178.25 > 194.168.159.3.47512: P 139:147(8) ack 127 win 61341 (DF)
0x0020   5018 ef9d 4145 0000 3235 3020 4f6b 0d0a                250.Ok..

000034 194.168.159.3.47512 > 84.45.179.178.25: P 127:133(6) ack 147 win 46 (DF)
0x0020   5018 002e 69ac 0000 4441 5441 0d0a                     DATA..

001196 84.45.179.178.25 > 194.168.159.3.47512: P 147:184(37) ack 133 win 61335 (DF)
0x0020   5018 ef97 cf0d 0000 3335 3420 456e 6420                354.End.
0x0030   6461 7461 2077 6974 6820 3c43 523e 3c4c        data.with.<CR><L
0x0040   463e 2e3c 4352 3e3c 4c46 3e0d 0a               F>.<CR><LF>..

001624 194.168.159.3.47512 > 84.45.179.178.25: . 133:1093(960) ack 184 win 46 (DF)
0x0020   5010 002e 6d66 0000 5265 6365 6976 6564                Received
0x0030   3a20 6672 6f6d 206e 6577 7331 2e6d 6167        :.from.news1.mag
0x0040   6963 616c 6961 2e63 6f6d 2028 6e65 7773        icalia.com.(news
000028 194.168.159.3.47512 > 84.45.179.178.25: . 1093:2053(960) ack 184 win 46 (DF)

So far so good, message body starts at TCP sequence 133 (receiver @184),
segments are 960 bytes. Something goes haywire after the message segment
of 320 bytes ending at 36677. The receiving system sends a FIN after
processing payload trhough 27077, each FIN retransmit ACKs more data.

000982 84.45.179.178.25 > 194.168.159.3.47512: . ack 17477 win 61440 (DF)
000015 194.168.159.3.47512 > 84.45.179.178.25: . 35717:36677(960) ack 184 win 46 (DF)
000005 194.168.159.3.47512 > 84.45.179.178.25: P 36677:36997(320) ack 184 win 46 (DF)
000968 84.45.179.178.25 > 194.168.159.3.47512: . ack 18437 win 61440 (DF)
000034 194.168.159.3.47512 > 84.45.179.178.25: . 36997:37957(960) ack 184 win 46 (DF)
000768 84.45.179.178.25 > 194.168.159.3.47512: . ack 19397 win 61440 (DF)
002791 84.45.179.178.25 > 194.168.159.3.47512: . ack 20357 win 61440 (DF)
003618 84.45.179.178.25 > 194.168.159.3.47512: . ack 22277 win 59520 (DF)
003764 84.45.179.178.25 > 194.168.159.3.47512: . ack 24197 win 57600 (DF)
004195 84.45.179.178.25 > 194.168.159.3.47512: . ack 26117 win 55680 (DF)
000994 84.45.179.178.25 > 194.168.159.3.47512: . ack 27077 win 60560 (DF)
001394 84.45.179.178.25 > 194.168.159.3.47512: . ack 27077 win 60560 (DF)
000796 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 27077 win 60560 (DF)
000996 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 28037 win 59600 (DF)
000025 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
001174 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 28037 win 61440 (DF)
000017 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)

037687 194.168.159.3.47512 > 84.45.179.178.25: FP 37957:38150(193) ack 185 win 4
6 (DF)
0x0020   5019 002e 6a67 0000 7370 616d 2061 6e64                spam.and
0x0030   2064 616e 6765 726f 7573 2063 6f6e 7465        .dangerous.conte
0x0040   6e74 2e0d 0a3c 6272 202f 3e46 6f72 206d        nt...<br./>For.m
0x0050   6f72 6520 696e 666f 726d 6174 696f 6e20        ore.information.
0x0060   706c 6561 7365 2076 6973 6974 203c 6120        please.visit.<a.
0x0070   6872 6566 3d22 6874 7470 3a2f 2f77 7777        href="http://www
0x0080   2e6c 356e 6574 2e6e 6574 2f22 3e3c 623e        .l5net.net/"><b>
0x0090   414f 4320 496e 7465 726e 6574 204c 7464        AOC.Internet.Ltd
0x00a0   3c2f 623e 3c2f 613e 2e0d 0a3c 2f68 746d        </b></a>...</htm
0x00b0   6c3e 0d0a 0d0a 2d2d 2d2d 2d2d 3d5f 4e65        l>....------=_Ne
0x00c0   7874 5061 7274 5f30 3030 5f42 3134 3935        xtPart_000_B1495
0x00d0   5f30 3143 3844 3236 442e 3330 3245 4630        _01C8D26D.302EF0
0x00e0   4230 2d2d 0d0a 2e0d 0a                         B0--.....

Here you send the end of the message. After that the receiving system
acks the rest of the payload and the connection is finally torn down.

    135028 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 28997 win 60480 (DF)
    000013 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000010 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 28997 win 61440 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000365 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 29957 win 60480 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000193 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 29957 win 61440 (DF)
    000005 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000790 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 30917 win 60480 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    001191 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 30917 win 61440 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000591 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 31877 win 60480 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    001002 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 31877 win 61440 (DF)
    000005 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000981 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 32837 win 60480 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    001790 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 32837 win 61440 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000591 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 33797 win 60480 (DF)
    000007 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000791 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 33797 win 61440 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    001191 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 34757 win 60480 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    012334 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 34757 win 61440 (DF)
    000005 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000003 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 35717 win 60480 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 35717 win 61440 (DF)
    000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36677 win 60480 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36677 win 61440 (DF)
    000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36997 win 61120 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36997 win 61120 (DF)
    000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 60160 (DF)
    000005 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000229 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 61440 (DF)
    000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    000003 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 61440 (DF)
    000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
    082709 84.45.179.178.25 > 194.168.159.3.47512: . ack 38151 win 61247 (DF)

So the question is why did the sender abort the delivery mid-stream? Hard
to say. Broken firewall?

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: lost connection while sending end of data

Wietse Venema
Victor Duchovni:

>     000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36677 win 60480 (DF)
>     000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36677 win 61440 (DF)
>     000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36997 win 61120 (DF)
>     000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 36997 win 61120 (DF)
>     000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000004 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 60160 (DF)
>     000005 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000229 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 61440 (DF)
>     000006 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     000003 84.45.179.178.25 > 194.168.159.3.47512: F 184:184(0) ack 37957 win 61440 (DF)
>     000004 194.168.159.3.47512 > 84.45.179.178.25: . ack 185 win 46 (DF)
>     082709 84.45.179.178.25 > 194.168.159.3.47512: . ack 38151 win 61247 (DF)

[at this point the entire payload has arrived]

> So the question is why did the sender abort the delivery mid-stream? Hard
> to say. Broken firewall?

Either this, or someone has modified Postfix and inserted code
that does shutdown(sock, SHUT_WR).

If there the receiving socket were closed, then I would expect the
server to send RSETs instead of FINs.  There is not code in Postfix
that shuts down the sending side of a socket only.

So the more likely explanation is a broken firewall, maybe ticked
of by window scaling.

        Wietse
Reply | Threaded
Open this post in threaded view
|

RE: lost connection while sending end of data

Stef Morrell
In reply to this post by Stef Morrell
Viktor wrote:

> On Tue, Jun 24, 2008 at 07:26:40PM +0100, Stef Morrell wrote:
>
>> Hello,
>>
>> Using 2.5.1 I've got what appears to be a common problem, multiple
>> instances of
>>
>> lost connection with site.com [xxx.xxx.xxx.xxx] while sending end of
>> data -- message may be sent more than once
>>
>> I've got a tcpdump available at
> http://mort.level5.net/dump.gz of the
>> failing emails. Hopefully this will give a clue to the problem.
>
> Some firewalls lose with window scaling.
>
<snip packet dump>
>
> Your Linux system (2.6 or later) enables window scaling by
> default, this could be an issue.

Turning off window scaling...

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

doesn't help. For clarity

http://mort.level5.net/dump2.gz 

shows the traffic with window scaling disabled.

> Looking at a specific session:
>
<snip again>
>
> So the question is why did the sender abort the delivery
> mid-stream? Hard to say. Broken firewall?

Sorry, I'm confused - I'm the sender and not firewalled. You are saying
my server aborted the delivery?

Stef
Stefan Morrell          | Operations Director
Tel: 0845 3452820       | Alpha Omega Computers Ltd
Fax: 0845 3452830       | Incorporating Level 5 Internet
[hidden email]         | [hidden email]

Alpha Omega Computers Ltd, Unit 57, BBTC, Grange Road, Batley, WF17 6ER.
Registered in England No. 3867142.  VAT No. GB734421454
Reply | Threaded
Open this post in threaded view
|

RE: lost connection while sending end of data

Stef Morrell
In reply to this post by Victor Duchovni
Wietse Venema wrote:
<snip dump>
> [at this point the entire payload has arrived]
>
>> So the question is why did the sender abort the delivery mid-stream?
>> Hard to say. Broken firewall?
>
> Either this, or someone has modified Postfix and inserted
> code that does shutdown(sock, SHUT_WR).

My end is stock 2.5.1, built from source. The receiving end is, I
believe, a hacked with 1.1.14, part of an old Suse Linux OpenExchange
implementation. From what I can see there's a lot of non-standard
options in main.cf - though I could be wrong.

> So the more likely explanation is a broken firewall, maybe
> ticked of by window scaling.

What might be broken in the firewall?

Stef
Stefan Morrell          | Operations Director
Tel: 0845 3452820       | Alpha Omega Computers Ltd
Fax: 0845 3452830       | Incorporating Level 5 Internet
[hidden email]         | [hidden email]

Alpha Omega Computers Ltd, Unit 57, BBTC, Grange Road, Batley, WF17 6ER.
Registered in England No. 3867142.  VAT No. GB734421454
Reply | Threaded
Open this post in threaded view
|

Re: lost connection while sending end of data

Victor Duchovni
In reply to this post by Stef Morrell
On Wed, Jun 25, 2008 at 10:39:42AM +0100, Stef Morrell wrote:

> echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
>
> doesn't help. For clarity
>
> http://mort.level5.net/dump2.gz 
>
> shows the traffic with window scaling disabled.

Indeed no window scaling.

    05:28:17.473188 194.168.159.3.53339 > 84.45.179.178.25: S 1874608731:1874608731(0) win 5840 <mss 1460,sackOK,timestamp 1856369883 0> (DF)
    05:28:17.475295 194.168.159.3.53340 > 84.45.179.178.25: S 1869120603:1869120603(0) win 5840 <mss 1460,sackOK,timestamp 1856369883 0> (DF)
    05:28:17.475800 194.168.159.3.53341 > 84.45.179.178.25: S 1866467599:1866467599(0) win 5840 <mss 1460,sackOK,timestamp 1856369883 0> (DF)
    05:28:17.476037 194.168.159.3.53342 > 84.45.179.178.25: S 1871208871:1871208871(0) win 5840 <mss 1460,sackOK,timestamp 1856369883 0> (DF)

So the problem is elsewhere...

> > Looking at a specific session:
> > So the question is why did the sender abort the delivery
> > mid-stream? Hard to say. Broken firewall?
>
> Sorry, I'm confused - I'm the sender and not firewalled. You are saying
> my server aborted the delivery?

Yes, sorry, the SMTP server. It performed a half-close on the SMTP socket,
or the firewall did it, a proxy in front of the receiving Postfix.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

RE: lost connection while sending end of data

Stef Morrell
In reply to this post by Stef Morrell
Viktor wrote:
> On Wed, Jun 25, 2008 at 10:39:42AM +0100, Stef Morrell wrote:
> Yes, sorry, the SMTP server. It performed a half-close on the
> SMTP socket, or the firewall did it, a proxy in front of the
> receiving Postfix.

There is a watchguard firebox in front of the receiving postfix. As far
as I can tell it does NAT on outgoing connections with a port forwarding
for incoming connections.

I shall go away and commence the delicate process of suggesting we test
the connection with some other device in place and see what happens.

Meantime, I guess it's possible that a dump from the other end might be
useful in diagnosis.

http://mort.level5.net/bdump.gz

It's quite big, so a couple of typical streams can be found on source
ports 46459 (to some polish server) or on 46636 (to me).

In both cases the sessions seem to start up fine until finally devolving
into a succession of zerowindow and keepalive packets until the
receiving server times out, in the first instance silently, or in the
second instance with a standard postfix error, correctly generated after
the configured 300 seconds.

Regards

Stef
Stefan Morrell          | Operations Director
Tel: 0845 3452820       | Alpha Omega Computers Ltd
Fax: 0845 3452830       | Incorporating Level 5 Internet
[hidden email]         | [hidden email]

Alpha Omega Computers Ltd, Unit 57, BBTC, Grange Road, Batley, WF17 6ER.
Registered in England No. 3867142.  VAT No. GB734421454
Reply | Threaded
Open this post in threaded view
|

Re: lost connection while sending end of data

Victor Duchovni
On Wed, Jun 25, 2008 at 04:39:18PM +0100, Stef Morrell wrote:

> Viktor wrote:
> > On Wed, Jun 25, 2008 at 10:39:42AM +0100, Stef Morrell wrote:
> > Yes, sorry, the SMTP server. It performed a half-close on the
> > SMTP socket, or the firewall did it, a proxy in front of the
> > receiving Postfix.
>
> There is a watchguard firebox in front of the receiving postfix. As far
> as I can tell it does NAT on outgoing connections with a port forwarding
> for incoming connections.
>
> I shall go away and commence the delicate process of suggesting we test
> the connection with some other device in place and see what happens.

First find all SMTP-aware features in the firewall and turn them off.
Indeed this firewall is the first thing to suspect.

--
        Viktor.

Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.

To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[hidden email]?body=unsubscribe%20postfix-users>

If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
Reply | Threaded
Open this post in threaded view
|

Re: lost connection while sending end of data

Wietse Venema
In reply to this post by Stef Morrell
Stef Morrell:
> Wietse Venema wrote:
> <snip dump>
> > [at this point the entire payload has arrived]
> >
> >> So the question is why did the sender abort the delivery mid-stream?
> >> Hard to say. Broken firewall?
> >
> > Either this, or someone has modified Postfix and inserted
> > code that does shutdown(sock, SHUT_WR).
...
> > So the more likely explanation is a broken firewall, maybe
> > ticked of by window scaling.
>
> What might be broken in the firewall?

It's not smart for the receiver to do shutdown(sock, SHUT_WR),
meaning that the remote end won't send more data, when it is unhappy
about the data that your system is sending. Reason: the sending system
will retransmit the mail forever (until it expires in the queue).

        Wietse