Re: Accurate ECN support in tcpdump/libpcap

["Scheffenegger, Richard via tcpdump-workers" <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com>
>
> Date: Thu, 13 Nov 2025 15:43:46 +0000
>
>
> Well, as long as there is a reasonably easy (new) way to access the full 9-bit TCP header flags field interactively, 
> and it's documented properly, I don't care that much how to attain this.
>
> Personally, I like the approach of a new predefined variable which can also be used as shorthand for the old 
> tcp[tcpflags], tcphf, and used in the very much the same syntactic fashion as before, the most.
>
> The other approaches suggested further down don't seem to be quite as intuitive.
>
> And retaining tcp[tcpflags] to allow access to the long-term tcp header flags, while allowing tcphf to access to all 
> IANA defined flags (9 currently, maybe more in the future) sounds like the best option to me.
>
>
> Richard Scheffenegger
>
>
> -----Original Message-----
> From: Denis Ovsienko <denis () ovsienko info> 
> Sent: Donnerstag, 13. November 2025 15:35
> To: Scheffenegger, Richard <Richard.Scheffenegger () netapp com>
> Cc: tcpdump-workers () lists tcpdump org
> Subject: [tcpdump-workers] Re: Accurate ECN support in tcpdump/libpcap
>
> EXTERNAL EMAIL - USE CAUTION when clicking links or attachments
>
>
>
>
> On Thu, 13 Nov 2025 08:17:00 +0000
> "Scheffenegger, Richard" <Richard.Scheffenegger () netapp com> wrote:
>
> > Hi Denis,
> >
> > Before discussing the various alternate ways - what exactly are you 
> > referring to with "breaking compatibility" when tcp[tcpflags] maps to
> > 12:2 instead of 13:1?
> >
> > Is there an expectation that people use "tcpflags" as a "shorthand"
> > for 13:1? Or that is being used in contexts outside of the tcp header 
> > flags?
> >
> > Because within the context of the tcp header, the flags were always 
> > defined to be 12 bits wide, since 1981, or 2003 at the latest.
>
> Hello Richard.
>
> Please note that as far as the specifications define it, they never were.
>
> RFC 793 (published in September 1981) Section 3.1 says:
>
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Data |           |U|A|P|R|S|F|                               |
>    | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
>    |       |           |G|K|H|T|N|N|                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
>   Reserved:  6 bits
>     Reserved for future use.  Must be zero.
>
>
> RFC 3168 (published in September 2001) Section 23.2 says:
>
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>    |               |               | C | E | U | A | P | R | S | F |
>    | Header Length |    Reserved   | W | C | R | C | S | S | Y | I |
>    |               |               | R | E | G | K | H | T | N | N |
>    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>
>
> RFC 9293 (published in August 2022) Section 3.1 says:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Data |       |C|E|U|A|P|R|S|F|                               |
>    | Offset| Rsrvd |W|C|R|C|S|S|Y|I|            Window             |
>    |       |       |R|E|G|K|H|T|N|N|                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> [...]
> Reserved (Rsrvd):    4 bits
> A set of control bits reserved for future use. Must be zero in
>     generated segments and must be ignored in received segments if the
>     corresponding future features are not implemented by the sending or
>     receiving host.
>
>
> In all diagrams you can see the reserved space is a unstructured block rather than a bitmap pre-allocated into 
> individual 1-bit flags with names such as ReservedFlag-16, ReservedFlag-15, ReservedFlag-14 etc.
>
> Arguably, RFC 9293 says "a set of control bits", so perhaps the guess/impression/idea/figure of speech (but not the 
> formally specified norm) is that the rest of the available bit space will be allocated to more flags later.  But RFC 
> 793 conveyed no such guess, and for 20 years until ECE and CWR were allocated it was not obvious whether even the rest 
> of the byte 13 would become more flags, let alone byte 12.
>
> This way, when the named offset "tcpflags" meaning 13 (with the implied load size of 1 byte) was added to libpcap in 
> what is now known as git commit 4ed1792 (February 2001) and became generally available in release 0.7.1 (October 2001), 
> the equivalence of "tcp[13:1]" and "tcp[tcpflags]" was a good fit for 20 years of Internet development before that, and 
> remained a good fit for more than 20 years afterwards, so it seems almost certain "tcp[tcpflags]" has been baked into 
> some non-interactive software that uses libpcap.
>
> It is conceivable that some of such software trusts "tcp[tcpflags]" to evaluate to an 8-bit value, and uses it as a 
> part of a more complex arithmetic expression that would not handle an overflow correctly.  Or, for example, the 
> software captures packets that match "tcp[tcpflags] != 0" and runs them through a switch block that assumes that at 
> that point at least one of the 8 TCP flags it knows is set, but this would no longer be the case if tcp-ae matched, but 
> none of the other flags did.
> Or, for example, the software prints to a string buffer an exact 8-bit value for the specific combination of flags it 
> needs to match, but then one day for no apparent reason "tcp[tcpflags] == 0x02" no longer matches all packets with only 
> SYN set in byte 13.
>
> Or this is not a software, but a firewall rule, because some firewalls can take, via BPF, libpcap filter expressions to 
> match packets.  And/or the matching is offloaded to some sort of network hardware, where problems could cascade further.
>
> So let's be wise to choose a solution space that does not make the problem space larger.
>
> > But back to the issue - what compatibility issue is expected to arise?  
> > As user, who infrequently uses tcpdump with all the functionalities - 
> > I'd expect there to be only one way to access *all* tcp flags by name; 
> > and if i need something special, it'll be possible to convert scripts 
> > that somehow (I don't know how, my imagination fails me) require 
> > tcp[tcpflags] to return only a 8 bit value, to be redefined tcp[13:1] 
> > in those scripts as a one-off change after updating tcpdump which has 
> > proper tcp header flags support...
>
> Interactive use with a relatively short feedback loop is one important use case, but not the only.
>
> --
>     Denis Ovsienko
> _______________________________________________
> tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org To unsubscribe send an email to 
> tcpdump-workers-leave () lists tcpdump org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s