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: <77738f53-591f-4cfa-b65b-9789911ca4b3@suse.com>
Date: Wed, 23 Jul 2025 12:03:06 +0200
From: Oliver Neukum <oneukum@...e.com>
To: yicongsrfy@....com, oneukum@...e.com
Cc: andrew+netdev@...n.ch, andrew@...n.ch, davem@...emloft.net,
 linux-usb@...r.kernel.org, netdev@...r.kernel.org, yicong@...inos.cn
Subject: Re: [PATCH] usbnet: Set duplex status to unknown in the absence of
 MII

On 23.07.25 10:44, yicongsrfy@....com wrote:
> On Wed, 23 Jul 2025 09:17:02 +0200 Oliver <oneukum@...e.com> wrote:
>>
>> On 23.07.25 03:29, yicongsrfy@....com wrote:
>>
>>>   From these two tests, we can conclude that both full-duplex
>>> and half-duplex modes are supported — the problem is simply
>>> that the duplex status cannot be retrieved in the absence of
>>> MII support.
>>
>> Sort of. You are asking a generic driver to apply a concept
>> from ethernet. It cannot. Ethernet even if it is half-duplex
>> is very much symmetrical in speed. Cable modems do not, just
>> to give an example.
>>
>> I think we need to centralize the reaction to stuff that is not ethernet.
> 
> Thanks!
> 
> I think I understand what you mean now.
> You're suggesting to create a unified interface or
> framework to retrieve the duplex status of all CDC
> protocol-supported devices?

Well no. We have to understand that the difference in duplex
status apply only to a subset of devices. In a way the network
layer is deficient in only having an unknown status rather than
an unknown and an inapplicable status.

If we are to retain a single status for simplicity, then
I'd say that the default being half duplex rather than
unknown is wrong.

> This seems like a rather big undertaking, and one of the key
> reasons is that the CDC protocol itself does not define anything
> related to duplex status — unlike the 802.3 standard, which
> clearly defines how to obtain this information via MDIO.

CDC is not a network protocol. CDC is a protocol for talking
to network devices. CDC can define a way to transmit duplex
information. If the protocol under CDC does not have the notion,
this will be of no use.

> Coming back to the issue described in this patch,
> usbnet_get_link_ksettings_internal is currently only used in
> cdc_ether.c and cdc_ncm.c as a callback for ethtool.
> Can we assume that this part only concerns Ethernet devices
> (and that, at least for now, none of the existing devices can
> retrieve the duplex status through this interface)?

Yes. It is not really that important. But strictly speaking the
network layer is using the wrong default.

	Regards
		Oliver


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ