netdev - Re: tcpdump and Big TCP

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]

Date: Mon, 2 Oct 2023 18:25:19 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: David Ahern <dsahern@...nel.org>
Cc: Xin Long <lucien.xin@...il.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: tcpdump and Big TCP

On Mon, Oct 2, 2023 at 6:20 PM David Ahern <dsahern@...nel.org> wrote:
>
> Eric:
>
> Looking at the tcpdump source code, it has a GUESS_TSO define that can
> be enabled to dump IPv4 packets with tot_len = 0:
>
>         if (len < hlen) {
> #ifdef GUESS_TSO
>             if (len) {
>                 ND_PRINT("bad-len %u", len);
>                 return;
>             }
>             else {
>                 /* we guess that it is a TSO send */
>                 len = length;
>             }
> #else
>             ND_PRINT("bad-len %u", len);
>             return;
> #endif /* GUESS_TSO */
>         }
>
>
> The IPv6 version has a similar check but no compile change needed:
>         /*
>          * RFC 1883 says:
>          *
>          * The Payload Length field in the IPv6 header must be set to zero
>          * in every packet that carries the Jumbo Payload option.  If a
>          * packet is received with a valid Jumbo Payload option present and
>          * a non-zero IPv6 Payload Length field, an ICMP Parameter Problem
>          * message, Code 0, should be sent to the packet's source, pointing
>          * to the Option Type field of the Jumbo Payload option.
>          *
>          * Later versions of the IPv6 spec don't discuss the Jumbo Payload
>          * option.
>          *
>          * If the payload length is 0, we temporarily just set the total
>          * length to the remaining data in the packet (which, for Ethernet,
>          * could include frame padding, but if it's a Jumbo Payload frame,
>          * it shouldn't even be sendable over Ethernet, so we don't worry
>          * about that), so we can process the extension headers in order
>          * to *find* a Jumbo Payload hop-by-hop option and, when we've
>          * processed all the extension headers, check whether we found
>          * a Jumbo Payload option, and fail if we haven't.
>          */
>         if (payload_len != 0) {
>                 len = payload_len + sizeof(struct ip6_hdr);
>                 if (length < len)
>                         ND_PRINT("truncated-ip6 - %u bytes missing!",
>                                 len - length);
>         } else
>                 len = length + sizeof(struct ip6_hdr);
>
>
> Maybe I am missing something, but it appears that no code change to
> tcpdump is needed for Linux Big TCP packets other than enabling that
> macro when building. I did that in a local build and the large packets
> were dumped just fine.
>

My point is that tcpdump should not guess, but look at TP_STATUS_GSO_TCP
(and TP_STATUS_CSUM_VALID would also be nice)

Otherwise, why add TP_STATUS_GSO_TCP in the first place ?