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]

Message-id: <47CD5D43.9020408@nets.rwth-aachen.de>
Date:	Tue, 04 Mar 2008 15:31:31 +0100
From:	Arnd Hannemann <hannemann@...s.rwth-aachen.de>
To:	Ilpo Järvinen <ilpo.jarvinen@...sinki.fi>
Cc:	Netdev <netdev@...r.kernel.org>
Subject: Re: TCP IPv4 strange retransmits

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