Serious Postfix weirdness
Hi all, I have got reports about lost mail(not received, im the receiver not the sender) recently and trying to find out whats going on seems to be beyond me. Basically a lot of email is lost with "timeout after DATA" For example: timeout after DATA (0 bytes) from mail.securepay.com.au[203.89.212.166] . Supposedly the problem here is that the sending machine has got a firewall in front of it thats blocking ICMP MUST FRAGMENT. I somewhat could verify this by trying to ping those machines and indeed pinging them does not work. On the Postfix website it suggests lowering MTU, so I lowered it from 1500 to 1000, but this did not improve the situation at all. Some suggest disabling PIPELINING, so i did that but it didnt work either. I took a tcpdump of one of these and attached it to this email. (daria is the name of the mail server) The system is running DragonFly 2.0.0 with ETHER_INPUT_CHAIN and ETHER_INPUT2 enabled. Just a note about my setup: The server is running behind a Cisco ADSL Router that connects to a Cisco switch and the server connects to the switch. Any Postfix gurus here that could help me figure this problem out? Thanks, Petr postfix_dump.tgz Description: application/tgz
Re: Serious Postfix weirdness
On Fri, Nov 14, 2008 at 08:15:04PM +1100, Petr Janda wrote: > Supposedly the problem here is that the sending machine has got a firewall > in front of it thats blocking ICMP MUST FRAGMENT. Is net.inet.tcp.path_mtu_discovery=1? Joerg
Re: Acer Aspire One (150)
On 14 Nov 2008, at 04:09, Justin C. Sherrill wrote: Could be; look at the dmesg if you can to see if it sees the device. It's possible that the network device is an ath(4) chipset, in which case you would have to boot a kernel with it compiled in? I'm guessing. It's an "Atheros L2 Fast Ethernet" (Sorry I couldn't find the chipset number). I'm fairly certain that it is supported by a recent driver added to FreeBSD head ( ale http://docs.FreeBSD.org/cgi/mid.cgi?20081030040637.GA78796 ). Can you dmesg from the remote computer? -- Chris
Re: Acer Aspire One (150)
On Fri, Nov 14, 2008 at 7:55 PM, Christopher Rawnsley <[EMAIL PROTECTED]> wrote: > On 14 Nov 2008, at 04:09, Justin C. Sherrill wrote: >> >> Could be; look at the dmesg if you can to see if it sees the device. It's >> possible that the network device is an ath(4) chipset, in which case you >> would have to boot a kernel with it compiled in? I'm guessing. > > It's an "Atheros L2 Fast Ethernet" (Sorry I couldn't find the chipset > number). I'm fairly certain that it is supported by a recent driver added to > FreeBSD head ( ale > http://docs.FreeBSD.org/cgi/mid.cgi?20081030040637.GA78796 ). > > Can you dmesg from the remote computer? Would you be interested to port it from FreeBSD? My plate is kinda full at the moment. Please feel free to ask questions on kernel@ or users@, if you want to do it. BTW, is anyone interested to port age(4)? I got a private mail from one of the possible users about it :) These two chips seem more and more common these days. However, I don't have any (they should be LOM). Best Regards, sephe -- Live Free or Die
Re: Acer Aspire One (150)
On 14 Nov 2008, at 12:09, Sepherosa Ziehau wrote: Would you be interested to port it from FreeBSD? My plate is kinda full at the moment. Please feel free to ask questions on kernel@ or users@, if you want to do it. I'll give it a go when I have a DF box up and running :) My driver development is nil. Are there any particular drivers in the tree that are general enough for me to see what system calls might need to be changed etc? What are the typical things that need changing? In fact... is it possible to compile this from the Live CD and have that PXE'd over to the netbook? -- Chris
Re: Acer Aspire One (150)
On Fri, November 14, 2008 7:19 am, Christopher Rawnsley wrote: > I'll give it a go when I have a DF box up and running :) My driver > development is nil. Are there any particular drivers in the tree that > are general enough for me to see what system calls might need to be > changed etc? What are the typical things that need changing? > > In fact... is it possible to compile this from the Live CD and have > that PXE'd over to the netbook? (Someone can correct me if I'm wrong, cause I haven't done this much) You could build a kernel with the driver built in and supply that on the machine serving the kernel image, and the netbook should be able to download and use it as normal. There are development accounts available on leaf.dragonflybsd.org, though you won't be able to test the driver directly there.
Re: Serious Postfix weirdness
> Is net.inet.tcp.path_mtu_discovery=1? > > Joerg No, it was set to 0. is it supposed to be set to 1? If so, should the default be 1? As far as documentation goes Ive read most of modern UNIX systems have it turned on by default. Cheers, Petr
Re: Serious Postfix weirdness
On Sat, Nov 15, 2008 at 04:31:55AM +1100, Petr Janda wrote: > > Is net.inet.tcp.path_mtu_discovery=1? > > > > Joerg > > No, it was set to 0. is it supposed to be set to 1? If so, should the default > be 1? As far as documentation goes Ive read most of modern UNIX systems have > it turned on by default. It might help. Joerg
Re: Serious Postfix weirdness
Joerg Sonnenberger wrote: On Sat, Nov 15, 2008 at 04:31:55AM +1100, Petr Janda wrote: Is net.inet.tcp.path_mtu_discovery=1? Joerg No, it was set to 0. is it supposed to be set to 1? If so, should the default be 1? As far as documentation goes Ive read most of modern UNIX systems have it turned on by default. It might help. Joerg Does anybody object to turning Path MTU Discovery on by default? It's been more than 15 years since it was introduced and everybody had a chance to learn about it by now. Is there a technical reason (e.g. related to where the Path MTU is stored), for having it off till now?
Re: Serious Postfix weirdness
On Fri, Nov 14, 2008 at 11:05:00PM +0200, Jordan Gordeev wrote: > Is there a technical reason (e.g. related to where the Path MTU is > stored), for having it off till now? Stupid network admistrators that consider all ICMP traffic evil and block it. But IMO it should be active by default. Joerg
Re: Serious Postfix weirdness
> It might help. > > Joerg Ive had it on for like 6 hours now but i dont think it made a difference. Thanks anyway. Im welcome to more suggestions. Petr
Re: Serious Postfix weirdness
> Stupid network admistrators that consider all ICMP traffic evil and > block it. But IMO it should be active by default. > > Joerg I really hate the fact there is so many stupid admins who would block ICMP because they think its evil, while they dont see the overwhelming goodness in a protocol like ICMP. I dont think they even know what it stands for and what its for, I noticed a lot of the mailservers are Postfix or (s)eXchange. One would have thought that at least the Linux admins would known what they are doing. Although it possible that a number of them are caused by the infamous Cisco PIX bug. Petr
