Bug #202
closed
ipfw2 (was Re: Hard-coded M_* flags)
0%
Description
On Thu, Jun 08, 2006 at 12:41:51PM +0900, YONETANI Tomokazu wrote:
[hardcoded M_ flags]
M_SKIP_FIREWALL: defined as 0x4000, which conflicts with M_EXT_CLUSTER
/sys/net/ipfw/ip_fw2.c
Can I commit the following patch? This only helps ipv4-only environment,
but those who are in ipv6 network are not probably using ipfw2.
Without this, you get a kernel panic in m_free() as soon as ipfw2
sends out a packet generated by send_pkt().
Index: sys/net/ipfw/ip_fw2.c
===================================================================
RCS file: /home/source/dragonfly/cvs/src/sys/net/ipfw/ip_fw2.c,v
retrieving revision 1.17
diff u -p -r1.17 ip_fw2.c sys/net/ipfw/ip_fw2.c 17 Jun 2005 19:12:19 -0000 1.17
--
+++ sys/net/ipfw/ip_fw2.c 11 Jun 2006 09:55:23 -0000@ -82,7 +82,7 @
* a firewall-generated packet loops forever through the firewall.
*/
#ifndef M_SKIP_FIREWALL
-#define M_SKIP_FIREWALL 0x4000
+#define M_SKIP_FIREWALL M_PROTO5
#endif
/*Files
Updated by joerg almost 20 years ago
On Sun, Jun 11, 2006 at 07:16:53PM +0900, YONETANI Tomokazu wrote:
On Thu, Jun 08, 2006 at 12:41:51PM +0900, YONETANI Tomokazu wrote:
[hardcoded M_ flags]
M_SKIP_FIREWALL: defined as 0x4000, which conflicts with M_EXT_CLUSTER
/sys/net/ipfw/ip_fw2.cCan I commit the following patch? This only helps ipv4-only environment,
but those who are in ipv6 network are not probably using ipfw2.
Without this, you get a kernel panic in m_free() as soon as ipfw2
sends out a packet generated by send_pkt().
Can you work on a patch to put it into fw_flags instead? That would
resolve the problem in a better way IMO.
Joerg
Updated by qhwt+dfly almost 20 years ago
On Sun, Jun 11, 2006 at 02:32:11PM +0200, joerg@britannica.bec.de wrote:
Can you work on a patch to put it into fw_flags instead? That would
resolve the problem in a better way IMO.
Sure. I've replaced the kernel on my router with patched one.
Updated by dillon almost 20 years ago
:> Can you work on a patch to put it into fw_flags instead? That would
:> resolve the problem in a better way IMO.
:
:Sure. I've replaced the kernel on my router with patched one.
:
:--a8Wt8u1KmwUX3Y2C
:Content-Type: text/plain; charset=us-ascii
:Content-Disposition: attachment; filename="ipfw2.patch"
:
:Index: sys/sys/mbuf.h
:===================================================================
:RCS file: /home/source/dragonfly/cvs/src/sys/sys/mbuf.h,v
:...
That looks a lot cleaner. Commit any time!-Matt
Updated by joerg almost 20 years ago
On Mon, Jun 12, 2006 at 12:10:10AM +0900, YONETANI Tomokazu wrote:
On Sun, Jun 11, 2006 at 02:32:11PM +0200, joerg@britannica.bec.de wrote:
Can you work on a patch to put it into fw_flags instead? That would
resolve the problem in a better way IMO.Sure. I've replaced the kernel on my router with patched one.
One thing you should look at is whether or not the flag needs to be kept
when copying the mbuf. I don't know whether it is an issue for this
application, but it might need special handling.
Joerg
Updated by qhwt+dfly almost 20 years ago
On Sun, Jun 11, 2006 at 08:29:37PM +0200, joerg@britannica.bec.de wrote:
One thing you should look at is whether or not the flag needs to be kept
when copying the mbuf. I don't know whether it is an issue for this
application, but it might need special handling.
Good catch, it must be copied, but apparently the original ip_fw2.c code
we inherited from FreeBSD 4.8 didn't:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/mbuf.h?rev=1.128&content-type=text/x-cvsweb-markup
Since M_SKIP_FIREWALL is set only on pkthdr, and duplication of pkthdr
is performed by structure copy of m_pkthdr(which contains fw_flags),
the patch should retain the current behavior.