netdev - Re: [PATCH] usbnet: Set duplex status to unknown in the absence of MII

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: <20250723012926.1421513-1-yicongsrfy@163.com>
Date: Wed, 23 Jul 2025 09:29:26 +0800
From: yicongsrfy@....com
To: andrew@...n.ch
Cc: andrew+netdev@...n.ch,
	davem@...emloft.net,
	linux-usb@...r.kernel.org,
	netdev@...r.kernel.org,
	oneukum@...e.com,
	yicong@...inos.cn,
	yicongsrfy@....com
Subject: Re: [PATCH] usbnet: Set duplex status to unknown in the absence of MII

On Tue, 22 Jul 2025 15:06:37 +0200	[thread overview] Andrew <andrew@...n.ch> wrote:
>
> On Tue, Jul 22, 2025 at 10:09:33AM +0800, yicongsrfy@....com wrote:
> > Thanks for your reply!
> >
> > According to the "Universal Serial Bus Class Definitions for Communications Devices v1.2":
> > In Section 6.3, which describes notifications such as NetworkConnection and ConnectionSpeedChange,
> > there is no mention of duplex status.In particular, for ConnectionSpeedChange, its data payload
> > only contains two 32-bit unsigned integers, corresponding to the uplink and downlink speeds.
>
> Thanks for checking this.
>
> Just one more question. This is kind of flipping the question on its
> head. Does the standard say devices are actually allowed to support
> 1/2 duplex? Does it say they are not allowed to support 1/2 duplex?
>
> If duplex is not reported, maybe it is because 1/2 duplex is simply
> not allowed, so there is no need to report it.
>

No, the standard does not mention anything about duplex at all.

However, Chapter 2 of the standard describes the scope of devices
covered by CDC, including wired and wireless network adapters,
among others.

We know that wireless communication is inherently half-duplex;
for wired network adapters, the duplex status depends on the
capabilities of both communication ends.

One of the USB network adapters I have (AX88179) supports both
the vendor-specific driver and the cdc_ncm driver.

When using the vendor-specific driver, all operational states
function normally, and the information reported by ethtool
matches the actual hardware behavior — which means the hardware
definitely supports both full-duplex and half-duplex modes.

The issue we are discussing only occurs when using the cdc_ncm driver.

To further investigate, I conducted the following tests using
the cdc_ncm driver:

1. I set the peer network adapter (r8169) to auto-negotiation
and connected it to the device under test. On the peer adapter,
I was able to observe that the link was operating in full-duplex mode.

2. I disabled auto-negotiation on the peer adapter and manually
set it to half-duplex. The setting was successfully applied,
and communication remained functional.

>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.