linux-kernel - RE: TCP stack behaviour question

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <006301c6dbf4$035a71c0$294b82ce@stuartm>
Date:	Tue, 19 Sep 2006 10:00:49 -0400
From:	"Stuart MacDonald" <stuartm@...necttech.com>
To:	"'Samuel Tardieu'" <sam@...1149.net>,
	<linux-kernel@...r.kernel.org>
Subject: RE: TCP stack behaviour question

From: On Behalf Of Samuel Tardieu
> >>>>> "Stuart" == Stuart MacDonald <stuartm@...necttech.com> writes:
> Stuart> I suppose that the TCP retransmits aren't being sent because
> Stuart> the ethernet and/or IP layers don't know what's going on,
> Stuart> which is what's producing the arps. Is that correct?
> 
> It seems correct. You cannot expect TCP packets to be sent if the
> target is supposedly on a directly connected network and ARP cannot
> get its MAC address. What should the IP layer put as the MAC address
> if it is unknown?

I'd agree, but the MAC is/was known. Only part way through the
sequence of retransmits (with MAC filled in) do the arps start. Also,
tellingly maybe, the first three arps are sent directly to the
unreachable MAC. Only after those are unanswered are broadcast arps
attempted.

Ah, interesting, see below. ***

> You may want to run another test with another unreachable target
> located after a router, so that the MAC address of the router is used
> on the wire. You should see all the TCP retransmits you expect to see.

I'll try that if I have time, but I agree, I expect to see all the
retransmits in that case.

*** I found arp(7) and read up on it while I was typing. And now I see
something interesting in the tcpdump; my app is actually talking on
two TCP connections at the same time. Both are in retransmit phase,
and the first arp is 5 seconds (delay_first_probe_time) after an
_aggregate total_ of 15 retransmits (being the two original unanswered
packets and 7 and 6 retransmits of each).

My reading of tcp(7)'s documentation of tcp_retries2 is that
tcp_retries2 is a per-TCP packet count. My tcpdump seems to show that
it is in fact a global count. Which is correct?

..Stu

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/