On Wed, Nov 11, 2020 at 05:48 AM CET, Andrii Nakryiko wrote:
> On Tue, Nov 10, 2020 at 9:12 AM Santucci Pierpaolo
> <santucci@xxxxxxxxxxxxxx> wrote:
>>
>> From second fragment on, IPV6FR program must stop the dissection of IPV6
>> fragmented packet. This is the same approach used for IPV4 fragmentation.
>>
>
> Jakub, can you please take a look as well?
I'm not initimately familiar with this test, but looking at the change
I'd consider that Destinations Options and encapsulation headers can
follow the Fragment Header.
With enough of Dst Opts or levels of encapsulation, transport header
could be pushed to the 2nd fragment. So I'm not sure if the assertion
from the IPv4 dissector that 2nd fragment and following doesn't contain
any parseable header holds.
Taking a step back... what problem are we fixing here?
>
>> Signed-off-by: Santucci Pierpaolo <santucci@xxxxxxxxxxxxxx>
>> ---
>> tools/testing/selftests/bpf/progs/bpf_flow.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/tools/testing/selftests/bpf/progs/bpf_flow.c b/tools/testing/selftests/bpf/progs/bpf_flow.c
>> index 5a65f6b51377..95a5a0778ed7 100644
>> --- a/tools/testing/selftests/bpf/progs/bpf_flow.c
>> +++ b/tools/testing/selftests/bpf/progs/bpf_flow.c
>> @@ -368,6 +368,8 @@ PROG(IPV6FR)(struct __sk_buff *skb)
>> */
>> if (!(keys->flags & BPF_FLOW_DISSECTOR_F_PARSE_1ST_FRAG))
>> return export_flow_keys(keys, BPF_OK);
>> + } else {
>> + return export_flow_keys(keys, BPF_OK);
>> }
>>
>> return parse_ipv6_proto(skb, fragh->nexthdr);
>> --
>> 2.29.2
>>
