lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <45452DEC.2070203@newipnet.com>
Date:	Sun, 29 Oct 2006 23:40:44 +0100
From:	Carlos Velasco <lkml@...ipnet.com>
To:	linux-kernel@...r.kernel.org, linux-net@...r.kernel.org
Subject: Re: Networking messed up, bad checksum, incorrect length

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


Download attachment "smtptrace_merak_bad2.pcap" of type "application/octet-stream" (5503 bytes)

Download attachment "smtptrace_flash1_bad2.pcap" of type "application/octet-stream" (6047 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ