netdev - Re: Issues with smsc95xx driver since a049a30fc27c

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]

Message-ID: <Yb4m3xms1zMf5C3T@lunn.ch>
Date:   Sat, 18 Dec 2021 19:22:23 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Gabriel Hojda <ghojda@...urs.ro>
Cc:     Martyn Welch <martyn.welch@...labora.com>, netdev@...r.kernel.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Markus Reichl <m.reichl@...etechno.de>,
        Steve Glendinning <steve.glendinning@...well.net>,
        UNGLinuxDriver@...rochip.com,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, stable@...nel.org
Subject: Re: Issues with smsc95xx driver since a049a30fc27c

> hi Andrew,
> 
> on my odroid-u3, with all kernel versions since 5.15.6 (where the patch was
> applied) and also with 5.16.y if tcpdump is running the network works. when
> tcpdump process is killed/stopped, networking stops working.

O.K, thanks for confirming this. It is a clue to the problem, but i
have 0 idea what it actually means, yet.

> 2.1. kernel 5.15.5 - "mii-tool -vvv eth0"
> 
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok
>   registers for MII PHY 1:
>     3100 782d 0007 c101 01e1 45e1 0001 ffff
>     ffff ffff ffff ffff ffff 0000 0000 0000
>     0040 0002 00e1 ffff 0000 0000 0000 0000
>     0b9d 0000 0000 000a 0000 00c8 0000 1058
>   product info: vendor 00:01:f0, model 16 rev 1
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   advertising:  1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD
>   link partner: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD
> 10baseT-FD 10baseT-HD flow-control
> 
> 2.2. kernel 5.15.8 - "mii-tool -vvv eth0"
> 
> Using SIOCGMIIPHY=0x8947
> eth0: negotiated 1000baseT-HD flow-control, link ok
>   registers for MII PHY 1:
>     3100 782d 0007 c101 01e1 45e1 0003 ffff

                                       ^ 3 vs 1.

but otherwise, they look the same. And it has completed autoneg, and
got the same results. So i would say, the PHY is not the problem, it
is a MAC problem.

> [   23.261816] Generic PHY usb-001:002:01: attached PHY driver
> (mii_bus:phy_addr=usb-001:002:01, irq=POLL)
> 
> 3.1 kernel 5.15.8 - "dmesg | grep -i phy"
> 
> [   11.742916] Generic PHY usb-001:002:01: attached PHY driver

genphy for both.

O.K, stab in the dark. Does the hardware need to be programmed with
the MAC address? When does this happen? If this is going wrong, it
could explain the promisc mode. If the MAC address has not been
programmed, it has no idea what packets are for itself. Put it into
promisc mode, and it will receive everything, including what it is
supposed to receive. But looking at the offending patch, it is not
obvious how it has anything to do with MAC addresses. The only
unbalanced change in that patch is that smsc95xx_reset(dev) has
disappeared, not moved to somewhere else.

	Andrew