Re: IPFilter issue in -current

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

On 23/12/2012 8:34 PM, Geoff Adams wrote:
...
> The slightly good news is that patching ns_bucketlen to 0 after
> noticing this problem keeps everything happy, where before all
> clients on the network would regularly see random connection
> failures. (Please excuse the extreme hackery in that code; I was
> sleep deprived. Even decent debugging printfs would test for 0
> before decrementing, rather than that ugliness.)
> 
> I haven't had time to track down what causes them to be 0 at this point, 
> though.

That's the problem. Something else could be going on, like a memory
leak or you're creating a potential memory leak, but since we don't
yet know what the cause is, it is hard to know what treating the
symptom is letting happen.

> One final thing I've discovered: The following printf gets hit fairly 
> frequently (as seen above):
> 
> Index: ip_nat.c
> ===================================================================
> RCS file: /cvsroot/src/sys/external/bsd/ipf/netinet/ip_nat.c,v
> retrieving revision 1.7
> diff -u -r1.7 ip_nat.c
> --- ip_nat.c  20 Dec 2012 21:42:28 -0000      1.7
> +++ ip_nat.c  23 Dec 2012 09:20:58 -0000
> @@ -2992,6 +3007,7 @@
>       if (natl != NULL) {
>               DT2(ns_new_xlate_exists, fr_info_t *, fin, nat_t *, natl);
>               NBUMPSIDE(0, ns_xlate_exists);
> +             printf("ipf_nat_newrdr: mapping already exists!\n");
>               return -1;
>       }
>  
> This causes ipf_nat_add to jump to badnat.
> I also haven't yet spent any time looking into why this occurs.

This is where a dtrace enabled kernel would help ;)

I would be curious to see what the timestamp of the output of those
printfs about ipf_nat_newrdr was relative to that of "NEW RDR" lines
from "ipmon -oN" (or do you run ipmon with -a?)

Darren