Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Nov 2024 17:21:02 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 282673] ipfw tags are lost while transit via if_epair
Message-ID:  <bug-282673-227-pZ3xMTmIQc@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-282673-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-282673-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D282673

--- Comment #3 from bugs.freebsd.org@mx.zzux.com ---
(In reply to Andrey V. Elsukov from comment #1)

Thanks for the link to the explanation of this,
because there is no word about mbuf_tag stripping in 'man if_epair'.


Though 'man ipfw' says

Tags are "sticky", meaning once a tag is applied to a packet by a
matching rule it exists until explicit removal.  Tags are kept
with the packet everywhere within the kernel, but are lost when
the packet leaves the kernel.
...
Note: since tags are kept with the packet everywhere in
kernelspace, they can be set and unset anywhere in the kernel
network subsystem (using the mbuf_tags(9) facility), not only by
means of the ipfw(4) tag and untag keywords



I think that silent unconditional (eg. via sysctl) behaviour is contrary to=
 the
ipfw documentation.

And by the way, a packet tagged by the host may be also useful inside jail =
and
vice versa.
But I need simply fully functional loopback allowing any action at any pass,
not first and only.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-282673-227-pZ3xMTmIQc>