Hi Hans,
Your test program appears to be doing:
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = 3
sendto(3,
"E\0\0+\0\0@\0@\21\267o\300\250\1\1\300\250\1\1\4\322\4\322\0\0272\221\1\2\3\4"...,
43, 0, NULL, 0) = 43
This means we're calling into af_packet's packet_sendmsg->packet_snd,
which appears to call packet_parse_headers(skb, sock):
static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)
{
if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
sock->type == SOCK_RAW) {
skb_reset_mac_header(skb);
skb->protocol = dev_parse_header_protocol(skb);
}
skb_probe_transport_header(skb);
}
So the question is, why isn't skb->protocol set on the packet that
makes it to wg_xmit?
Adding some printks, it looks like the result of:
pr_err("SARU %s:%d\n", __FILE__, __LINE__);
skb_reset_mac_header(skb);
skb->protocol = dev_parse_header_protocol(skb);
pr_err("%d\n", skb->protocol);
is:
[ 0.430754] SARU net/packet/af_packet.c:1864
[ 0.431454] 0
So digging a bit further, dev_parse_header_protocol:
static inline __be16 dev_parse_header_protocol(const struct sk_buff *skb)
{
const struct net_device *dev = skb->dev;
if (!dev->header_ops || !dev->header_ops->parse_protocol)
return 0;
return dev->header_ops->parse_protocol(skb);
}
Apparently the issue is that wireguard doesn't implement any
header_ops. I fixed that in this commit here:
https://git.zx2c4.com/wireguard-linux/commit/?id=73b20c384a8bc498c6b8950672003410ed6016da
In my tests, that commit appears to fix the problem exposed by your
test case. I'll probably wait a few days to think about this some more
and make sure this is correct before submitting, but it seems likely
that this will take care of the issue.
Thanks for the report and easy test case!
Jason
