On Tue, 30 Jun 2020 21:05:27 -0600 "Jason A. Donenfeld" <ja...@zx2c4.com> wrote:
> On Sun, Jun 28, 2020 at 2:04 PM Willem de Bruijn > <willemdebruijn.ker...@gmail.com> wrote: > > > > On Sat, Jun 27, 2020 at 1:58 AM Jason A. Donenfeld <ja...@zx2c4.com> wrote: > > > > > > Hi again Hans, > > > > > > A few remarks: although gre implements header_ops, it looks like > > > various parts of the networking stack change behavior based on it. I'm > > > still analyzing that to understand the extent of the effects. > > > Something like > > > <https://git.zx2c4.com/wireguard-linux/commit/?id=40c24fd379edc1668087111506ed3d0928052fe0> > > > would work, but I'm not thrilled by it. Further research is needed. > > > > > > However, one thing I noticed is that other layer 3 tunnels don't seem > > > to be a fan of libpcap. For example, try injecting a packet into an > > > ipip interface. You'll hit exactly the same snag for skb->protocol==0. > > > > Not setting skb protocol when sending over packet sockets causes many > > headaches. Besides packet_parse_headers, virtio_net_hdr_to_skb also > > tries to infer it. > > > > Packet sockets give various options to configure it explicitly: by > > choosing that protocol in socket(), bind() or, preferably, by passing > > it as argument to sendmsg. The socket/bind argument also configures > > the filter to receive packets, so for send-only sockets it is > > especially useful to choose ETH_P_NONE (0) there. This is not an > > "incorrect" option. > > > > Libpcap does have a pcap_set_protocol function, but it is fairly > > recent, so few processes will likely be using it. And again it is > > still not ideal if a socket is opened only for transmit. > > > > header_ops looks like the best approach to me, too. The protocol field > > needs to reflect the protocol of the *outer* packet, of course, but if > > I read wg_allowedips_lookup_dst correctly, wireguard maintains the > > same outer protocol as the inner protocol, no sit (6-in-4) and such. > > WireGuard does allow 6-in-4 and 4-in-6 actually. But parse_protocol is > only ever called on the inner packet. The only code paths leading to > it are af_packet-->ndo_start_xmit, and ndo_start_xmit examines > skb->protocol of that inner packet, which means it entirely concerns > the inner packet. And generally, for wireguard, userspace only ever > deals with the inner packet. That inner packet then gets encrypted and > poked at in strange ways, and then the encrypted blob of sludge gets > put into a udp packet and sent some place. So I'm quite sure that the > behavior just committed is right. > > And from writing a few libpcap examples, things seem to be working > very well, including Hans' example. > > Hans - if you want to try out davem's net.git tree, you can see if > this is working properly for you. I just tested it and everything seems to work now. Thanks :) Hans
