[tcpdump-workers] Re: bringing in distro and embedded patches

[Denis Ovsienko]

On Sun, 22 Jun 2025 15:51:56 -0400
Michael Richardson  wrote:

> The current set of patches that OpenWRT applies to tcpdump are at:
> 
> > The current paches are here:
> > 
> https://github.com/openwrt/openwrt/tree/master/package/libs/libpcap/patches
> >  
> 
> There are no doubt Fedora/RPM, and Debian/DPKG patches too.

Yes, and FreeBSD ports, and pkgsrc... and so on.  Some patches have been
merged in recent years, some more could be merged, some should not be
merged.  Also there are forks of tcpdump and libpcap in the base system
part of the major BSDs, some of these have diverged very substantially.

Guy has been importing various useful bits in this department, but I
suspect many more days of work would be required to merge everything
that can and should be merged.

> I for one, would be very happy to see everything upstreamed to our
> repos. Even if we -DDEBIAN, or -DEMBED or -DSMALL.
> 
> This would be a great new contributor effort.

That's a sound point, and this is not the first time it emerges (indeed
tcpdump 5.0 has been earlier agreed a milestone before this change).
This is what I remember to be the closest thing to consensus for
tcpdump:

* A very small number of dissectors should be always-on to provide a
  baseline for OpenWrt and other low-resource environments. (e.g.
  Ethernet, IPv4, IPv6, ICMP, ICMPv6, UDP and TCP).  In other words,
  this would a build with nothing left to remove, and the expectation
  would be that both the library dependencies, the disk and the memory
  footprints stay minimal.

* Dissectors for protocols that are obviously out of date (subject to
  opinions and interpretations) should be made default-off to reduce the
  default attack surface and to preserve the material for
  research/hobby/scientific/educational purposes. (e.g. DECnet,
  AppleTalk, Frame Relay, ATM).  Individual builds would be able to
  enable this group as and if required.

* All other dissectors should be default-on.

After this is implemented as three types of build, there may be some
sense in making the latter two options more granular and/or arranging
the source such that assigning a specific dissector to a specific group
would be a matter of one #define.  But this may be over-engineering.

-- 
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[tcpdump-workers] Re: bringing in distro and embedded patches

[Guy Harris]

On Jun 23, 2025, at 6:32 AM, Denis Ovsienko  wrote:

> Also there are forks of tcpdump and libpcap in the base system
> part of the major BSDs, some of these have diverged very substantially.

FreeBSD's is a fork that appear to get synced with each of our releases, so it 
hasn't diverged much. It's in contrib/tcpdump, as with other "contributed" 
software.

NetBSD's is imported (into CVS) from our releases by a script. I'm not sure 
what changes they've made and where they are kept in the source tree. It's in 
external/bsd/tcpdump.

OpenBSD's was forked a while ago and they're maintaining it themselves; I think 
they've picked up some changes from us.

DragonFly BSD is similar to FreeBSD's (not surprisingly, as DragonFly BSD was 
originally a fork of FreeBSD). It's also in contrib/tcpdump.
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s