On Sat, Oct 10, 2020 at 11:58 AM Cong Wang wrote:
>
> Well, AF_PACKET RAW socket is supposed to construct L2 headers
> from the user buffer, and for a tunnel device these headers are indeed its
> L2. If users do not want to do this, they can switch to DGRAM anyway.
>
> I know how inconvenient it i
On Sat, Oct 10, 2020 at 2:49 PM Xie He wrote:
>
> Another reason why tunnel devices usually don't provide
> header_ops->create might be to keep consistency with TAP devices. TAP
> devices are just like tunnel (TUN) devices except that they use an
> additional Ethernet header after the tunnel heade
On Fri, Oct 9, 2020 at 8:10 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 6:07 PM Cong Wang wrote:
> >
> > Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
> > because 1) all other tunnels devices do not have it (ip_tunnel_header_ops
> > only contains ->parse_protocol); 2) G
On Sat, Oct 10, 2020 at 11:58 AM Cong Wang wrote:
>
> On Fri, Oct 9, 2020 at 8:10 PM Xie He wrote:
> >
> > This seems so weird to me. If a user is using an AF_PACKET/RAW socket,
> > the user is supposed to do what the header_ops->create function does
> > (that is, creating two headers and leaving
On Fri, Oct 9, 2020 at 6:07 PM Cong Wang wrote:
>
> Looking a bit deeper, I doubt the ipgre_header_ops->create is necessary,
> because 1) all other tunnels devices do not have it (ip_tunnel_header_ops
> only contains ->parse_protocol); 2) GRE headers are pushed in xmit
> anyway, so at least SOCK_D
On Fri, Oct 9, 2020 at 1:38 PM Cong Wang wrote:
>
> Interesting point. I think needed_headroom is 0 until we call
> ipgre_changelink(), but needed_headroom is already being used
> in multiple places for skb_cow_head() in the same file, I guess
> they should be replaced with hard_head_len because f
On Fri, Oct 9, 2020 at 12:51 PM Xie He wrote:
>
> On Fri, Oct 9, 2020 at 12:41 PM Xie He wrote:
> >
> > Thanks. But there is still something that I don't understand. What is
> > needed_headroom used for? If we are requesting space for t->encap_hlen
> > and t->tun_hlen in hard_header_len. Do we st
On Fri, Oct 9, 2020 at 12:41 PM Xie He wrote:
>
> Thanks. But there is still something that I don't understand. What is
> needed_headroom used for? If we are requesting space for t->encap_hlen
> and t->tun_hlen in hard_header_len. Do we still need to use
> needed_headroom?
It seems to me that the
On Fri, Oct 9, 2020 at 10:44 AM Cong Wang wrote:
>
> On Thu, Oct 8, 2020 at 4:40 PM Xie He wrote:
> >
> > I found another possible issue. Shouldn't we update hard_header_len
> > every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
>
> Good catch. It should be updated there like ->
On Thu, Oct 8, 2020 at 4:40 PM Xie He wrote:
>
> I found another possible issue. Shouldn't we update hard_header_len
> every time t->tun_hlen and t->hlen are updated in ipgre_link_update?
Good catch. It should be updated there like ->needed_headroom.
I will update my patch.
Thanks.
On Thu, Oct 8, 2020 at 2:54 PM Xie He wrote:
>
> OK. If the t->encap_hlen header needs to be placed before the GRE
> header, then I think the ipgre_header function should leave some space
> before the GRE header to place the t->encap_hlen header, rather than
> leaving space after the GRE header.
On Thu, Oct 8, 2020 at 2:48 PM Willem de Bruijn
wrote:
>
> > 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 afte
On Thu, Oct 8, 2020 at 5:36 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 1:32 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 4:11 PM Xie He wrote:
> > >
> > > OK. I understand that t->tun_hlen is the GRE header length. What is
> > > t->encap_hlen?
> >
> > I've looked at that closely
On Thu, Oct 8, 2020 at 1:32 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 4:11 PM Xie He 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:
On Thu, Oct 8, 2020 at 4:11 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 12:20 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
> > >
> > > However, there's something I don't understand in the GRE code. The
> > > ipgre_header function only creates an IP header (20
On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
>
> GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
> conditionally. When it is set, it assumes the outer IP header is
> already created before ipgre_xmit().
>
> This is not true when we send packets through a raw packet socket,
> wh
On Thu, Oct 8, 2020 at 12:20 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
> >
> > However, there's something I don't understand in the GRE code. The
> > ipgre_header function only creates an IP header (20 bytes) + a GRE
> > base header (4 bytes), but pushes and retu
On Thu, Oct 8, 2020 at 12:18 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 3:04 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> > >
> > > On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
> > > wrote:
> > > >
> > > > On Wed, Oct 7, 2020 at 9:22 PM Co
On Thu, Oct 8, 2020 at 3:17 PM Xie He wrote:
>
> On Thu, Oct 8, 2020 at 12:04 PM Willem de Bruijn
> wrote:
> >
> > On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> > >
> > > The uninit data is allocated by packet_alloc_skb(), if
> > > dev->hard_header_len
> > > is 0 and 'len' is anything betwe
On Thu, Oct 8, 2020 at 3:04 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> >
> > On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
> > wrote:
> > >
> > > On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
> > > >
> > > > GRE tunnel has its own header_ops, ipgre_head
On Thu, Oct 8, 2020 at 12:04 PM Willem de Bruijn
wrote:
>
> On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
> >
> > The uninit data is allocated by packet_alloc_skb(), if dev->hard_header_len
> > is 0 and 'len' is anything between [0, tunnel->hlen + sizeof(struct iphdr)),
> > dev_validate_header(
On Thu, Oct 8, 2020 at 1:34 PM Cong Wang wrote:
>
> On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
> wrote:
> >
> > On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
> > >
> > > GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
> > > conditionally. When it is set, it assumes the ou
On Thu, Oct 8, 2020 at 4:49 AM Willem de Bruijn
wrote:
>
> On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
> >
> > GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
> > conditionally. When it is set, it assumes the outer IP header is
> > already created before ipgre_xmit().
> >
> >
On Wed, Oct 7, 2020 at 9:22 PM Cong Wang wrote:
>
> GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
> conditionally. When it is set, it assumes the outer IP header is
> already created before ipgre_xmit().
>
> This is not true when we send packets through a raw packet socket,
> wh
GRE tunnel has its own header_ops, ipgre_header_ops, and sets it
conditionally. When it is set, it assumes the outer IP header is
already created before ipgre_xmit().
This is not true when we send packets through a raw packet socket,
where L2 headers are supposed to be constructed by user. Packet
25 matches
Mail list logo
