Re: npf bug(?)

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

In article <Pine.NEB.4.64.1703301513250.22851%6bone.informatik.uni-leipzig.de@localhost>,
 <6bone%6bone.informatik.uni-leipzig.de@localhost> wrote:
>On Mon, 20 Mar 2017, Tom Ivar Helbekkmo wrote:
>
>> Christos Zoulas <christos%zoulas.com@localhost> writes:
>>
>>> Current has been changed not to do reassembly for IPv6 so this will
>>> probably solve your problems. We found that the v6 reassembly code
>>> does not work properly. The patch is simple and should apply to -7.
>
>Thanks for the patch. Unfortunately, I could not apply it to -7. I've 
>tested -current. The problem seems to be solved.
>
>After an hour the statistics show the following:
>
>Fragmentation:
>         649 fragments
>         586 reassembled
>         3517 failed reassembly
>
>How can this happen if npf not tried to reassembly IPv6 packets?

We have this code:

        flags = npf_cache_all(&npc);
        if (__predict_false(flags & NPC_IPFRAG)) {
                /*
                 * We pass IPv6 fragments unconditionally
                 * The first IPv6 fragment is not marked as such
                 * and passes through the filter
                 */
                if (flags & NPC_IP6)
                        return 0; 
                /*
                 * Pass to IPv4 reassembly mechanism.
                 */
                error = npf_reassembly(npf, &npc, mp);
                if (error) {
                        con = NULL;
                        goto out; 
                } 
                if (*mp == NULL) {
                        /* More fragments should come; return. */
                        return 0;
                }
        }

All the statistics are incremented in npf_reassembly. This means that they
must be ipv4 packets... Don't you have any v4 traffic?

christos