linux-kernel - Re: After many hours all outbound connections get stuck in SYN

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: <47682F8C.20205@cosmosbay.com>
Date:	Tue, 18 Dec 2007 21:37:32 +0100
From:	Eric Dumazet <dada1@...mosbay.com>
To:	James Nichols <jamesnichols3@...il.com>
CC:	Jan Engelhardt <jengelh@...putergmbh.de>,
	linux-kernel@...r.kernel.org,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: After many hours all outbound connections get stuck in SYN_SENT

James Nichols a écrit :
>> Well... please dont start a flame war :(
>>
>> Back to your SYN_SENT problem, I suppose the remote IP is known, so you
>> probably could post here the result of a tcdpump ?
>>
>> tcpdump -p -n -s 1600 host IP_of_problematic_peer -c 500
>>
>> Most probably remote peer received too many attempts from you, and a
>> anti DOS mechanism is droping all SYN packets.
>>
>> Ah well... I remember now that you mentioned tcp_sack setting had an
>> effect, so forget the "Most probably..." and give some tcpdump traces :)
> 
> 
> I've run tcpdump for all IPs during this problem.  I haven't tried
> doing it for a single explicit IP address- due to the nature of the
> workload it's very difficult to know which IPs will be hit at any
> given moment.   What I did see in the full IP captures is that the
> returning ACKs don't show up in the packet capture.  Unfortunately,
> tcpdump reported that some packets were dropped during the capture.
> Is it possible that the kernel was dropping the packets before they
> could be captured by tcpdump?

Yes it can happens, because an active sniffer makes the stack using more
  cpu cycles (timestamping for example).

So you see outgoing SYN packets, but no SYN replies coming from the remote 
peer ?  (you mention ACKS, but the first packet received from the remote
  peer should be a SYN+ACK),

client->server   SYN
server->client   SYN+ACK
client->server   ACK


> 
> Also, I have some doubts about it being the end points or an
> intermediate router, please let me know if these are unreasonable:
> 1)  We've completely replaced our routing equipment several times in
> the past 4 years... totally different colos, router vendors, firewall
> vendors, firewall rules, etc.
> 2)  It occurs across all remote end points at the exact same time.
> The endpoints are hetrogenous, run brain-dead OS's that don't do any
> DOS detection, reboot at random times of the day, are geographically
> distributed, are on different ISPs, etc. etc.
> 3)  Turning of tcp_sack instantaneously makes the problem go away.  If
> it were endpoints or a router, it seems like a stretch that removing a
> single TCP option would make the problem instantly resolve itself in
> so many places other than the originating host.

CC to netdev where linux network guys might have an idea.

When the problem comes, instead of restarting the application, please take a 
tcpdump of say 10.000 packets.
Then turn off tcp_sack and take a 2nd tcpdump sample, and make both samples 
available to us.

If turning off tcp_sack makes the problem go away, why dont you turn it off 
all the time ?

--
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/