Hacker News Reader

Comment by oneplane | Hacker News Reader

This has very little to do with USB-C. The same problem can be observed using a classic USB-A to ethernet adapter when connected to a class USB-A hub that has its own power supply.

The problem is the 'feature' of some USB Ethernet controllers where they keep the ethernet link active when the host disconnects. As described in the article, it's the PAUSE frame that some switches forward to all devices on the network causing them to... pause sending data. The link stays up but nothing happens. Perhaps the idea was that you get a fast connection resume, but it's not like ethernet handshaking takes a lot of time so they might as well simply disconnect the ethernet link when the USB ethernet controller notices the host computer has disconnected.

View on HN

> Perhaps the idea was that you get a fast connection resume

This seems unlikely for the reasons you listed. Since USB is a polled bus and has shared bandwidth, implementing the flow control is likely very beneficial in case the bus can't temporarily handle the full Ethernet speed.

So, a USB-to-Ethernet gizmo just monitors its internal Ethernet-to-USB queue and if it starts to overflow, it attempts to flow control the switch. But, if no USB host is connected, no USB data requests ever arrive, the queue overflows and never gets cleared...

There may also be some WoL/USB remote wakeup stuff at play, which may be why these ICs do not drop the link on USB host disconnect by default. In fact, I wonder if messing with those settings on the host side could remediate the issue...

I meant fast resume on the ethernet side, not the USB side. While the (often) 8051 cores do work for things like magic packets and ASF, it's often not really exposed to the user or kernel unless some device-specific driver is used. Some devices have windows-specific drivers that come with device manager properties tabs for extra settings, but then they hide it in some unclear magic packet handling and energy saving setting instead of a host-baed link control setting (the ethernet link control usually is still there).

The weird thing is that there is a whole lot of cool stuff you can do with the on-chip firmware like mDNS proxy for offline devices, but it's all so hidden and vague that nobody bothers to do a whole lot about it.

No, the problem is some broken switches forwarding PAUSE frames to other ports, in violation of the 802.3 spec. It's perfectly compliant for the adapter to send PAUSE frames when it can't empty the incoming packet queue, but that should only pause the single port on the switch.

While that is of course technically true, we are living in an imperfect world and USB Ethernet controller implementations should probably be aware of those millions of switches out there that use a handful of switch chips with known bad implementations.

Keeping to whatever the spec supports is nice, but if the world doesn't work that way you still get a broken product at the end of the day.

Instead of pause, it should (at least have the option to) disconnect. Ethernet link training isn't a computationally expensive and lengthy process anymore, at least not from the user's perspective. Between plugging it in and moving your hands to your input device L1 and L2 are up before you even get a chance to look at your display with L3 being available pretty quickly thereafter.

Reply on news.ycombinator.com