[ previous ] [ next ] [ threads ]
 From:  "Neil A. Hillard" <m0n0 at dana dot org dot uk>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] bad tcp cksum
 Date:  Wed, 4 Oct 2006 19:53:56 +0100

In message <4523CF99 dot 1050406 at buehlertech dot com>, Jeff Buehler
<jeff at buehlertech dot com> writes
>I think Neil is just saying it may be worth exploring other possible
>reasons for the email to be failing rather than focusing on the bad TCP
>checksums, which may or may not be related (is that right, Neil?).  It
>seems to me that that woulds be a indication of part of the problem,
>though, but it may confuse the issue.  For example, are you certain
>that the Postfix server doesn't have problems with large emails in
>general?  I was having an issue with a mail server that had memory
>corruption due to memory timings in the bios that ONLY failed on very
>large email transfers (over 1.5 meg) and it took me quite a while to
>discover the cause, or even the problem, since none of my users
>reported it for a very long time.
>If it were me, I would try sending large emails from other locations to
>verify the server is functioning properly (just to discount that as a
>possibility), then I would try sending large files from the M0n0 VPN
>via FTP to see if the failure is specific to SMTP.  I would suspect
>memory on the M0n0, or the network card.  I have found with M0n0wall
>that using IPSEC changing the type of compression makes a difference
>with MTU issues (PPTP doesn't have that option). Finally messing with
>MTU settings is the only thing left, and I have had very significant
>problems that were hard to correct with MTU (just changing this and
>that didn't work - it required very deliberate changes on a number of
>systems along with reboots in some cases) running M0n0wall to Windows
>systems specifically.

Yep.  My point was that the bad checksums may just lead you down the
wrong path and waste your time.

To confirm whether this is a problem or is just TCP offloading, perform
a packet capture using a separate machine, either in a tap, a spanned
port on a manageable switch or a hub.

At least that way you'll know if this really is a problem.



>Andreas Ferrari wrote:
>> > This is probably a red herring.
>> Thanks for your answer....
>> Dou you think i will report something that i have dreamd?
>> The fact is that it still not working, I tried lowering the mtu
>>without sucess...
>> So if you or someone have any ideas what there could be wrong please
>>give me a hint.
>> Neil A. Hillard schrieb:
>>> Hi,
>>>         I've been away for a while and haven't seen a response to this
>>> but apologies if I've missed it.
>>> In message <451A397A dot 8010006 at stasoft dot ch>, Andreas Ferrari
>>> <aferrari at stasoft dot ch> writes
>>>> One of our customer has a VPN from his home office (wrap+m0n0 ver 1.22)
>>>> to his office (wrap+m0n0 ver 1.22), that works fine. When he tries to
>>>> send a mail from home over the VPN to the postfix server then the mail
>>>> is never delivered to the mailserver.
>>>> I noticed that small plaintext messages can be delivered to the postfix
>>>> server but if the mail gets bigger then only the first part of the data
>>>> are sent.
>>>> On the mailserver i started tcpdump and could see that the mail could
>>>> not be sent because there are a lot of bad tcp cksum messages.
>>>> So the mailserver gets the first part right and the rest of the data
>>>> are bad. How could that happend?
>>> This is probably a red herring.  I suspect that you'll find that this is
>>> due to TCP Checksum Offloading.  I spent a couple of days chasing what I
>>> thought were problems cause by this - turns out it was something else.
>>> HTH,
>>>                                 Neil.
>To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
>For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch

Neil A. Hillard                E-Mail:   m0n0 at dana dot org dot uk