Date: Thu, 15 Aug 2002 00:07:21 -0700 From: Luigi Rizzo <rizzo@icir.org> To: ipfw@freebsd.org Subject: RFC: new mbuf flag bit needed Message-ID: <20020815000720.B24495@iguana.icir.org>
next in thread | raw e-mail | index | archive | help
[Bcc to -arch in case they have some comments]
Hi,
we have the following problem: both ipfw and ipfw2 can sometimes
generate new packets (e.g. in response to an "unreach" or "reset"
action, or simply keepalives) which in turn get reinjected in the
stack and the firewall itself, starting from the beginning. This
has the potential of causing loops, unless we break them in some
way.
ipfw does this using two specific hacks:
+ ICMP packets will not generate a response even on "unreach" rules;
+ TCP packets with the RST bit set will not generate a response
on "unreach" rules)
ipfw2 has a harder time because keepalives have nothing very
distinguishable in them (except sequence numbers which refer to old
data; but to detect them requests a lookup of the stateful entry).
So my proposal is to use a different method, and use one of the
m_pkthdr.flags bits as a marker that the packet should bypass the
firewall. I can restrict the change to just ip_fw2.c so no other
parts of the system will need to be modified, except sys/mbuf.h for
the definition of the new bit if we want to give it a meaningful name.
sys/mbuf.h contains definitions for M_PROTO1..M_PROTO5; the first
one is used to mark that rcvif is valid on vlan packets (btw should
we rename it to indicate its real use ?).
The others are used in the KAME code in netinet6/ -- i guess that
leaves me with using one of the two unused bits, 0x4000 and 0x8000 ?
cheers
luigi
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020815000720.B24495>