Control USB power on a port by port basis on some USB hubs | Hacker News Reader

Control USB power on a port by port basis on some USB hubs

github.com

82 pointscodazoda33 comments

This is what I have a ykush[1] hub for, with an iLok dongle plugged in and VirtualHere sharing that USB device over the network. Only one machine can use the dongle at a time (so it's basically just a way to not have to constantly walk a dongle from a laptop to a workstation to a bedroom computer and back) the iLok binds the machine id of whatever computer's using it and the only way to clear it is to unplug the iLok. Or cut its power. A simple LAN-only server that accepts a "GET /reset-usb" call that cycles the power on each of the ports on the hub solves that problem

[1] https://www.yepkit.com/products/ykush

I'd forgotten about VirtualHere, thanks for the reminder.

https://www.virtualhere.com - VirtualHere might be exactly what I've been looking for ...

Is this just a less polished/active version of https://github.com/mvp/uhubctl?

Thanks for linking! This one is way more up to date with regards to compatible USB hubs. It credits the project in the OP:

>Original idea for this code was inspired by hub-ctrl.c by Niibe Yutaka: https://www.gniibe.org/development/ac-power-control-by-USB-h...

I want power only USB Cables. The USB-C protcoll was allready a security thread resulting in unlocking fde and successfull boot up

amazon has them, or you can get "usb condoms".

I’m more a fan of the unsafe ejection method.

Make sure to get the ones with active circuitry on them to negotiate charging speed, otherwise you will be stuck at 5v and under an amp.

I got some ti chip ones from aliexpress for around 4 bucks each that have worked flawlessly on laptops and phones.

yes that negotion is a specific protocoll of USB-C and was used to unlock fde encryption through the USB-C port connected secure enclave, that was happy to decrypt fed as if you had entered the password. the next generation had magsafe again :)

If you're talking about the T2 vulnerability - no, PD negotiation is not sufficient, you need arbitrary data communication.

mind sharing a reference? didn't say it's a pd vuln btw edit: ah, I see – did say exactly that.

sorry, but NO I didn't meant to say that. but part of the problem and part of the solution was usbc/nomore usbc.

Do you happen to have that github link with the poc link to youtube?

It's not just pd, it does all the wacky Samsung and other negotiation types too.

We used something like this for one of the high resolution depth cameras we had that had some buggy driver/firmware issue. IT needed to be power cycled every once in a while...

I've used this in the past for power cycling USB-powered embedded boards in a test farm, but the dependency on specific hubs is a pain. In the end it was easier to dedicate an RPi per board. The generation of RPi I was using could switch the overall USB power and that was good enough [1].

[1] https://github.com/bfletcher/remote-usb-target

Note that this works with most hubs inside laptops.

I use it to turn a USB desk lamp on and off.

Hmmm. Readme unfortunately fails to note what the required hardware is (that apparently has a common/shared control interface) which makes these USB hubs controllable.

What? They list several hubs that work, I guess you could buy any of these.

https://github.com/codazoda/hub-ctrl.c#hubs-known-to-work

In my experience, the hubs listed tend to be obsolete. For instance, that LinkSys one I just looked up and its manual is copyright 15 years ago.

Someone on Amazon is boldly offering to sell you one, a 4 port USB 2.0 hub, for $72, but whether they actually have it or are a robot planning to order one from another robot that doesn’t have it but thinks it can get it for $60 is anyone’s guess.

Last time I went through hubctl’s list, none were available new, and lots of the ones listed have “issues” where later buyers can’t make them work (probably because the manufacturer changed the design but kept the model number). But that’s been a few years.

I just like to tell the manufacturers that I’m a niche, but I will happily pay double for them to put the current sense shunts and power switching transistors from the IC reference design on their board.

https://www.yepkit.com/products/ykush linked elsewhere seems available.

Also listed elsewhere, this repo has a much more up to date list. Maybe I should make an edit to the repo after all these years!

I also had trouble finding the original author online when I created the GitHub repo, but the other repo links him. I’m sure this didn’t exist back in the day. I did reach out to Niibe Yutaka way back and get his permission to post on GitHub.

https://github.com/mvp/uhubctl

Maybe my wording could have been clearer. The hardware within the hubs listed (which you linked and I'd already seen)... I'm assuming there's something in common among them, for a library to work broadly with them.

I know other hubs, like those by Acroname, have their own libraries for power control of USB ports. (and I would guess are not supported by this library)

Would be nice if someone could intergrate this with the OS itself so that if some USB device stops responding, the OS "unplugs and plugs" it automatically until it works.

USB was always a shitty standard to begin with, nothing should ever require unplugging and plugging to get it to work, yet I have to do that to my webcam every day.

USB has a built in protocol level reset that should achieve the same thing. The only change is 5V power is not cut. It's basically the same as doing an OS reboot from the peripheral's perspective.

If the USB device still doesn't respond then it means that they have some buggy firmware that requires a hard reboot to work.

Example for a USB reset in linux: https://marc.info/?l=linux-usb&m=121459435621262&w=2

I've tried that, my RealSense camera and several other USB devices I've used require physically unplugging and plugging after every reboot or it refuses to work.

That Linux USB reset does not work.

I've got experience with this... `reboot` won't work, as it doesn't cut power, but if you can do `rtcwake -m off -s 30`, the power to the USB ports gets cut in between the computer being off and booting back up again.

(I even replace `reboot` with a script warning of this gotcha :) )

Caveat: this is with a typical x86 motherboard. Not all SBCs have RTCs needed to use rtcwake (e.g. RPi doesn't I think?)

You need to cut the power for certain USB devices to actually reset their in-device memory though (like an iLok dongle). Just "disconnecting and reconnecting" via software without a power cycle won't do anything for those. And that's not a bug, in dongles that's literally an anti-piracy feature.

Some devices (mostly security devices) trigger things based on the physical connection state, cycle count, etc. and it's useful to have a means to test these.

I've never seen a device so far that has a physical switch to make sure it's really been unplugged, but I'd imagine someone could find a use case.

That doesn't solve the problem that I still need to do it though. I've got this problem right now with my Blue microphone: it hates being rebooted without being power-cycled for some reason.

Yeah, this would be really useful for my RP2040Zero project.

I don't know if it's the board or if it's down to circuitpython, but being able to software powercycle the USB ports on my motherboard would be really useful, particularly as the RP2040 is mounted inside the PC.

Has anyone come across a way to do this in Windows?

Not really, we needed that on windows and ended up buying a Pegasus Astro USB Control Hub (https://pegasusastro.com/products/usb-control-hub/).

We needed to reset a plugged high-speed webcam, and we needed high-speed USB3, and the ability to cut the data lines too.

The Windows driver (usbctl.sys?) does not support the USB power control commands, the solution that Pegasus or Yepkit use is to add a HID/COM USB device to control the power rail. [edit] We used Pegasus instead of yepkit due to it going to a customer setup, and the bare-board yepkit was a no-go.

Reply on news.ycombinator.com