Re: npf bug(?)

[christos%zoulas.com@localhost (Christos Zoulas)]

On Apr 9, 10:53pm, 6bone%6bone.informatik.uni-leipzig.de@localhost (6bone%6bone.informatik.uni-leipzig.de@localhost) wrote:
-- Subject: Re: npf bug(?)

| On Sun, 9 Apr 2017, Christos Zoulas wrote:
| 
| > Perhaps you get a lot of dup fragments? netstat -s should show you the
| > stack's reassembly and fragment stats. Perhaps those agree with what
| > npf shows?
| 
| Currently the patch is active. That's why I have no npf statistics. The 
| netstat statistics seem to me credible.
| 
| If npf checks the fragmentation, then the counters of npf and the ip stack 
| run parallel? Or are the ip stack only counted the packets the npf leaves?

Npf just calls "error = ip_reass_packet(mp, ip)" and if that fails
it increments NPF_STAT_REASSFAIL. Since it uses the same exact
call the regular ip stack uses, I would expect that:

    NPF_STAT_REASSFAIL = IP_STAT_BADFRAGS + IP_STAT_RCVMEMDROP;

>From your stats I see (without npf):

         1795 fragments received

          335 malformed fragments dropped
          440 fragments dropped after timeout
          636 packets reassembled ok
	  ---
	 1411 what happened to the rest?

I guess we should look at the code to figure out if we are not printing
some, or we and not updating the status for some. Nevertheless, the stack
seems to be able to reassemble a bit more 1/3 of the fragments, while 2/3
of them are dropped. What's the ratio with npf?

christos