On Thu, Oct 8, 2020 at 1:32 PM Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > > On Thu, Oct 8, 2020 at 4:11 PM Xie He <xie.he.0...@gmail.com> wrote: > > > > OK. I understand that t->tun_hlen is the GRE header length. What is > > t->encap_hlen? > > I've looked at that closely either. > > Appears to be to account for additional FOU/GUE encap: > > " > commit 56328486539ddd07cbaafec7a542a2c8a3043623 > Author: Tom Herbert <therb...@google.com> > Date: Wed Sep 17 12:25:58 2014 -0700 > net: Changes to ip_tunnel to support foo-over-udp encapsulation > > This patch changes IP tunnel to support (secondary) encapsulation, > Foo-over-UDP. Changes include: > > 1) Adding tun_hlen as the tunnel header length, encap_hlen as the > encapsulation header length, and hlen becomes the grand total > of these. > 2) Added common netlink define to support FOU encapsulation. > 3) Routines to perform FOU encapsulation. > > Signed-off-by: Tom Herbert <therb...@google.com> > Signed-off-by: David S. Miller <da...@davemloft.net> > "
I see the ipgre_xmit function would pull the header our header_ops creates, and then call __gre_xmit. __gre_xmit will call gre_build_header to complete the GRE header. gre_build_header expects to find the base GRE header after pushing tunnel->tun_hlen. However, if tunnel->encap_hlen is not 0, it couldn't find the base GRE header there. Is there a problem? Where exactly should we put the tunnel->encap_hlen header? Before the GRE header or after?
