Re: Accurate ECN support in tcpdump/libpcap

[Denis Ovsienko <denis () ovsienko info>]

On Fri, 6 Feb 2026 16:40:35 +0000
Denis Ovsienko <denis () ovsienko info> wrote:

> This is a work in progress.
>
> I tried modelling the arithmetic "tcphf" after tcp[] and realised that
> tcp[] as it is now is not a good model because it has always been
> IPv4-only (for the avoidance of doubt, the current tcp[tcpflags] is a
> case of the same problem).  Then I prototyped a draft of IPv6 support
> in tcp[] -- it works in principle, but would need to be done right
> before the arithmetic "tcphf" could reproduce the method.  This does
> not look a good fit, but before deciding on the final syntax for TCP
> flags it seems worthwhile to research this direction a little bit
> more.

After two weeks of research the lack of the originally expected results
and the presence of many originally unexpected results lead me to
conclude that a *reliable* IPv4+IPv6 implementation of the "tcphf"
arithmetic expression is not practicable in near future and might not
be doable even in a few more man-months of development work due to
technical debt.  Therefore "tcp flag" is going to be the solution to the
TCP flag matching problem.

As it turned out, IPv4+IPv6 "tcphf" is one of the problems that are easy
to state and difficult to solve.  Its difficulty comes from the same
root causes as for the long-overdue IPv4+IPv6 tcp[], udp[], pim[],
etc., so even though there is no practical reason to pursue "tcphf" any
more, there would be sense in resuming this research later to get
closer to IPv4+IPv6 transport protocol data accessors.

Internally the code base that implements packet data accessors is
roughly a super-set of the code base that implements primitives, but
the former has not been substantially tested or refactored.  When an
IPv4+IPv6 accessor starts producing a bit more sophisticated filter
program fragments, those tend to expose technical debt of varying
complexity in the arithmetic expressions code base and in the
optimiser, which is yet another dimension of complexity in demand of
better testing.

Nevertheless, this is a useful source of material for longer-term
development, and during this research I have been committing small
complete solutions for small problems, but there are other problems
that I understand, but have not completely solved yet, and other
problems that I can reproduce, but cannot even define yet.  Hopefully
this work will continue slowly in the background and will eliminate
some more technical debt.

-- 
    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