On Sun, 22 Jun 2025 15:51:56 -0400 Michael Richardson <m...@sandelman.ca> 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