Ok i missunderstod you and yestarday was not really my day.
I hope you accept my excuse.
Yes the postfix server works, I tested it with other VPN connections and
large Mails so it cannot be the a problem of the postfix server.
I also checked the transfer of files to the fileserver.
Maybe its really a problem with the Memory of the M0n0 or the FlashCard,
hope it works with a new one. And the last option is the MTU story..
I will keep you up-to-date....
Neil A. Hillard schrieb:
> 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
> 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
>>>So if you or someone have any ideas what there could be wrong please
>>>give me a hint.
>>>Neil A. Hillard schrieb:
>>>> 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
>>>>>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.
>>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
P: +41 61 726 80 70
F: +41 61 726 80 79