netdev - Re: [PATCH net] r8169: fix multicast tx issue with macvlan interface

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Fri, 27 Mar 2020 10:39:17 +0100
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Charles Daymand <charles.daymand@...irst.fr>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net] r8169: fix multicast tx issue with macvlan interface

On 27.03.2020 10:08, Charles Daymand wrote:
> During kernel upgrade testing on our hardware, we found that macvlan
> interface were no longer able to send valid multicast packet.
> 
> tcpdump run on our hardware was correctly showing our multicast
> packet but when connecting a laptop to our hardware we didn't see any
> packets.
> 
> Bisecting turned up commit 93681cd7d94f
> "r8169: enable HW csum and TSO" activates the feature NETIF_F_IP_CSUM
> which is responsible for the drop of packet in case of macvlan
> interface. Note that revision RTL_GIGA_MAC_VER_34 was already a specific
> case since TSO was keep disabled.
> 
> Deactivating NETIF_F_IP_CSUM using ethtool is correcting our multicast
> issue, but we believe that this hardware issue is important enough to
> keep tx checksum off by default on this revision.
> 
> The change is deactivating the default value of NETIF_F_IP_CSUM for this
> specific revision.
> 

The referenced commit may not be the root cause but just reveal another
issue that has been existing before. Root cause may be in the net core
or somewhere else. Did you check with other RTL8168 versions to verify
that it's indeed a HW issue with this specific chip version?

What you could do: Enable tx checksumming manually (via ethtool) on
older kernel versions and check whether they are fine or not.
If an older version is fine, then you can start a new bisect with tx
checksumming enabled.

And did you capture and analyze traffic to verify that actually the
checksum is incorrect (and packets discarded therefore on receiving end)?


> Fixes: 93681cd7d94f ("r8169: enable HW csum and TSO")
> Signed-off-by: Charles Daymand <charles.daymand@...irst.fr>
> ---
>  net/drivers/net/ethernet/realtek/r8169_main.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/drivers/net/ethernet/realtek/r8169_main.c b/net/drivers/net/ethernet/realtek/r8169_main.c
> index a9bdafd15a35..3b69135fc500 100644
> --- a/net/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/net/drivers/net/ethernet/realtek/r8169_main.c
> @@ -5591,6 +5591,9 @@ static int rtl_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
>  		dev->vlan_features &= ~(NETIF_F_ALL_TSO | NETIF_F_SG);
>  		dev->hw_features &= ~(NETIF_F_ALL_TSO | NETIF_F_SG);
>  		dev->features &= ~(NETIF_F_ALL_TSO | NETIF_F_SG);
> +		if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
> +			dev->features &= ~NETIF_F_IP_CSUM;
> +		}
>  	}
>  
>  	dev->hw_features |= NETIF_F_RXALL;
>