I generally prefer to blog when I’ve solved an obscure problem, or even a not-so-obscure problem, because I’m proud of myself for doing it, and because for everyone out there who already knows the answer, there are 20 people out there who don’t, and I like to be helpful.<\/p>\n\n\n\n
Not this time. I’m blogging about it this time in the hopes that explaining it in sufficient detail might trigger an a-ha moment for me, or maybe that someone out there in the ether will find it and know, and feel that same urgent need to be helpful that I frequently feel.<\/p>\n\n\n\n
So I’ll be as concise as possible here:<\/p>\n\n\n\n
CentOS-based server running VirtualBox.<\/p>\n\n\n\n
Multiple USB devices connected to the server, intended to be passed through to individual VMs.<\/p>\n\n\n\n
These particular devices caused us to settle on VirtualBox, because it was on the only virtualization platform we found that could pass them through reliably in a usable way.<\/p>\n\n\n\n
So we found one that we like as far as function set and usability. We’re happily plugging along and making our VM work happily with it. OK, let’s make another one. Spin up another VM, plug in another (identical) device.<\/p>\n\n\n\n
Oh noes. The vendor, product, manufacturer name, and everything are all identical! What do we do? Those of you who’ve done this before, I know what you’re about to say. “Use the serial number in the VBox USB Filter, dumbass!” To that I say, “did you read the title of this post?” <\/p>\n\n\n\n
Yeah. This particular vendor rolled out this product commercially with generic, identical serial numbers. Whatever fucktard made that decision, I curse their existence.<\/p>\n\n\n\n
After a bit of futzing, we found that we could filter on “Port”, which is the port number assigned to the device, visible in lsusb and in the device in. \/dev\/bus\/usb\/001\/###.<\/p>\n\n\n\n
So yeah, we got on with our day and forgot about it. Oh yeah — then we got another one.
“No problem,” I said, “we know how to handle that.” So we’re working through setup, and I have the filter in place, and we pull it out and put it back in for whatever reason, and the filter’s not kicking in. I look again, and the port number has incremented!<\/p>\n\n\n\n
Yeah. USB port numbers in linux, at least in this distro, are dynamic. So you can’t expect them to continue to work after a server reboot, or maybe even after a device reset. Bad news.<\/p>\n\n\n\n
So a colleague sends me an article on using udev rules to find the uniqueness buried in udevadm attributes to generate a named symlink to the device. That sounds awesome.<\/p>\n\n\n\n
Well, less than awesome. The only uniqueness I was able to find in the attributes was “bus” and “devpath”, which are the physical USB bus and port the device is connected to. The lovely non-unique serial number is in there glaring at me triumphantly with its useless stupid face.<\/p>\n\n\n\n
So I futzed around with udev rules, trying to get that symlink to come up, and haven’t figured out quite the magic words yet. Maybe because the article is based on a ttyACM device that’s directly in \/dev, and my particular situation involves a device that shows up way under \/dev\/bus\/usb\/001\/### instead. In any case, I see no evidence of a symlink being created anywhere in the \/dev tree, and I have no way of knowing whether it would be usable in VBox USB filtering even if it did show up. So I’m calling it a night, and I’ll put fresh eyes on it tomorrow maybe.<\/p>\n\n\n\n
That’s my day, how’s youres?<\/p>\n","protected":false},"excerpt":{"rendered":"
I generally prefer to blog when I’ve solved an obscure problem, or even a not-so-obscure problem, because I’m proud of myself for doing it, and because for everyone out there … <\/p>\n