Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752701AbdLFGDA (ORCPT ); Wed, 6 Dec 2017 01:03:00 -0500 Received: from tama500.ecl.ntt.co.jp ([129.60.39.148]:41172 "EHLO tama500.ecl.ntt.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752546AbdLFGC4 (ORCPT ); Wed, 6 Dec 2017 01:02:56 -0500 X-Greylist: delayed 4666 seconds by postgrey-1.27 at vger.kernel.org; Wed, 06 Dec 2017 01:02:55 EST Subject: Re: Sending 802.1Q packets using AF_PACKET socket on filtered bridge forwards with wrong MAC addresses References: From: Toshiaki Makita Message-ID: <443375f0-f29e-4153-56b0-f17513f19388@lab.ntt.co.jp> Date: Wed, 6 Dec 2017 13:44:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit To: Brandon Carpenter Cc: Stephen Hemminger , "David S. Miller" , bridge@lists.linux-foundation.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Vlad Yasevich X-TM-AS-MML: disable Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1912 Lines: 54 Hi, (CC: Vlad) On 2017/11/30 7:01, Brandon Carpenter wrote: > I narrowed the search to a memmove() called from > skb_reorder_vlan_header() in net/core/skbuff.c. > >> memmove(skb->data - ETH_HLEN, skb->data - skb->mac_len - VLAN_HLEN, >> 2 * ETH_ALEN); > > Calling skb_reset_mac_len() after skb_reset_mac_header() before > calling br_allowed_ingress() in net/bridge/br_device.c fixes the > problem. > > diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c > index af5b8c87f590..e10131e2f68f 100644 > --- a/net/bridge/br_device.c > +++ b/net/bridge/br_device.c > @@ -58,6 +58,7 @@ netdev_tx_t br_dev_xmit(struct sk_buff *skb, struct > net_device *dev) > BR_INPUT_SKB_CB(skb)->brdev = dev; > > skb_reset_mac_header(skb); > + skb_reset_mac_len(skb); > eth = eth_hdr(skb); > skb_pull(skb, ETH_HLEN); Thanks for debugging this problem. It seems this has been broken since a6e18ff11170 ("vlan: Fix untag operations of stacked vlans with REORDER_HEADER off"). Unfortunately this does not always work correctly, since in tx path drivers assume network header to be set to L3 protocol header offset. Packet socket (packet_snd()) determines network header by dev_hard_header which is ETH_HLEN in bridge devices, so this works for packet socket, but with vlan devices on top of bridge device with tx-vlan hwaccel disabled we get ETH_HLEN + VLAN_HLEN or longer by mac_len. Since mac_len can be arbitrarily long if we stack vlan devices on bridge devices, and since we want to untag the outermost tag, using mac_len to untag in tx path is probably no longer correct. I'll think deeper about how to fix it. > I'll put together an official patch and submit it. Should I use > another email account? Are my emails being ignored because of that > stupid disclaimer my employer attaches to my messages (outside my > control)? > > Brandon > -- Toshiaki Makita