NetBSD Problem Report #59488

From kre@munnari.OZ.AU  Sat Jun 28 12:41:03 2025
Return-Path: <kre@munnari.OZ.AU>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 1E16B1A923A
	for <gnats-bugs@gnats.NetBSD.org>; Sat, 28 Jun 2025 12:41:03 +0000 (UTC)
Message-Id: <202506281240.55SCeulV003817@jacaranda.noi.kre.to>
Date: Sat, 28 Jun 2025 19:40:56 +0700 (+07)
From: kre@munnari.OZ.AU
To: gnats-bugs@NetBSD.org
Subject: net/tcptrace does not build (amd64 HEAD)
X-Send-Pr-Version: 3.95

>Number:         59488
>Category:       pkg
>Synopsis:       net/tcptrace does not build (amd64 HEAD)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 28 12:45:00 +0000 2025
>Last-Modified:  Tue Nov 11 13:00:01 +0000 2025
>Originator:     Robert Elz
>Release:        NetBSD 10.99.14
>Organization:
>Environment:
System: NetBSD jacaranda.noi.kre.to 10.99.14 NetBSD 10.99.14 (JACARANDA:1.1-20250525) #200: Sun May 25 10:04:09 +07 2025 kre@jacaranda.noi.kre.to:/usr/obj/testing/kernels/amd64/JACARANDA amd64
Architecture: x86_64
Machine: amd64
>Description:
	The function pread_tcpdump() in tcptrace/tcpdump.c attempts to call
	pcap_offline_read() to read a packet from a saved pcap file.

	The function in libpcap is actually called pcapint_offline_read()
	(at least it is in libpcap 1.10.5 -- which is what is in both pkgsrc
	net/libpcap, and HEAD).   Needless to say, calling a function which
	does not exist in the library results in an undefined symbol linker
	error.

>How-To-Repeat:
	cd ..../pkgsrc/net/tcptrace
	make package-install

>Fix:
	In pkgsrc/net/tcptrace/patches/patch-tcpdump.c add changes to alter
	pcap_offline_read() into pcapint_offline_read() which is the function
	(with the same obviously desired semantics and signature) instead.

	Note that there is both an extern decl for pcap_offline_read() and
	exactly one call of that function (in pread_tcpdump()).  Whether the
	extern declaration remains required or not, I did not test, I did
	verify that it builds with just this one change (applied in both
	sites pcap_offline_read is mentioned).

	Note though that I edited the unpacked source to make it, rather
	than altering the patch.

>Audit-Trail:
From: Guy Harris <gharris@sonic.net>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: pkg/59488
Date: Mon, 10 Nov 2025 12:31:34 -0800

 Is there some reason why tcptrace isn't just using pcap_loop() or =
 pcap_dispatch() or some libpcap API, rather than an internal routine =
 that tcpdump.org does *not* guarantee will continue to exist and does =
 *not* guarantee that it won't have its name changed?

 (The name was changed because somebody complained - in a message to me =
 on LinkedIn - about find_dev() being exported from the static libpcap; =
 to fix that, we renamed *all* internal routines with a pcapint_ prefix =
 to try to avoid conflicts.)=

From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: Guy Harris <gharris@sonic.net>
Subject: Re: pkg/59488
Date: Tue, 11 Nov 2025 19:55:29 +0700

     Date:        Mon, 10 Nov 2025 20:35:02 +0000 (UTC)
     From:        "Guy Harris via gnats" <gnats-admin@NetBSD.org>
     Message-ID:  <20251110203502.0BD771A923A@mollari.NetBSD.org>

   |  Is there some reason why tcptrace isn't just using pcap_loop() or
   |  pcap_dispatch() or some libpcap API,

 No idea, I was simply trying to build it (via pkgsrc) on NetBSD.
 tcptrace comes from:

 	https://github.com/blitz/tcptrace

 NetBSD pkgsrc has (builds) version 6.6.7 - I have no idea whether or
 not that's the most recent one.   It probably is, as it appears (that
 at least on github) tcptrace has been frozen (readonly) for more than
 5 years now, so I'd assume nothing is going to change in its code any
 more.

 All I did was find the smallest change I could apply to the sources
 as they are which would make it build.

   |  (The name was changed because somebody complained

 That's fine, no complaints about libpcap, nor what stuff is called.

 kre

Home	PR Database Search