netdev - Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA driver

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:   Mon, 23 Jan 2023 13:54:41 +0300
From:   Arınç ÜNAL <arinc.unal@...nc9.com>
To:     frank-w@...lic-files.de, netdev <netdev@...r.kernel.org>
Cc:     Lorenzo Bianconi <lorenzo@...nel.org>,
        Sergio Paracuellos <sergio.paracuellos@...il.com>
Subject: Re: gmac1 issues with mtk_eth_soc & port 5 issues with MT7530 DSA
 driver

On 13.09.2022 16:45, Frank Wunderlich wrote:
> Am 13. September 2022 14:54:20 MESZ schrieb "Arınç ÜNAL" <arinc.unal@...nc9.com>:
>> I'd like to post a few more issues I stumbled upon on mtk_eth_soc and MT7530 DSA drivers. All of this is tested on vanilla 6.0-rc5 on GB-PC2.
>>
>> ## MT7621 Ethernet gmac1 won’t work when gmac1 is used as DSA master for MT7530 switch
>>
>> There’s recently been changes on the MT7530 DSA driver by Frank to support using port 5 as a CPU port.
>>
>> The MT7530 switch’s port 5 is wired to the MT7621 SoC’s gmac1.
>>
>> Master eth1 and slave interfaces initialise fine. Packets are sent out from eth1 fine but won't be received on eth1.
>>
>> This issue existed before Lorenzo’s changes on 6.0-rc1.
>>
>> I’m not sure if this is an issue with mtk_eth_soc or the MT7530 DSA driver.
>>
>> ---
>>
>> ## MT7530 sends malformed packets to/from CPU at port 5 when port 6 is not defined on devicetree
>>
>> In this case, I can see eth1 receiving traffic as the receive counter on ifconfig goes up with the ARP packets sent to the mt7621 CPU.
>>
>> I see the mt7621 CPU not responding to the ARP packets (no malformed packets or anything), which likely means ARP packets received on the mt7621 CPU side are also malformed.
>>
>> I think this confirms that the above issue is related to the MT7530 DSA driver as I can see eth1 receiving traffic in this case.
>>
>> Packet capture of the malformed packets are in the attachments.
>>
>> ---
>>
>> ## MT7621 Ethernet gmac1 won’t work when gmac0 is not defined on devicetree
>>
>> eth0 interface is initalised even though it’s not defined on the devicetree, eth1 interface is not created at all.
>>
>> This is likely not related to the MT7530 DSA driver.
>>
>> Arınç
> There are some patches fixing ethernet and dsa driver for getting sfps to work.
> 
> https://git.openwrt.org/?p=openwrt/staging/dangole.git;a=commit;h=9469ba3568d7d9de31dc63de5269c848a1cc1dc7
> 
> And on dsa side imho only to support sfp
> 
> https://github.com/openwrt/openwrt/commit/bd6783f4fb8f6171927e9067c0005a6d69fc13fe
> 
> Hope the first patches help you with your issue

Thanks for pointing these patches out Frank. I tried these but it didn't 
fix any of the issues I described.

It's been a while since this post. In the meantime, I've gained access 
to a Bananapi BPI-R2 and tested whether the first issue I described 
exists there too. It does. The behaviour on that one was slightly 
different which helped me actually figure out what part of the code 
causes this. I'll send another reply to this post to explain all that.

Arınç