Re: npf bug(?)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 13 Apr 2017 08:13:12 +0200 (CEST)
    From:        6bone%6bone.informatik.uni-leipzig.de@localhost
    Message-ID:  <Pine.NEB.4.64.1704130759160.22851%6bone.informatik.uni-leipzig.de@localhost>

  | npf:
  | 
  | Fragmentation:
  |          870 fragments

I thought I should look at the sources...  that counter is slightly
different than what I had guessed it might be, what's being counted
there is the number of times a fragment is received which does not
complete a packet - that is, none of first/last/middle is it, just the
number of times npf ends up waiting on another packet arriving, and ...

  |          102 failed reassembly

those are not included in the 870, rather this counts the number of
incoming fragmented packets that couldn't be reassembled for some
reason (and counts both v4 & v6 if both are being passed to npf ... all
incoming v6 fragments will be counted here with npf currently, as it
does not attempt to reassemble v6 packets).

  |          774 reassembled

counts the number of incoming frags that did successfully complete a
packet - so the total number of incoming fragments is the sum of
those three, which is 1746.

If we were then to also assume that in ...

  | netstat:
  |          1644 fragments received
  |          102 malformed fragments dropped

"fragments received" means "valid fragments received", then we also have
1746 received (valid + invalid) fragments.

That makes the npf and netstat numbers agree precisely.

It does however cause a question about

  |          33 fragments dropped after timeout

from netstat, which don't seem to be counted anywhere else.

kre