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: <CADVnQyk5EDY8ZVJysjbwZ5Ws=yc7kuZS=jMxh57cAKgEdAva_Q@mail.gmail.com>
Date:   Mon, 21 Aug 2017 10:17:07 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Akshat Kakkar <akshat.1984@...il.com>
Cc:     David Laight <David.Laight@...lab.com>,
        Eric Dumazet <eric.dumazet@...il.com>,
        netdev <netdev@...r.kernel.org>
Subject: Re: Something hitting my total number of connections to the server

On Mon, Aug 21, 2017 at 5:56 AM, Akshat Kakkar <akshat.1984@...il.com> wrote:
>
> The issue is with tcp timestamp. When I am disabling it, things are
> working fine but when I enable the issue re-occurs. However, I am not
> seeing tcp timestamps on packet, even when it is enabled simply
> because my client doesn't support it.
>
> But the question is, if I my client doesnt support timestamp , why
> enabling timestamp on server side is creating an issue??

To help shed light on this, you could try collecting and dumping the
nstat counters when the system is in the mode where it is not
creating/accepting new connections, e.g.:

nstat > /dev/null && sleep 10 && nstat

The sleep interval would need to be long enough to cover a failing
client connect attempt. It would also be helpful to gather a tcpdump
trace over the interval, to see if the server is sending a RST,
SYN+ACK, or nothing.

neal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ