Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: npf bug(?)



On Mon, 10 Apr 2017, Christos Zoulas wrote:

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?


Sorry for the long response time. I could not restart the router. Now runs the kernel without the patch. I have made sure that all counter at 0 are started.

After a few hours the statistics look as follows:

npf:

Fragmentation:
        870 fragments
        774 reassembled
        102 failed reassembly

netstat:
        1644 fragments received
        0 fragments dropped (dup or out of space)
        0 fragments dropped (out of ipqent)
        102 malformed fragments dropped
        33 fragments dropped after timeout
        774 packets reassembled ok

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


Regards
Uwe


Home | Main Index | Thread Index | Old Index