Re: git: 637c0bace261 - main - sysutils/pftop: Fix build on 14.0-CURRENT
- In reply to: Michael Gmelin : "Re: git: 637c0bace261 - main - sysutils/pftop: Fix build on 14.0-CURRENT"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 11 Jun 2023 12:40:53 UTC
On Sun, 11 Jun 2023 12:12:44 +0200 Michael Gmelin <grembo@freebsd.org> wrote: > > On 11. Jun 2023, at 12:00, Herbert J. Skuhra <herbert@gojira.at> > > wrote: On Sun, 11 Jun 2023 11:25:45 +0200, Michael Gmelin wrote: > >> > >> > >> > >>> On 11. Jun 2023, at 10:27, Herbert J. Skuhra <herbert@gojira.at> > >>> wrote: On Sat, 10 Jun 2023 12:06:09 +0200, > >>> Michael Gmelin <grembo@FreeBSD.org> wrote: > >>>> The branch main has been updated by grembo: > >>>> URL: > >>>> https://cgit.FreeBSD.org/ports/commit/?id=637c0bace26138529a36232e948549ad59342ba9 > >>>> commit 637c0bace26138529a36232e948549ad59342ba9 Author: > >>>> Michael Gmelin <grembo@FreeBSD.org> AuthorDate: 2023-06-10 > >>>> 10:03:39 +0000 Commit: Michael Gmelin <grembo@FreeBSD.org> > >>>> CommitDate: 2023-06-10 10:03:39 +0000 > >>>> sysutils/pftop: Fix build on 14.0-CURRENT > >>>> --- > >>>> sysutils/pftop/Makefile | 10 ++++++++-- > >>>> sysutils/pftop/files/extra-patch-config.h | 6 +++++- > >>>> 2 files changed, 13 insertions(+), 3 deletions(-) > >>>> diff --git a/sysutils/pftop/Makefile b/sysutils/pftop/Makefile > >>>> index f3c6d879f637..cba2ecd65aeb 100644 > >>>> --- a/sysutils/pftop/Makefile > >>>> +++ b/sysutils/pftop/Makefile > >>>> @@ -1,6 +1,6 @@ > >>>> PORTNAME= pftop > >>>> PORTVERSION= 0.8 > >>>> -PORTREVISION= 2 > >>>> +PORTREVISION= 3 > >>>> CATEGORIES= sysutils net > >>>> MAINTAINER= grembo@FreeBSD.org > >>>> @@ -22,7 +22,13 @@ EXTRA_PATCHES+= > >>>> ${FILESDIR}/extra-patch-bpf_dump.c \ > >>>> ${FILESDIR}/extra-patch-sf-gencode.h MAKE_ARGS= > >>>> LOCALBASE="${PREFIX}" \ > >>>> - OSLEVEL=45 > >>>> + > >>>> +.if ${OPSYS} == FreeBSD && ${OSVERSION} >= 1400090 > >>>> +MAKE_ARGS+= OSLEVEL=46 > >>>> +.else > >>>> +MAKE_ARGS+= OSLEVEL=45 > >>>> +.endif > >>>> + > >>>> CFLAGS+= -DHAVE_SNPRINTF=1 -DHAVE_VSNPRINTF=1 \ > >>>> -DHAVE_FINE_GRAINED_LOCKING=1 > >>>> diff --git a/sysutils/pftop/files/extra-patch-config.h > >>>> b/sysutils/pftop/files/extra-patch-config.h index > >>>> 6d2873c42ab1..d24f88179718 100644 --- > >>>> a/sysutils/pftop/files/extra-patch-config.h +++ > >>>> b/sysutils/pftop/files/extra-patch-config.h @@ -1,7 +1,7 @@ > >>>> $OpenBSD: patch-config_h,v 1.4 2008/12/20 04:36:11 canacar Exp $ > >>>> --- config.h.orig Tue Nov 6 22:34:18 2007 > >>>> +++ config.h Fri Dec 19 20:28:01 2008 > >>>> -@@ -74,11 +74,20 @@ > >>>> +@@ -74,11 +74,24 @@ > >>>> #define HAVE_PFSYNC_STATE > >>>> #endif > >>>> @@ -11,7 +11,11 @@ $OpenBSD: patch-config_h,v 1.4 2008/12/20 > >>>> 04:36:11 canacar Exp $ +#endif > >>>> + > >>>> #ifdef HAVE_PFSYNC_STATE > >>>> ++#if OS_LEVEL > 45 > >>>> ++typedef struct pfsync_state_1400 pf_state_t; > >>> Are you sure that this is correct? > >>> If I replace pfsync_state_1400 with pfsync_state_1301 the port > >>> builds and the output looks sane. > >> > >> Hi, thanks for reporting, could you please add some details (like, > >> how the output differs)? > > > > With your change: > > > > sctp Out (null)[13715] (null)[0] > > 0:255 0 * * * 237 In (null)[0] > > (null)[0] NO_TRAFFIC:NO_TRAFFIC 0 0 > > * * ip In (null)[0] (null)[0] > > NO_TRAFFIC:NO_TRAFFIC 0 9324h * * ip In > > (null)[7185] (null)[512] NO_TRAFFIC:NO_TRAFFIC > > 0 53 * 2048G ip In (null)[4097] > > (null)[49408] NO_TRAFFIC:NO_TRAFFIC 0 0 0 > > 1 ip In (null)[9732] (null)[4992] > > 9:0 0 0 42 73728M cpnx In (null)[0] > > (null)[0] 255:0 0 * > > * * ipenca In (null)[0] (null)[0] > > NO_TRAFFIC:NO_TRAFFIC 0 0 * * ip In > > (null)[0] (null)[0] 0:9 > > * * * * > > > > Garbage? > > > > With attached patch I see ipv[46] addresses and port numbers again. > > :-) > > > > I am running main-n263493-4e8d558c9d1c. > > > > The question is if pftop shouldn’t use pfsync_state_1400, or if there > is a kernel problem with that struct. I’ll look into it. > > Thanks Hi Herbert, Apparently what happened is that I tested using 1301, which worked, then changed to 1400, which also seemed to work and committed the change. Apparently I tested the wrong binary, as rebuilding and testing I see the same results as you do. Therefore I'll switch to using 1301, thanks again for reporting. Best Michael -- Michael Gmelin