I have the following configuration: netns0 netns1 veth0 <---------> veth1 Inside netns0 I inject packets with libpcap into veth0. On kernels 4.16.5 and older packets were correctly received on veth1 in netns1. On kernel 4.16.12 most packets are dropped by interface veth1 (but not all, ICMP and TCP connection establishment sequence goes through, large ones are dropped). When observing packets send on veth0 with Wireshark I notice that: - on 4.16.5 packets are 1512 bytes long and do not include Ethernet trailer and FCS - on 4.16.12 packets are 1526 bytes long and include Ethernet trailer and FCS, which is incorrect (either zeros or some garbage) I suspect that the incorrect FCS is the reason why packets are dropped by veth1. Other explanation could be that packets with trailer and FCS are dropped because they are simply too long (this would explain why small packets are received). I do not have access to binaries of kernel versions other than 4.16.5 and 4.16.12 (using Debian sid), so I cannot tell in which exact version between them this regressions has been introduced.
I can confirm that packets are dropped because they are too long. After raising MTU on veth1 packets are received. But of course this is not a solution or even workaround, since raising MTU on both interfaces would change nothing.
I guess the following commit fixes this issue? commit cb6ae865976164c9e6a5a8fb3ade171412a8a9f7 Author: Willem de Bruijn <willemb@google.com> Date: Thu May 24 18:10:30 2018 -0400 packet: fix reserve calculation [ Upstream commit 9aad13b087ab0a588cd68259de618f100053360e ] Commit b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") ensures that packet_snd always starts writing the link layer header in reserved headroom allocated for this purpose. This is needed because packets may be shorter than hard_header_len, in which case the space up to hard_header_len may be zeroed. But that necessary padding is not accounted for in skb->len. The fix, however, is buggy. It calls skb_push, which grows skb->len when moving skb->data back. But in this case packet length should not change. Instead, call skb_reserve, which moves both skb->data and skb->tail back, without changing length. Fixes: b84bbaf7a6c8 ("packet: in packet_snd start writing at link layer allocation") Reported-by: Tariq Toukan <tariqt@mellanox.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> It is merged in v4.16.15.
I confirm that this bug is fixed in 4.16.15.