netdev - Re: [next] bonding: pass link-local packets to bonding master also.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a252f12d-783f-2455-570d-fe4ea622fc5c@ziu.info>
Date:   Sun, 23 Dec 2018 14:06:57 +0100
From:   Michal Soltys <soltys@....info>
To:     Vincent Bernat <vincent@...nat.ch>
Cc:     Mahesh Bandewar <mahesh@...dewar.net>,
        Jay Vosburgh <j.vosburgh@...il.com>,
        Andy Gospodarek <andy@...yhouse.net>,
        Veaceslav Falico <vfalico@...il.com>,
        David Miller <davem@...emloft.net>,
        Netdev <netdev@...r.kernel.org>,
        Mahesh Bandewar <maheshb@...gle.com>,
        Chonggang Li <chonggangli@...gle.com>
Subject: Re: [next] bonding: pass link-local packets to bonding master also.

On 18/12/20 06:55, Vincent Bernat wrote:
>  ❦ 19 décembre 2018 23:57 +01, Michal Soltys <soltys@....info>:
> 
>>>> 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 ?