between protocol handlers.
ipsec socket pointers, ipsec decryption/auth information, tunnel
decapsulation information are in my mind - there can be several other usage.
at this moment, we use this for ipsec socket pointer passing. this will
avoid reuse of m->m_pkthdr.rcvif in ipsec code.
due to the change, MHLEN will be decreased by sizeof(void *) - for example,
for i386, MHLEN was 100 bytes, but is now 96 bytes.
we may want to increase MSIZE from 128 to 256 for some of our architectures.
take caution if you use it for keeping some data item for long period
of time - use extra caution on M_PREPEND() or m_adj(), as they may result
in loss of m->m_pkthdr.aux pointer (and mbuf leak).
this will bump kernel version.
(as discussed in tech-net, tested in kame tree)
pfil information, instead, struct protosw now contains a structure
which caontains list heads, etc. The per-protosw pfil struct is passed
to pfil_hook_get(), along with an in/out flag to get the head of the
relevant filter list. This has been done for only IPv4 and IPv6, at
present, with these patches only enabling filtering for IPPROTO_IP and
IPPROTO_IPV6, although it is possible to have tcp/udp, etc, dedicated
filters now also. The ipfilter code has been updated to only filter
IPv4 packets - next major release of ipfilter is required for ipv6.
back into the packet. (ip_output() clears it since ipsec reuses that
packet field in the output path. by putting it back, we're going to
pretend we're back on the input path now).
the member is used to pass struct socket to ip{,6}_output for ipsec decisions.
(i agree it is kind of ugly. we need to modify struct mbuf if we are
to do better - which seems to me a bit too much)
operation, since:
- in ipl_enable(), "fr_savep = fr_checkp" is not conditionalized
in the same way (not at all), and
- without this change, it was not possible to enable, disable,
and reenable ipfilter.
silly differences between the NetBSD copy of the code and the
vendor branch, keeping only those which are necessary. Of those
differences that currently exist, several "portability to NetBSD"
issues, which will be fed back to the ipfilter author.
- Fix a really obvious error: ipl_enable() disappeared, but the guts of
the function were scrunched into the "no-op" BSD pseudo-device attach
routine. Would not compile, because of non-void return from a void
function. Fixed by reincarnating ipl_enable(), and reimplementing
the no-op pseudo-device attach.
- #ifdef as appropriate to remove unused variable warnings.
- Call ipl_enable() in iplinit(), rather than the no-op ipfilterattach().
Description:
- A BSD pseudo-device initialization routine is declared as
void <pseudo-device name>attach __P((int count));
in ioconf.c by config(8). main() calls these functions
from a table.
- IP Filter has functions iplattach() and ipldetach() (or,
in the NetBSD case, were erroneously renamed ipfilterattach()
and ipfilterdetach()). These functions are used to establish
and disestablish the IP Filter "filter rule check" hook in
the IP input/output stream. They are declared:
int iplattach __P((void));
int ipldetach __P((void));
..and are expected to return a value by iplioctl().
- When main() calls (by sheer coincidence!) iplattach(),
the filter hook is established, and the IP Filter machinery
labeled as "initialized". This causes all packets, whether or
not the user intents to use filter rules, to be passed to
the filter rule checker if "ipfilter" is configured into the
kernel.
- As a result of the above, a kludge existed to default to
passing all packets (I can only assume that when this was
originally committed, the symptom of the bug was noticed by
the integrator, but the bug not actually found/fixed).
- In iplioctl(), if the SIOCFRENB ioctl is issued with an
argument of "enable" (i.e. user executed "ipf -E"), iplattach()
will notice that the machinery is already initialized and
return EBUSY.
Fix:
- Rename iplattach()/ipldetach() to ipl_enable() and ipl_disable().
- Create a pseudo-device entry stub named ipfilterattach()
(NetBSD case) or iplattach() (all other). This is a noop; none
of the machinery should be initialized until the caller expicitly
enables the filter with ipf -E. Add a comment to note that.
XXX !!! XXX !!!
I noticed a few semi-serious bugs while doing this merge, one of which
has existed for a fairly long time. Some of them are addressed in this
commit (because they caused the kernel to not compile), and are annoted
by "XXX" and "--thorpej". The other one will be addressed shortly in
a future commit, and, as far as I can tell, affects all operating systems
which IP Filter supports.
mycroft