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>

Further source analysis confirms that for netstat, the "bad" fragments
are not counted as fragments received, but that (as expected) a fragment
which completes a packet is counted as both a fragment received, and a
packet reassembled (unlike with npf).

Further it is clear that ...

  | There is again a difference between the npf counters and the counters of 
  | the IP stack.

(side from them counting different things - slightly) it is clear that this
cannot happen, as the way it works (it appears to me) is ...

	packet arrives at interface
	npf examines packet
	npf determines packet is fragmented
		calls IPv4 reassembly routine for IPv4 packets
		(drops or passes through IPv6 fragments ... didn't check)
	if packet is now complete, pass to IP
	otherwise, done and wait for another frag

	IP gets the packet
	tests if it is fragmemted.
	answer must be "no" or npf would not have let the packet through.
	processing continues...

That is, the IP reassembly stats come from when npf reassembles the
packet (reassembly is not done twice) and so whatever is seen by the
IP frag counters is coming from npf's reaassembly process.

This also explains npf's lack of a "timed out" counter - npf never does
that, it is invoked from an incoming packet, and that's it ... fragments
hang about in the regular IP reassembly queues, and the normal IP
reassembly timer runs on them, the 33 packets that failed to be completed
in the IP stats, also failed to be completed in npf's reassembly (as they
are the same thing) but npf never knows that happened, and so cannot
implement a counter of its own.

This is still all *currently anyway) just v4 of course...

kre

ps: there is one (apparent) place in npf where an incoming fragment is
counted nowhere - that's where the packet reassembly completes, but
turns out to still be a fragment.   That is, there's some disagreement
somewhere in the code whether reassembly succeeded or not.   That case
should probably be a panic() rather than a "return EINVAL".