Re: kern/47749

[Darren Reed <darrenr%netbsd.org@localhost>]

The following reply was made to PR kern/47749; it has been noted by GNATS.

From: Darren Reed <darrenr%netbsd.org@localhost>
To: =?ISO-8859-1?Q?Sergio_L=F3pez?= <slp%sinrega.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, martin%duskware.de@localhost
Subject: Re: kern/47749
Date: Thu, 29 Aug 2013 23:06:18 +1000

 Sergio López wrote:
 > Apparently, IPF gets confused when trying to keep track of an
 > ICMP_ECHOREPLY packet.
 >
 > The first time such a packet is found, fr_addstate from fr_scanlist
 > (fil.c:2146) fails, and if no other rule matches, it returns the
 > default "pass" value (without FR_KEEPSTATE flag), but leaves
 > fin->fin_fr pointing to the rule (with FR_KEEPSTATE), and this
 > structure is saved into frcache. So this first packet is considered to
 > haven't match any rule, and unless IPF is in block by default, it
 > passes the filter.
 >
 > But, when a second packet arrives, its "pass" value is taken from
 > frcache, which contains the flags from the rule, including
 > FR_KEEPSTATE. In consequence, fr_addstate fails again when called from
 > fr_check (fil.c:2586), and this time the packet is marked as blocked.
 >
 > From an user's perspective, this can be avoided by not using "keep
 > state" for icmp rules, or by doing so in both the input and output
 > filters, as this will make all ICMP_ECHOREPLY packets to be matched by
 > a previous ICMP_ECHO.
 >   
 
 Can you give me an example that uses ipftest to show this behaviour?
 
 Darren