[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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?
Main Index |
Thread Index |