netdev - Re: TCP IPv4 strange retransmits

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] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Mar 2008 22:04:09 +0100
From:	"H. Willstrand" <h.willstrand@...il.com>
To:	"Arnd Hannemann" <hannemann@...s.rwth-aachen.de>
Cc:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>,
	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP IPv4 strange retransmits

On Tue, Mar 4, 2008 at 3:31 PM, Arnd Hannemann
<hannemann@...s.rwth-aachen.de> wrote:
> Hi,
>
>
>  Ilpo Järvinen wrote:
>  > On Tue, 4 Mar 2008, Arnd Hannemann wrote:
>  >
>  >> I'm observing some retransmits with kernel 2.6.24.2, which I don't
>  >> understand. For instance in this cutout[1] of a sequence diagram which
>  >> was captured[2] on the TCP sender, 4 retransmits are made.
>  >
>  > They don't correspond to each other?
>
>  Hmm, they should.
>
>
>  >
>  >> According to netstat -st output[3][4] all those 4 retransmits were "fast
>  >> retransmit".
>  >> But there are no three DUPACKs which I expected would be needed for fast
>  >> retransmit?
>  >
>  > With FACK it's enough that you have fackets_out > tp->reordering
>  > (=dupThresh).
>
>  If it is FACK shouldn't it be accounted for LINUX_MIB_TCPFORWARDRETRANS
>  instead of LINUX_MIB_TCPFASTRETRANS?
>
>
>  >
>  >> Also interesting all retransmits happen _after_ those segments were
>  >> already acked and sacked, internal queuing or latency issues?
>  >
>  > I think your viewer is doing something wrong, sender.dump is not giving
>  > such information (or you draw that from wrong end?). Or it just draws
>  > DSACK like that?
>
>  Viewer is tcptrace and xplot. So nothing special at all.
>  You see it also in wireshark, if you draw a sequence diagram.
>  You also see it in wireshark if you sort by capture timestamp. I always thought
>  that capture timestamp order is correct and not dump order, but maybe I'm wrong?
>
>  Tcpdump:
>
>  12:08:20.667538 IP 192.168.0.7.33824 > 192.168.0.5.50139: . ack 23485 win 22720 <nop,nop,timestamp 969759 972885,nop,nop,sack 2 {24905:26325}{27745:29165}>
>  ^^^^^ got acked at .667538
>
>  12:08:20.646749 IP 192.168.0.5.50139 > 192.168.0.7.33824: . 22065:23485(1420) ack 1 win 2864 <nop,nop,timestamp 972885 969754>
>  ^^^^^ got retransmitted at .646749
>
>
>  >
>  >> It would be great if somebody could shed some light on this,
>  >> why those segments are retransmitted.
>  >> Dumps and xplots are available here[5].
>  >
>  > ...I quickly glanced over it and found no strange behavior in
>  > the sender.dump.
>
>  Best regards,
>  Arnd
>
>
>
>  --
>  To unsubscribe from this list: send the line "unsubscribe netdev" in
>  the body of a message to majordomo@...r.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Hi!

I recommend you to capture packages both on sender-side and
receiver-side to verify the tcpdump.

Regards,
Harri
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html