If you’ve been following along from home, you’ll know that I’m building the pieces of a customer-presence-sensitive music system for restaurants. Part of this system is a Bluetooth device discovery system that looks for Bluetooth devices – phones, laptops, etc. – of registered customers, and uses their presence as a trigger to adjust the restaurant playlist.
The Bluetooth discovery server that I’m using for testing is a stock Mac Mini, running a modified version of haraldscan, a Python application. The server has been in place for a week for testing the “Bluetooth environment” and the script itself has been working well.
Except that every 12 hours the Mac Mini has been crashing. Or, rather, the scan process has been hanging.
At first I thought it was simply the Mac Mini going to sleep, or being turned off on a power bar, but I realized that the server itself was still alive, it just wasn’t running my process via launchd every minute as I’d set it up to do.
It was only when I logged in to the server itself and looked at the list of running processes that I learned the cause of the problem: there were hundreds of processes running like this:
.../BluetoothUIServer.app/Contents/MacOS/BluetoothUIServer \ -pair XX-XX-XX-XX-XX
And when I looked on the terminal screen, I saw the evidence of this: hundreds of dialog boxes from a device trying to pair:
These pairing requests were eventually bogging down the server to the point where it could no longer run new processes, effectively bringing the server to its knees.
I tried dealing with this in the usual ways: turned off the “discoverable” setting in the Mac Mini’s Bluetooth settings, and unchecking all the other settings that would allow the Mac Mini to automatically react to new devices. But to no avail.
Next I decided to try to find out what the mysterious device “6441” actually was. Originally I thought it was a Panasonic cordless phone, but then I used this helpful Bluetooth Device Address Lookup tool, which identified the device as being made by Ingenico, a name I recognized from debit and credit card terminals.
Sure enough, the mysterious “6441” was a Moneris 8200 pay-at-table terminal in the restaurant. So all I needed to do was to prevent it from making pairing requests, and the problem would be solved.
Unfortunately, after 3 calls to 3 different technical support agents at Moneris, I came to learn that this isn’t possible. There is, it seems, no way to prevent a Moneris 8200 terminal from trying to pair with any discoverable Bluetooth device within range: the only suggestions Moneris could offer were to either turn off Blueotooth on the Mac Mini or to move it out of range of the 8200, neither of which is feasible.
So I decided to approach the problem from the other end: I simply inserted this bit of code into the launchd script that runs the Bluetooth scanner on the Mac Mini:
killall BluetoothUIServer
This has the effect of killing any pairing request dialogs that have popped up in the minute since the process last run, effectively removing the constant pairing request issue an annoyance, but not a system-crippling problem.
I welcome any advice from others on alternative approaches to this.
Comments
Hey,are you doing service
Hey,
are you doing service scans on devices or is does the Moneris have a unknown Vendor?
I have run across deviced that attempt to pair while doing a service scan, but never just a discovery scan.
—Terence
Ah, perhaps this is the issue
Ah, perhaps this is the issue! I am, indeed, doing a service scan. Perhaps it’s the service scan that’s causing the Moneris terminal to initiate a pairing request? I’ll do some experimenting to find out. Thanks.
Oh my god! I’m going to die
Oh my god! I’m going to die if I don’t get the bluetooth pairing request stopped for my mac! Unchecked discoverable and all the other options in bluetooth preferences. Please help me!!! It’s a motorola bluetooth headset.
Add new comment