I just miss the dual mode HID/HCI bluetooth adapters.
replies(2):
Why? My friend needed a way to use his Bluetooth mouse and keyboard on a PC with Bluetooth disabled due to policy restrictions. This tool acts as a bridge, relaying Bluetooth input over USB. It also lets you use Bluetooth peripherals with older devices that only support USB input.
Tech: Written in Go, optimized for Raspberry Pi Zero W.
I love HN’s community and often lurk here—I’m hoping this project is useful or at least sparks some interesting discussions. Feedback and contributions are welcome!
Out of curiosity, do you think this concept could be extended to other common bluetooth use cases, such as wireless headphones/speakers, or file transfers over bluetooth to mobile devices, or are the audio/file transfer/etc stacks too far removed from the HID stack for that to cleanly translate?
Once the operating system finished loading, it would send the adapter the command to switch to HCI mode, and the adapter would then re-appear as a normal bluetooth adapter. Under BlueZ, this operation was done by a command called hid2hci.
I have several (even Apple used to do this), but they stopped being a thing during the 2.0 EDR era (therefore zero support for LE keyboards).
In fact, if you google these keywords ("HID proxy", "HID2HCI", ...) you will find that there are several much older projects to also replicate this using RPi Zeros. I personally would like one which extends the concept to audio devices, serial ports, etc. so that I can use them from OSes without BT stack.
Great question. I can see this being fairly easily extendable to other HID devices and even modifying their behaviour slightly (e.g. remapping a key) but audio stack sounds like (no pun intended) a different beast altogether. A buddy of mine had a similar question around connecting his BT gamepad and headset to play PS games on PC so I'll be looking into this more.
e.g. https://www.aliexpress.com/item/33010159305.html?spm=a2g0o.p...
I think that's a fair point about potentially wasted resources, something like Pico would have been and a leaner choice if this was going to be mass-produced. But for me, part of the decision was my comfort level with system programming and what I desired to tinker with and learn along the way and still, it's a very affordable option (around 20 CAD I believe)
Perhaps I'll look into porting it to Pico in future as new challenge and learning experience. Thank you for your sharing your thoughts.
If you still want to DIY, an ESP32 (BLE and Wi-Fi capable microcontroller) board, and an RS232 to logic-level breakout board should be all you need. Again, I'm sure if you search, you'll find existing projects doing exactly this.
If it's not actually at RS232 voltage levels and Classic Bluetooth is enough, then something like this will work just fine: https://www.amazon.com/Wireless-Bluetooth-Transceiver-Integr...
I would say the most complicated part would be the TCP/IP stack, and binding/publishing your address, but if you are running something with Embedded Linux it is doable :)
What a cool little project. I might build a couple of these for the KVMs at work.
Protip: If their company's IT section is like the one at my old company, they are quite unlikely to like this solution, either.
But it's very clever. Kudos.
Another thought around this is that I don't even think there's anything intrinsically insecure about BT as an attack vector but most likely some old policy based on security issues that existed in the early days of Bluetooth. Or at least I don't know of any, but I'm no expert in this so I would love to hear other people's insights here.
It sucked. Big time, but they had the clout.
Great work Bahador.
Remote work at startups has largely removed my need for this kind of behavior. Now I'm mostly just mad that I can't always run Linux at work anymore.
Would this work? I’d buy one. I currently have to use Synergy to share peripherals between two MacBooks.
Well.
Other departments ask for equipment, but only hear no back. Management product like Monday? No. Dedicated solution for jobs they don't understand? Hell no!
It's tough to be part of this. I know security is hard. Budget limit stuff. But we can, and should do better.
Same here, though I've never been in a significantly restrictive place with no authority (in current long-term DayJob I have some involvement in decisions wrt what restrictions are appropriate, and what exceptions to them are appropriate).
If someone is in a truly restrictive environment, they should take care. A deliberate breach of policy could be a job terminating excuse, or at least further justification, if someone wants them out of the way for any other reason, and in such circumstances a workaround and a breach will be seen in the same light.
Quite probably, though there might be protocol latency issues that you need to be careful of and they might limit the effective range (lookup the “We can't send mail more than 500 miles” tale for a related issue!).
My company's IT department is Windows clickops people who hire other Windows clickops people. When something goes wrong that requires the command line, they spend five figures on a consultant to fix it. Ditto for the few dozen Linux machines in the company.
Some of our departments, including mine, run Macs. I can't count the number of times I've had someone from IT tell me "OK, now click 'Start'…" or whatever the Windows convention is these days.
All they'd have to do is hire one guy who knows the command line, and one guy who knows how to support Macs. There must be a hundred people in the IT department, but they keep hiring the same type of people over and over.
I wish it was unique to my company, but there was an identical situation where I worked a few years ago.
Wired connections are inherently more difficult to attack. In security critical applications banning bluetooth is perfectly reasonable.
The best way to correctly fight Shadow IT is to provide equipment and services so good nobody would even care using something else.
I once plugged my personal phone into the USB port of a random machine in the office to get a quick charge, and a guy from Information Security showed up in under ten minutes ready to have a heart attack.
Some people will always want to bring their own equipment, but a lot of it is caused by penny pinching or lack of options
I gotta test how this works with the Magic Trackpad. IIUC Magic Trackpad does something non standard to achieve smooth scroll.
Also: if you work with certain customer data a good way to not only loose your job, but a ton of money would be to e.g. put that data into your shadow IT that might be running on some servers somewhere. E.g. people constantly asked us to use Zoom "because it is free and works", but we were in the public sector and a contract with them that guaruantueed the privacy of our clients would have costed a significant fraction of our yearly IT budget — and we are required by law to have such a contract.
When you then ask those people if they want to part with that money suddenly nobody is so adamant anymore.
One annoyance is that macOS automatically Bluetooth pairs with these devices when connected via USB, overwriting any existing pairing, but this shouldn't matter for purely wired scenarios.
For switching Bluetooth devices more generally, observe that most Bluetooth controllers are USB devices; with a bit of effort — mostly just copy/pasting the device pairing keys across all connected hosts — they can be switched just like any other USB peripheral (YMMV with "intelligent" USB KVM switches that virtualize USB HID device connections).
IME the connection delay is a couple seconds longer than switching wired USB HID devices directly, but entirely reasonable for typical KVM use cases.
Note here that "most Bluetooth controllers are USB devices" even extends to internal Wi-Fi/Bluetooth combo cards, which are commonly M.2 key A or E (= PCIe + USB 2.0 + …), or M.2 key A or E preinstalled on a mostly passive PCIe adapter, with a separate cable connection to a USB port or motherboard USB header used exclusively for Bluetooth.
This turns out to be a surprisingly useful implementation detail: on one of my work desktops, I'm currently virtual USB-switching the Bluetooth controller on an Intel BE200 PCIe card between a Linux host and a Windows VM running on that host, while keeping Wi-Fi connected to the host.
I have a matching hot key set up in each OS to attach/detach the Bluetooth controller from the VM and simultaneously DDC switch the monitor input between the host (iGPU) and guest (PCIe dGPU passthrough), and it works great.
Coincidentally, the Bluetooth devices I'm using in this configuration are a Magic Trackpad 2, a Magic Keyboard, and a Magic Mouse (the mouse was the motivation for using Bluetooth over USB in the first place, as, unlike the other Apple input devices, it's physically impossible to use when connected via USB).
This has been impossible so far, because even USB bluetooth dongles still require each host computer to pair (and un-pair) with the keyboard/mouse.
I am going to try your solution, and I will plug the USB input into the large monitor on my desk. Then any laptop that plugs into that monitor should have access to the wireless keyboard/mouse. Thank you for creating and sharing this!
Throwing more complexity at a simple problem might be "fun" from a nerd's POV, and, TBH, building this USB device sounds fun. But entirely unneeded while introducing more points of failure.
A simple solution to your problem:
1. Get a monitor with a built-in USB hub (nearly all of them?). Consider getting a USB-C monitor to reduce the number of cables to 1.
2. Don't use Bluetooth (for a keyboard, for multiple reasons, like needing the keyboard available in early boot). Get a keyboard/mouse with an external USB dongle like Logitech's Unify or Bolt, Corsair's SLIPSTREAM, or any of the other billion options that exist.
3. Plug keyboard/mouse into monitor, plug random computers into monitor. Bam. Unified mouse and keyboard without any pairing.
One popular request I’ve received is for certain RPi models (those with multiple USB ports as host) to act as a KVM, allowing them to serve as a USB host for multiple PCs simultaneously with easy switching—perhaps through shortcuts or physical buttons on the RPi. I’ll need to give it more thought, but it seems feasible with minimal changes. I already have some ideas for better state management for the devices!
This was especially true for memory sticks, but keyboards, and even bus-powered things like fans (or nerf turrets) would get banned.
They had the power to get you fired, if you crossed them.
They did not like my team, because we were the only ones in the building, that knew what bullshitters they were.
We had all kinds of scary tech, like custom-compiled metrics software from Intel.
They insisted that all of our machines run their malwa- er, security software.
It would totally screw up our measurements.
My current keyboard:
https://www.logitech.com/en-us/products/keyboards/mx-mechani...
It quickly grows past the 2-3 sanctioned models. Everyone wants something not on the list, lots of bickering of "why was that model chosen?", etc. Well that pre-approved model is $150, this is only $175. Bob got that $175 model, this is only $200, it's not that much. Jenny got that $200 model, this is only $250. Jenny's got a $250 keyboard? I gotta upgrade, here's this $300 model... Wait did the company just buy Bill a 55" 4K display? I need that too...
Suddenly your $150/person budget has exploded to replace everyone's equipment for $1,000+ otherwise it's just not fair someone else got more.
Personally I'm fine with me buying and owning my own kb+m. Maybe give a once a year or two office hardware stipend or whatever. Then otherwise make basic stuff available for free. If you're wanting a $200 keyboard you're probably wanting a particular $200 keyboard, and it's probably not one of those 2-3 approved models.
All because you're offended by the complexity of... what?
• The idea of a device that acts as a stable host for Bluetooth devices, while presenting as a wired USB hub to an upstream USB host controller?
• The particular implementation here, which is a hacky proof-of-concept of the idea (and which could, in practice, be reduced to a single chip embedded into any USB-C-dock product if there was demand)?
• The entire concept of Bluetooth?
---
Also, I would like to point out that, given that this is HN, it's more than even odds that the GP:
• likely has multiple monitors (so using a monitor with a built-in hub is likely untenable);
• and also, that their laptops are probably Macbooks, and their mouse and keyboard are therefore very likely a Magic Keyboard and Magic Trackpad [for which there is no 1:1 substitute that does non-Bluetooth wireless while still having the same level of macOS support/integration];
• and that, given what they've said, they're likely already using a Thunderbolt hub to talk to those multiple monitors + all their USB devices through "one cable" (and all they really want is to add one more USB connection to this dock to make it act like a "Bluetooth dock" too);
• and that they likely have a big deep sit-stand desk, that they'd be cluttering/making it hard to put things on the 90% of the free "middle space" on, if they had to run actual wires from the keyboard and mouse over to the dock.
I think the technique would be: pair in machine A (A has a link key). Then, pair again in machine B with the same dongle. Write that key into NVRAM, and machine A considers the device paired but it never gets asked for the key so just works if you plug the dongle into either machine. I don't know how the monitor thing works, does it act as a USB hub? I guess you can just leave the Bluetooth dongle plugged in there..
My point was more general: I see a lot of things getting built using Linux that really have no need for this level of complexity. And it doesn't come free: complex systems are more fragile, there are more things that can go wrong.
In this particular case, I'd recommend taking a look (for example) at the Seeed XIAO nRF52840 module and Zephyr: around $10, very capable CPU, very good Bluetooth stack (Zephyr+Nordic), USB-C connector.
I'm assuming this also works with Pi Zero 2 W? (The repo only mention the original Zero W)
I've always wondered how feasible it would be to copy Bluetooth pairing information. This particular series of hacks seems to rest at least somewhat on it being the same Bluetooth host adapter. (But maybe the host side can spoof, trade IDs with the other device?)
Ideally I'd love to centrally and dynically manage what devices of mine are paired with what system... I think that might be technically feasible, as long as I'm not trying to pair multiple things with a single bt adapter.
https://gist.github.com/madkoding/f3cfd3742546d5c99131fd19ca...
> Note that while this component is named bluetooth_proxy, only BLE devices (and their Home Assistant integrations) are supported.
One specific use-case I have in mind is controlling a Chromecast over the internet. So a smartphone should have its bluetooth signal relayed over an IP network. I haven’t found anything that would allow me to do that yet.
https://www.raspberrypi.com/products/raspberry-pi-zero-2-w/ https://www.raspberrypi.com/products/raspberry-pi-zero-w/
I can't find definitive information for RPi 4 though, I see some references to using it online but the spec here does not seem to mention USB host or OTG
https://www.raspberrypi.com/products/raspberry-pi-4-model-b/...