From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=fail (p=none dis=none) header.from=gmail.com Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) by passt.top (Postfix) with ESMTPS id 7E0005A0265 for ; Thu, 12 Nov 2026 17:09:34 +0100 (CET) Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-844a8bf7e25so3217068a34.1 for ; Thu, 12 Nov 2026 08:09:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1794499773; cv=none; d=google.com; s=arc-20260327; b=Xr5fD5QHJWP7zXyvBguOyLn4/vSt/whBdGFS/ZVbGgUilmGgaFrCSYFlfdp58yiun7 JT6/sI+q4qoNpVtbPLLWd/Vr/EdKvIi97yY5uiN9vJjp2790VxZhz1fRuR7REhOd5hR5 bNb/XEmdy6JCHfTVUqs9N45WXifvowufbYLKppg6cw5avNhAYKfX0z47XdFTwJ6SQTng 2uH0eUzheSUmhxxey0gyZdYbJgqYit6KTbG4kwuRQGocXQVP4vZvljc6QRkNQ6YJzAT1 IQA22h6sU0R+m+rdcVhPTNNDNLH7C9FgfGOd1YTVs008lxhmX+yVZMyocNepvru/OUxJ /4TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20260327; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=bSiJz54NQzcCodu4oYyfHS9bYkf0oUdpxmzEF8/Xi4Y=; fh=htis3z6nDPD3FFPmKX7SGQyhLv1B9tDlnJYWrC8d10o=; b=mdfrYs1/3RyJaner8YcGCOyP8lN0HNobAczCht6FqvKrUVGNzXOs892uxOSTtGxbKM 3P7o4cR6SYzp9y/JDEl6IDzwarzKzHZKUtkeWqm1K8HLXg08vaD9Wz7ZiITiY9CMM4aA RWFpI6fViMeFOSrz0slmMQ443Re9tbNaPCqchE0metSEJCAfjAuMSLmWpAhrRZg5mS2X 2z9dWZ6d3Q9EEG2iB3D0FjLOQSKz4vr11udN2ELW5IN31JgjF9NCFlnp/MctpAVIbvKB d/dP4S1AV6Wxf2WReaJqVMvNVo7RGSJXky8rS1VRRCdn6zUuXzOMkrnE1SXjWLg9rTd7 LBTA==; darn=passt.top ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20260707; t=1794499773; x=1795104573; darn=passt.top; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to :content-type; bh=bSiJz54NQzcCodu4oYyfHS9bYkf0oUdpxmzEF8/Xi4Y=; b=EipTlJxy94cgsNIVQ5lEy5lMwNSGaY7Dnkjae7BZQNkkkjhD2cfwkR7J0AWuYakZvz 5RrOcnn53BruNiNUMzos6guuIbPSc6S97DohAzbbFNk0DlZOEkLf1kh4Spi7LyztmDYR 8Z4z5im1yzzQguobsexDF07/jIRNKHz6XcsX1010uH/pYyl1QImUII+PVVlnP8JAQxW+ NgEqHeGVV68ZUms8qcH9ljg2y0rhvpEXv+jVC21EB837B+iAzKUdogowhatkafzsmPti 7dc4+Sk+voKQqyXLy7r5UdNHyK17JCWVD9Q8lkK0CWp6pXI4ZSb0AZ02q877VSwQ0SUT Yw+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1794499773; x=1795104573; h=content-type:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to:content-type; bh=bSiJz54NQzcCodu4oYyfHS9bYkf0oUdpxmzEF8/Xi4Y=; b=w0QPHse+cJAad+nRBJElSXYSg8P7k+4dL4bieyHpZArVjOpVG/1lQrvW/BAfsblT0a GFlpRstQICyFhml8h1/0RGu8yaQd3U5Tvcz+EGK61BfJvgMtpcnN2efgtd9/GBb/Ii4/ Fh6Q3cSWElzWodLjVptBRcEYA00zDu4JnnbD1zVyN4HSMUvYqEL44YFM1kICgEx1vRo6 RsPPqlyyPfzD3WrFo7mX6dm9Iuzx6BiPfsStGse2OpKNRhSgnBFH43Sh8D1EEvoC/d+F pXb8BVjRX0FOZakbOPEjpBzUzCxn2jJxonC7hAlHeV6kQKI2u0W7D9W+wGv+OmgeMnVa io6w== X-Gm-Message-State: APuU4Z8tSWguhgKn64TGVgxBgeqlX+EmOLo1VF/fjLLLSTyPzGGCKWdP F1qtbH4cAOC0vMnJ1BUctrsDeyJr5SmUdsJcU6tpGitkYjhInEjrr1uU+Iz64fhuSM2k6LAlQxy GSozGrqIVPVC5QqmZzROQjtdkKZGEGJs= X-Gm-Gg: AYBFou018+NpYjg4SgHGm6eYkqfNGQdGg6OOivy+8UkLL2M6dTOtd4Pdn+5a4CPo+r/ nOC18A0B6/gz8R7I599Y0YAEmVA8AwOJvmljEoQDcS+465U6z3tsiB/13twAcJy7Q8qFj9FPKoU Xa9FIhHDXa2cnPPNUpktTiaBawLtvL/9n8otdWXfsIFDWVFQlNXFDBY5r07S5B48+Z9zCxVxJFQ wqDpIirthNbZhPNVP7pVaTMFuys/3LWYm9xN3xxGt28dlT1ECkzaLE12++mCq3BfO4KbcrEj1OW fdr2O16zmuzMXF6jk3i4W/ngB9Mg7Jwacdm+Wsn+SlJ/hYWHMVE5aY5mrfeUNlMe6jPe8Jhhw8Z cBK6XJT3/RQtziKNg80uNTVgWUwVYWyUUwL2Pqg== X-Received: by 2002:a05:6830:3109:b0:828:d647:332c with SMTP id 46e09a7af769-860f293ce88mr6880127a34.25.1794499772902; Thu, 12 Nov 2026 08:09:32 -0800 (PST) MIME-Version: 1.0 References: <20261104145322.2dc73741@elisabeth> In-Reply-To: <20261104145322.2dc73741@elisabeth> From: Lynxes Exe Date: Thu, 12 Nov 2026 17:09:20 +0100 X-Gm-Features: AclHuK9ZkPH5IqnTOmbkqkHGwUjp3wDrOGYveEYoYC1ca91zsRZUiH5tkh49pJI Message-ID: Subject: Re: tcp: peer stuck in low_rtt_dst table loses window clamping, every new connection stalls on RTOs To: Stefano Brivio Content-Type: multipart/mixed; boundary="00000000000083930a0660168980" X-MailFrom: lynxes.exe@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation Message-ID-Hash: 7NNFRYFIOIFEP6UYFJXVBPWH6OWVM25U X-Message-ID-Hash: 7NNFRYFIOIFEP6UYFJXVBPWH6OWVM25U X-Mailman-Approved-At: Thu, 12 Nov 2026 17:12:08 +0100 CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000083930a0660168980 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stefano, I apologize for the long wait. The issue took a while to represent itself. As usual, this was done with the assistance of Claude. After the issue occurred again the table got extracted to show that in fact two IPs that were not supposed to be there got in the table (more details below). Also, thanks to both of you for the responses. Original response --------------------------- Thanks for going through it. The stalls came back this week, about two weeks after the last pasta restart, so we could check what you asked on a live instance. 1. The insertion, now demonstrated The pasta in Docker's rootless bundle is static, non-PIE and not stripped, so low_rtt_dst sits at a fixed address. We read it as root from /proc//mem while pasta kept running: slot 0 10.0.0.181 the host's own LAN address slot 1 192.168.5.3 a WireGuard peer, over the Internet slot 2 10.0.0.80 the host's second address slot 3 192.168.122.1 libvirt bridge, host side slot 4 10.0.0.187 a Windows desktop on Wi-Fi, RTT 2-6 ms slot 5-7 empty The desktop was the peer that stalled: through pasta it got 14-33 KB/s, with retransmissions and backoff inside the namespace, while SSH from the same machine to the host ran at about 9 MB/s. 10.0.0.1 from the first report wasn't there, because pasta had been restarted since. 2. Why: the ~0U case, reproduced For a passively opened socket, the handshake gives no RTT sample if the SYN-ACK was retransmitted (tcp_synack_rtt_meas() only measures when req->num_retrans is 0, and a retransmitted SYN from the client also increments it, via tcp_rtx_synack()). The only fallback is the timestamp echo in tcp_ack_update_rtt(), so if the client didn't negotiate timestamps, tcpi_min_rtt is still ~0U when pasta checks it. Windows doesn't offer timestamps on the connections it opens, by default, which fits the desktop. Reproducer: from a Linux client with net.ipv4.tcp_timestamps =3D 0, drop incoming SYN-ACKs from the pasta host for 2 seconds, with an nftables input rule on the client's fixed local port, while connecting to a port that pasta forwards. The client's SYN retries make the server retransmit the SYN-ACK, and the connection completes after about 2 s. Results, on Linux 6.18.57, with pasta built from 8ba4132 plus your check and some logging: - A plain listener on the same host, reading TCP_INFO right after accept(): tcpi_min_rtt 0xffffffff, tcpi_rtt 0, tcpi_total_retrans 3. The same client without the drop: tcpi_min_rtt 5423 us. - pasta: your check fired, the client stayed out of the table, and transfers from it stayed at full speed. Without the check, it would have been added. - With timestamps enabled on the client, the same test gets a measured RTT from the timestamp echo, and nothing is skipped. We never saw 0, so skipping only ~0U looks right to me. 3. Patches Attached, against current master (7380393): 0001 tcp: Don't add peers to low RTT table before RTT is measured 0002 tcp: Log additions to low RTT table 0001 is your condition as you wrote it. 0002 logs only additions, with flow_dbg(): the skip itself happens on every tcp_prepare_flags() call until the first sample, which was 28 times for one connection in the test above, so logging it would be noisy. Each patch builds without warnings; I haven't run the test suite. I didn't do the expiry part. I'm happy to try it if you have a preference between tcp_rtt_dst_check() and tcp_update_seqack_wnd(). We're keeping the patched build running and will report if a remote peer still gets into the table. Thanks, Lynxes On Wed, Nov 4, 2026 at 2:53=E2=80=AFPM Stefano Brivio = wrote: > > Hi Lynxes, > > Thanks for the report, and sorry for the delay. Some comments inline: > > On Wed, 28 Oct 2026 14:15:59 +0100 > Lynxes Exe wrote: > > > Hi, > > > > A disclaimer before anything is owed: what you're about to read was > > written by Claude, and is the result of a bug fixing session that occur= red > > on my personal home infrastructure. It was not intended as a bug hunt. > > Since it seems like this issue has been unreported and I couldn't find > > anything similar to it, and since what Claude reported seems potentiall= y > > plausible, I'm putting it here. > > If AI assisted/generated bug reports are unwanted, I apologize. > > At least as far as I'm concerned, in term of bugs reports, whatever > makes sense and is usable is welcome. This report has a few dubious > aspects (see below) but it might still be valuable, I think. > > > Original report > > -------------------------- > > I think a peer address can get stuck in pasta's low-RTT destination > > table and then lose window clamping for good. > > This part wasn't clearly demonstrated. > > > That caused every new > > TCP connection from our LAN router's address to stall on RTOs until > > pasta was restarted. Details below. > > This looks plausible and somewhat demonstrated. > > > I haven't found an existing report on Bugzilla or this list. > > Correct, no known issues in this sense so far. > > > Version: pasta 2026_10_02.cba3570-3-g8ba4132 (the logic below is > > unchanged in current master) > > Setup: rootless Docker 29.6.1 via rootlesskit, --net=3Dpasta, > > --port-driver=3Dimplicit, --mtu=3D65520 (pasta --tcp-ports=3Da= uto > > --udp-ports=3Dauto --no-map-gw --ipv4-only ...) > > Kernel: 6.18.57 (Arch linux-lts), x86_64 > > > > What we think is happening > > -------------------------- > > We suspect the low-RTT destination table (low_rtt_dst[], > > tcp_rtt_dst_check() / tcp_rtt_dst_low()). Our LAN router's address, > > 10.0.0.1, ended up in it even though the router is several > > milliseconds away. > > Nothing clearly confirms the "ended up in it" part (yet). > > > [...] > > > > We could not read the table directly (no ptrace into pasta), so > > "10.0.0.1 is in the table" is inferred from this behaviour and the > > code path. > > ...I guess the problem here is training a language model about the > difference between "inferred" and "suspected". :) > > One could ptrace() as root by the way, but that wouldn't help either. > > Could you make sure about this with a print in tcp_rtt_dst_check()? If > that's not the case, you might need to further trace what's going on in > tcp_update_seqack_wnd() instead. > > Rebuilding and using a modified version of passt is quick (it just > depends on a C library): > > git clone git://passt.top/passt && cd passt > [edit as needed] > make && sudo make install # Or make install as root > > Both Podman and Docker / rootlesskit will pick up the local build under > /usr/local/bin. You can cleanly remove it with 'make uninstall' as root > once you're done. > > > Why we think 10.0.0.1 got into the table > > ---------------------------------------- > > A real RTT of 10 us or less to the router is impossible here > > (measured RTT 2-6 ms). Our suspicion comes from reading the kernel > > source; we have not caught it on a live socket: > > > > - tcp_rtt_dst_check() tests > > (int)tinfo->tcpi_min_rtt > LOW_RTT_THRESHOLD. > > - The kernel initialises rtt_min to ~0U, both in tcp_init_sock() > > (net/ipv4/tcp.c) and for accepted sockets in > > tcp_create_openreq_child() (tcp_minisocks.c). tcpi_min_rtt stays > > ~0U until the first valid RTT sample. > > - tcp_synack_rtt_meas() takes no sample when the SYN-ACK was > > retransmitted (rtt_us =3D -1 unless !req->num_retrans). The same > > applies on the active side when the SYN was retransmitted (Karn). > > - Cast to int, ~0U becomes -1, which passes the "<=3D 10 us" test. > > - pasta runs this check in tcp_prepare_flags() when it sends the SYN > > (inbound) or SYN-ACK (outbound) to the guest. That is right after > > the host-side handshake, before any data ACK could provide a > > sample. > > ...maybe, yes. > > > We measured exactly such handshake retransmissions on this > > Wi-Fi/NAT path: 6 of 1,800 fresh connections took ~1.05 s, i.e. one > > 1 s retry. With hundreds of inbound and outbound connections to > > 10.0.0.1 per day, one retried handshake would be enough to insert it > > permanently. > > > > The night the stalls became severe, the published container was also > > restarted about ten times while clients kept connecting, which made > > unusual handshakes more likely. We cannot tell exactly when the > > insertion happened. > > > > > > Suggested fixes > > --------------- > > 1. In tcp_rtt_dst_check(), treat tcpi_min_rtt =3D=3D ~0U (and 0) as > > "no sample" and skip the insertion. Compare as unsigned, or check > > tcpi_rtt / tcpi_rcv_rtt as well. > > I'm not sure if we actually risk hitting 0: strictly speaking that > would mean less than 1 =C2=B5s which looks unlikely (even for simple veth > pairs or local guests), but in practice there might be rounding errors > somewhere. > > Do we need to skip 0? From a quick glance of the kernel paths involved > I'd say we don't. > > Could you test this perhaps? Not build tested but I think you could > modify the initial early return condition to: > > if (!min_rtt_cap || > (int)tinfo->tcpi_min_rtt > LOW_RTT_THRESHOLD || > tinfo->tcpi_min_rtt =3D=3D ~0U /* not measured yet */) > return; > > > 2. Don't trust a single sample forever: give entries a lifetime, or > > evict an address when a later connection to it shows a min RTT > > above the threshold. > > Reasonable. I guess we could add a timestamp and check if the entry > expired (minutes?) where we update the RTT in > tcp_update_seqack_wnd()... or even in tcp_rtt_dst_check(). No strong > preference on my side, I didn't really think it through. > > > 3. Log (at debug level) when an address enters the table. It was > > invisible here; the only visible signs were retransmissions > > inside the namespace. > > Yeah, that would be good. I added this feature before we started > logging anything, I think. Feel free to send a patch for that. > > > Workaround: restarting pasta clears the table. > > > > Happy to test a patch or collect more data. > > Let me know if you can check those few things I suggested, thanks. > > -- > Stefano > --00000000000083930a0660168980 Content-Type: application/octet-stream; name="0001-tcp-Don-t-add-peers-to-low-RTT-table-before-RTT-is-m.patch" Content-Disposition: attachment; filename="0001-tcp-Don-t-add-peers-to-low-RTT-table-before-RTT-is-m.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mwdqp4fe0 RnJvbSAxNzIxMzhjMGIwMDVmZTkyZThmMDIyMGIzODkxMjY4NWI2M2E1ODgyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaWV0cm8gRGUgRG9tZW5pY28gPGx5bnhlcy5leGVAZ21haWwu Y29tPgpEYXRlOiBUaHUsIDEyIE5vdiAyMDI2IDE2OjU2OjQ0ICswMTAwClN1YmplY3Q6IFtQQVRD SCAxLzJdIHRjcDogRG9uJ3QgYWRkIHBlZXJzIHRvIGxvdyBSVFQgdGFibGUgYmVmb3JlIFJUVCBp cwogbWVhc3VyZWQKClRoZSBrZXJuZWwgaW5pdGlhbGlzZXMgdGhlIG1pbmltdW0gUlRUIG9mIGEg c29ja2V0IHRvIH4wVSAoc2VlCnRjcF9pbml0X3NvY2soKSBhbmQgdGNwX2NyZWF0ZV9vcGVucmVx X2NoaWxkKCkpLCBhbmQgdGNwaV9taW5fcnR0IGtlZXBzCnRoYXQgdmFsdWUgdW50aWwgdGhlIGZp cnN0IFJUVCBzYW1wbGUuCgpGb3IgYSBwYXNzaXZlbHkgb3BlbmVkIHNvY2tldCwgdGhlIGhhbmRz aGFrZSBnaXZlcyBubyBzYW1wbGUgaWYgdGhlClNZTi1BQ0sgd2FzIHJldHJhbnNtaXR0ZWQgKEth cm4ncyBhbGdvcml0aG0sIHNlZSB0Y3Bfc3luYWNrX3J0dF9tZWFzKCkpLAphbmQgdGhlIG9ubHkg ZmFsbGJhY2sgaXMgdGhlIHRpbWVzdGFtcCBlY2hvLCB3aGljaCBpc24ndCB0aGVyZSBpZiB0aGUK cGVlciBkaWRuJ3QgbmVnb3RpYXRlIFRDUCB0aW1lc3RhbXBzLiBXaW5kb3dzIGNsaWVudHMgZG9u J3QsIGJ5IGRlZmF1bHQuCgp0Y3BfcnR0X2RzdF9jaGVjaygpIGNhc3RzIHRjcGlfbWluX3J0dCB0 byBpbnQsIHNvIH4wVSBiZWNvbWVzIC0xLCB0aGUKcGVlciBwYXNzZXMgdGhlIHRocmVzaG9sZCBj aGVjaywgYW5kIGl0J3MgYWRkZWQgdG8gdGhlIGxvdyBSVFQgdGFibGUsCndoaWNoIGl0IG5ldmVy IGxlYXZlczogZnJvbSB0aGVuIG9uLCBldmVyeSBjb25uZWN0aW9uIHdpdGggdGhhdCBwZWVyCmFk dmVydGlzZXMgYW4gdW5jbGFtcGVkIHdpbmRvdyB0byB0aGUgZ3Vlc3QgYW5kIHN0YWxscyBvbgpy ZXRyYW5zbWlzc2lvbnMuCgpTa2lwIHRoZSBjaGVjayB3aGlsZSB0aGUgbWluaW11bSBSVFQgaGFz bid0IGJlZW4gbWVhc3VyZWQgeWV0LgoKUmVwcm9kdWNlZCBvbiBMaW51eCA2LjE4LjU3IGJ5IGRy b3BwaW5nIFNZTi1BQ0tzIGF0IGEgY2xpZW50IHdpdGgKbmV0LmlwdjQudGNwX3RpbWVzdGFtcHMg c2V0IHRvIDAsIGZvciB0d28gc2Vjb25kczogdGNwaV9taW5fcnR0IG9mIHRoZQphY2NlcHRlZCBz b2NrZXQgaXMgMHhmZmZmZmZmZiwgd2l0aCB0Y3BpX3RvdGFsX3JldHJhbnMgMywgYW5kIHBhc3Rh CndvdWxkIGhhdmUgYWRkZWQgdGhlIGNsaWVudCB0byB0aGUgdGFibGUuCgpMaW5rOiBodHRwczov L2FyY2hpdmVzLnBhc3N0LnRvcC9wYXNzdC1kZXYvQ0FKUE5KVXVVWVNrVzc3NlAwaEttd2VIbktP cVh0c1hxd200SFhQLStqb3JYclNmRkZnQG1haWwuZ21haWwuY29tLwpTdWdnZXN0ZWQtYnk6IFN0 ZWZhbm8gQnJpdmlvIDxzYnJpdmlvQHJlZGhhdC5jb20+CkNvLUF1dGhvcmVkLUJ5OiBDbGF1ZGUg T3B1cyA1LjUgPG5vcmVwbHlAYW50aHJvcGljLmNvbT4KU2lnbmVkLW9mZi1ieTogUGlldHJvIERl IERvbWVuaWNvIDxseW54ZXMuZXhlQGdtYWlsLmNvbT4KLS0tCiB0Y3AuYyB8IDMgKystCiAxIGZp bGUgY2hhbmdlZCwgMiBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEv dGNwLmMgYi90Y3AuYwppbmRleCA5NWY0ZjNlLi5kODhlYmQ0IDEwMDY0NAotLS0gYS90Y3AuYwor KysgYi90Y3AuYwpAQCAtNzU4LDcgKzc1OCw4IEBAIHN0YXRpYyB2b2lkIHRjcF9ydHRfZHN0X2No ZWNrKGNvbnN0IHN0cnVjdCB0Y3BfdGFwX2Nvbm4gKmNvbm4sCiAJaW50IGksIGhvbGUgPSAtMTsK IAogCWlmICghbWluX3J0dF9jYXAgfHwKLQkgICAgKGludCl0aW5mby0+dGNwaV9taW5fcnR0ID4g TE9XX1JUVF9USFJFU0hPTEQpCisJICAgIChpbnQpdGluZm8tPnRjcGlfbWluX3J0dCA+IExPV19S VFRfVEhSRVNIT0xEIHx8CisJICAgIHRpbmZvLT50Y3BpX21pbl9ydHQgPT0gfjBVIC8qIG5vdCBt ZWFzdXJlZCB5ZXQgKi8pCiAJCXJldHVybjsKIAogCWZvciAoaSA9IDA7IGkgPCBMT1dfUlRUX1RB QkxFX1NJWkU7IGkrKykgewotLSAKMi41Ni4wCgo= --00000000000083930a0660168980 Content-Type: application/octet-stream; name="0002-tcp-Log-additions-to-low-RTT-table.patch" Content-Disposition: attachment; filename="0002-tcp-Log-additions-to-low-RTT-table.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_mwdqp4fl1 RnJvbSAzZjcxYjhiYTEyNTVlODNjNTcwMmQ0NzY5MjMwZDUwMDdjODI4YTNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaWV0cm8gRGUgRG9tZW5pY28gPGx5bnhlcy5leGVAZ21haWwu Y29tPgpEYXRlOiBUaHUsIDEyIE5vdiAyMDI2IDE2OjU2OjQ0ICswMTAwClN1YmplY3Q6IFtQQVRD SCAyLzJdIHRjcDogTG9nIGFkZGl0aW9ucyB0byBsb3cgUlRUIHRhYmxlCgpFbnRyaWVzIGluIHRo ZSBsb3cgUlRUIHRhYmxlIG5ldmVyIGV4cGlyZSwgYW5kIGEgd3Jvbmcgb25lIG1ha2VzIGV2ZXJ5 CmNvbm5lY3Rpb24gd2l0aCB0aGF0IHBlZXIgc3RhbGwsIGJ1dCBub3RoaW5nIHNob3dzIHRoYXQg YSBwZWVyIHdhcwphZGRlZDogdGhlIG9ubHkgdmlzaWJsZSBzeW1wdG9tIGlzIHJldHJhbnNtaXNz aW9ucyBpbnNpZGUgdGhlCm5hbWVzcGFjZS4KClByaW50IGEgZGVidWcgbWVzc2FnZSB3aXRoIHRo ZSBhZGRyZXNzIGFuZCB0aGUgbWVhc3VyZWQgbWluaW11bSBSVFQKd2hlbmV2ZXIgYSBwZWVyIGlz IGFkZGVkLgoKQ28tQXV0aG9yZWQtQnk6IENsYXVkZSBPcHVzIDUuNSA8bm9yZXBseUBhbnRocm9w aWMuY29tPgpTaWduZWQtb2ZmLWJ5OiBQaWV0cm8gRGUgRG9tZW5pY28gPGx5bnhlcy5leGVAZ21h aWwuY29tPgotLS0KIHRjcC5jIHwgNSArKysrKwogMSBmaWxlIGNoYW5nZWQsIDUgaW5zZXJ0aW9u cygrKQoKZGlmZiAtLWdpdCBhL3RjcC5jIGIvdGNwLmMKaW5kZXggZDg4ZWJkNC4uNGFlZjg1NCAx MDA2NDQKLS0tIGEvdGNwLmMKKysrIGIvdGNwLmMKQEAgLTc1NSw2ICs3NTUsNyBAQCBzdGF0aWMg dm9pZCB0Y3BfcnR0X2RzdF9jaGVjayhjb25zdCBzdHJ1Y3QgdGNwX3RhcF9jb25uICpjb25uLAog CQkJICAgICAgY29uc3Qgc3RydWN0IHRjcF9pbmZvX2xpbnV4ICp0aW5mbykKIHsKIAljb25zdCBz dHJ1Y3QgZmxvd3NpZGUgKnRhcHNpZGUgPSBUQVBGTE9XKGNvbm4pOworCWNoYXIgYnVmW0lOQU5Z X0FERFJTVFJMRU5dOwogCWludCBpLCBob2xlID0gLTE7CiAKIAlpZiAoIW1pbl9ydHRfY2FwIHx8 CkBAIC03NzUsNiArNzc2LDEwIEBAIHN0YXRpYyB2b2lkIHRjcF9ydHRfZHN0X2NoZWNrKGNvbnN0 IHN0cnVjdCB0Y3BfdGFwX2Nvbm4gKmNvbm4sCiAJaWYgKGhvbGUgPT0gLTEpCiAJCXJldHVybjsK IAorCWZsb3dfZGJnKGNvbm4sICJBZGRpbmcgJXMgdG8gbG93IFJUVCB0YWJsZSwgbWluaW11bSBS VFQ6ICV1IHVzIiwKKwkJIGluYW55X250b3AoJnRhcHNpZGUtPm9hZGRyLCBidWYsIHNpemVvZihi dWYpKSwKKwkJIHRpbmZvLT50Y3BpX21pbl9ydHQpOworCiAJbG93X3J0dF9kc3RbaG9sZSsrXSA9 IHRhcHNpZGUtPm9hZGRyOwogCWlmIChob2xlID09IExPV19SVFRfVEFCTEVfU0laRSkKIAkJaG9s ZSA9IDA7Ci0tIAoyLjU2LjAKCg== --00000000000083930a0660168980--