Following with this issue, disabling TSO does _not_ solve the problem in the lost of connection in an outbound email. It seems like a bug in Netfilter, not sure how to debug TCP conntrack, but it seems as if Netfilter lost the Established state for this connection. Looking at the traces, the only strange thing is that using tcpdump/libpcap in the server I see packets being sent before the previuos ACK is received, but I think this can't be posible, as the ACK number of this packet is needed before sending the next. I'm attaching the last traces taken with tso disabled. smtptrace_flash1_bad2.pcap <- packets taken in the destination server smtptrace_merak_bad2.pcap <- packets tanken in the source server (the one with problem). Analyzing the traces, it seems that a data packet is lost in transit to destination server, so the destination server send DUP ACKs trying to force the source server to resend this lost packet. But Netfilter is filtering these DUP ACKs (showed in the kernel logs) and so, the source server give up and reset the connection. I think this to be a bug in Netfilter code. Again, any help would be apreciated. Regards, Carlos Velasco CCNP & CCDP Cisco Certified Network Professional
Attachment:
smtptrace_merak_bad2.pcap
Description: Binary data
Attachment:
smtptrace_flash1_bad2.pcap
Description: Binary data
- References:
- Re: Networking messed up, bad checksum, incorrect length
- From: Herbert Xu <[email protected]>
- Re: Networking messed up, bad checksum, incorrect length
- Prev by Date: r8169 mac address change (was Re: [0/3] 2.6.19-rc2: known regressions)
- Next by Date: Re: [PATCH -mm] replacement for broken kbuild-dont-put-temp-files-in-the-source-tree.patch
- Previous by thread: Re: Networking messed up, bad checksum, incorrect length
- Next by thread: [PATCH: 2.6.18.1] delayacct: cpu_count in taskstats updated correctly
- Index(es):