Bug 199951
Summary: | Packets injected with libpcap into veth started to have trailer and FCS, are dropped because too long | ||
---|---|---|---|
Product: | Networking | Reporter: | Piotr Jurkiewicz (piotr.jerzy.jurkiewicz) |
Component: | Other | Assignee: | Stephen Hemminger (stephen) |
Status: | RESOLVED CODE_FIX | ||
Severity: | normal | CC: | xiyou.wangcong |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.16.12 | Subsystem: | |
Regression: | Yes | Bisected commit-id: |
Description
Piotr Jurkiewicz
2018-06-06 18:39:54 UTC
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. |