Hi, I'm not sure if this is a problem in ipf or with the NetBSD
integration - but since the CVS log shows a lot of merging/pulling-up of
the ipfilter code to NetBSD-1.5-release, I'll ask on this list first...

I'm using ipfilter 3.4.9 on NetBSD-1.5.1_BETA/i386.  I have a "block in
all with short" filter rule and was noticing a bunch of ICMP packets were
being blocked by that rule.  For example, the mcast router solicitation
packets (icmp type 10 - 8 bytes of IP payload) that are generated by
Windows 98 at bootup get blocked.

The relevant code appears to be fil.c (rev 1.36.2.3) around line 282.  It
calculates "minicmpsz" for a few of the common ICMP packet types, but
defailts to "sizeof(struct icmp)", which is 28, for others such as the
router solicitation type.  Should there just be an additional calculation
for minicmpsz for type 10 icmp messages?  Isn't there a more gracefull way
of doing this instead of having to hard-code the min size for specific
icmp message types?  Wouldn't it be better to default to ICMP_MINSIZE
(8) instead of the maximum size so that some bogus ICMP messages could get
through instead of some valid ICMP messages being blocked?

Also, the total packet length field in the ipmon log appears to be
bogus.  It says 7168 but a packet capture clearly shows the IP packet
having total length 28 (header + 8 byte ICMP message):
14/04/2001 21:46:41.489849 2x epic0 @0:1 b 192.168.149.16 -> 224.0.0.2 PR icmp len 20 7168 icmp 10/0 IN

Is this a NetBSD bug, or should I be directing this message to the
ipfilter mailing list?

Thanks,
	Rick