On 04.11.20 20:52, Willem de Bruijn wrote:
>>>> Fixes: c54419321455 ("GRE: Refactor GRE tunneling code.")
>>>
>>> How did you arrive at this SHA1?
>> I think the legacy usage of hard_header_len in ipv6/sit.c was overseen in
>> c54419321455.
>> Please correct me if I'm wrong.
>
> I don't see anything in that patch assign or modify hard_header_len.
>
It's not assigning or modifying it but changing expectations about how
dev->hard_header_len is to be used.
The patch changed the MTU calculation from:
mtu = dst_mtu(&rt->dst) - dev->hard_header_len - tunnel->hlen;
to this:
mtu = dst_mtu(&rt->dst) - dev->hard_header_len - sizeof(struct iphdr);
Later is became this (in patch 23a3647. This is the current implementation.):
mtu = dst_mtu(&rt->dst) - dev->hard_header_len - sizeof(struct iphdr) -
tunnel_hlen;
Apparently the initial usage of dev->hard_header_len was that it contains the
length
of all headers before the tunnel payload. c54419321455 changed it to assuming
dev->hard_header_len
does not contain the tunnels outter IP header. Thus I think the bug was
introduced by c54419321455.
Kind Regards
Oliver
