Re: Dropped inbound packets from stateful allow rule
Darren Reed <[email protected]> Tue, 13 Apr 2010 19:25:55 -0700
| Newsgroups | gmane.comp.security.firewalls.ipfilter |
|---|---|
| Message-ID | <4023_1271212050_4BC52812_4023_1027_1_4BC527B3.40009@reed.wattle.id.au> |
Paul B. Henson wrote:
> On Tue, 13 Apr 2010, Darren Reed wrote:
>
>> unfortuantely the version of code in Solaris 10 U8 is pretty old and
>> doesn't give you any additional insight.
>
> Bummer :(, I would have hoped once they pulled it in as an official
> component they would have kept it up to date.
Well, to gain an insight into its priority at Oracle,
just look on OpenSolaris's networking-discuss list.
Try and find any discussion about updating IPFilter
to a newer (patch) release.
> This is the third or fourth
> problem we've had in the last year or so. We were fortunate enough not to
> have installed the recent ipf patch that completely broke state before it
> was withdrawn so managed to miss that escapade. I guess we could upgrade to
> your latest release; but we used to run ipf under Solaris 8, and it was a
> huge PITA dealing with Sun support running a third party kernel module 8-/.
>
> Is the ipf bundled in OpenSolaris more up to date? We were planning on
> migrating, although now with the Oracle takeover we're probably going to
> sit for a while and see how things pan out.
No, it's not any more up to date.
If you have time, experiment with OpenSolaris.
It is no longer to buy support for it.
As an open source author, I am only targeting the commercial
releases.
>> What you might be able to do is use dtrace to provide some additional clues
>> by using where the return is being made from:
>>
>> # dtrace -n 'fbt:ipf:fr_addstate:return/arg1==0/{@returns[arg0] = count();}'
>
> My dtrace skill level isn't that high; I ran this for a while, during which
> interval the lost count increased by 1 or 2, and when I C-c'd dtrace it
> spit out:
>
> 1720 2
>
> Does that have any helpful meaning?
Well, it means that if you were to do this:
# adb -k
fr_addstate+6b8/i
that would be about where (in the fr_addstate function) that
it is returning back NULL. In S10U7, the code appears to get
to this region from a jump when there are too many state entries...
Can you paste the entire output from "ipfstat -s"?
Also, try this with dtrace:
# dtrace -n 'fbt:ipf:fr_addstate:entry{self->ifs=((fr_info_t
*)arg0)->fin_ifs;}' -n 'fbt:ipf:fr_addstate:return/arg1==0/{printf("num
%d max %d", ((ipf_stack_t *)self->ifs)->ifs_ips_num, ((ipf_stack_t
*)self->ifs)->ifs_fr_statemax);}'
Darren
(at home sick today)