On Mon, Nov 9, 2020 at 4:05 AM Oliver Herms
<oliver.peter.he...@gmail.com> wrote:
>
>
> 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.
And the only header in the case of SIT is that outer ip header. Got it, thanks.
Overly conservative MTU calculation is one issue. Packet sockets also
expect read/write link layer access with SOCK_RAW, which does not work
correctly for sit. I'm not sure that it ever did.
The chosen commit predates all stable trees, which is the most important point.
Acked-by: Willem de Bruijn <will...@google.com>
Could ip6 tunnels have the same issue? In ip6_tnl_dev_init_gen,
dev->hard_header_len = LL_MAX_HEADER + t_hlen;
