Date: Thu, 13 Apr 2017 08:13:12 +0200 (CEST) From: 6b...@6bone.informatik.uni-leipzig.de Message-ID: <pine.neb.4.64.1704130759160.22...@6bone.informatik.uni-leipzig.de>
| 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