netdev - Re: Linux ECN Handling

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: <CADVnQy=9xxQ2XH0rKhR+kHp6J9nOvM7e=6z-AJPAiTaap0e_bA@mail.gmail.com>
Date:   Tue, 5 Dec 2017 15:04:57 -0500
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Steve Ibanez <sibanez@...nford.edu>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Netdev <netdev@...r.kernel.org>, Florian Westphal <fw@...len.de>,
        Mohammad Alizadeh <alizadeh@...il.mit.edu>,
        Lawrence Brakmo <brakmo@...com>
Subject: Re: Linux ECN Handling

On Tue, Dec 5, 2017 at 2:36 PM, Steve Ibanez <sibanez@...nford.edu> wrote:
> Hi Neal,
>
> I've included a link to small trace of 13 packets which is different
> from the screenshot I attached in my last email, but shows the same
> sequence of events. It's a bit hard to read the tcptrace due to the
> 300ms timeout, so I figured this was the best approach.
>
> slice.pcap: https://drive.google.com/open?id=1hYXbUClHGbQv1hWG1HZWDO2WYf30N6G8

Thanks for the trace! Attached is a screen shot (first screen shot is
for the arriving packets with CWR; second is after the RTO). The
sender behavior looks reasonable. I don't see why the receiver is not
ACKing. As you say, it does look like a receiver bug. You could try
adding instrumentation to try to isolate why the receiver is not
sending an ACK immediately. You might instrument __tcp_ack_snd_check()
and tcp_send_delayed_ack() so that when the most recent incoming
packet had cwr set they printk to log what they are deciding in this
case. Perhaps the tcp_send_delayed_ack()  code is hitting the max_ato
= HZ / 2 code path?

neal

Download attachment "cwr-no-ack-1.png" of type "image/png" (9725 bytes)

Download attachment "cwr-no-ack-2.png" of type "image/png" (11703 bytes)