From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Soltys Subject: Re: [next] bonding: pass link-local packets to bonding master also. Date: Sun, 23 Dec 2018 14:06:57 +0100 Message-ID: References: <20180716011246.225647-1-mahesh@bandewar.net> <120845b4-3828-4473-19bc-ec3ab0b49d4c@ziu.info> <87ftuseo7y.fsf@bernat.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: Mahesh Bandewar , Jay Vosburgh , Andy Gospodarek , Veaceslav Falico , David Miller , Netdev , Mahesh Bandewar , Chonggang Li To: Vincent Bernat Return-path: Received: from drutsystem.com ([84.10.39.251]:43015 "EHLO drutsystem.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728293AbeLWNGP (ORCPT ); Sun, 23 Dec 2018 08:06:15 -0500 In-Reply-To: <87ftuseo7y.fsf@bernat.ch> Content-Language: en-US Sender: netdev-owner@vger.kernel.org List-ID: On 18/12/20 06:55, Vincent Bernat wrote: > ❦ 19 décembre 2018 23:57 +01, Michal Soltys : > >>>> Commit b89f04c61efe ("bonding: deliver link-local packets with >>>> skb->dev set to link that packets arrived on") changed the behavior >>>> of how link-local-multicast packets are processed. The change in >>>> the behavior broke some legacy use cases where these packets are >>>> expected to arrive on bonding master device also. >>> >>> Unfortunately, this doesn't completely restore the previous >>> functionality as PACKET_ORIGDEV is broken for the copy: the original >>> interface is lost through the call to netif_rx(). A LLDP daemon >>> listening to the master interface won't get the original interface like >>> it was able to before 4.12. >>> >>> I am a bit lost of what the original patch was trying to achieve. I am >>> using the following test program: >>> >> >> Basing on what you wrote below, it seems that everything was already >> possible before the Chonggang Li's commit ? >> >> If I understand correctly: >> >> - if listening on master, you could get both slave interface >> (PACKET_ORIGDEV) as well as bonding master >> - if listening on slave, you would just get the slave interface >> >> Right ? > > Yes. This has been this way since 2.6.27. > In the earlier thread, the author of the original patch said that: > The exact problem that was fixed is, when a LLDP/CDP packet is received, we want to know which exact interface did it come from, instead of the bonding master. > > Thanks, > Chonggang But if PACKET_ORIGDEV provided it (and this functionally is now broken, so counts as another regression - earlier bridging issues aside), maybe it should be just reverted ?