Bluetooth: Correlate random address and public address RRS feed

  • Question

  • When a Bluetooth device is using a public address (for paring) and a random address (for advertisement) at the same time, is there a way to correlate these addresses?  In other words, if I receive an advertisement with a random address, is there a way to determine if it's from one of the paired device?

    Saturday, April 28, 2018 6:30 AM


  • Hey Happy Dawg,

    #2a Is the question is do we APIs to support BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H | Out of band, in our current APIs, we do not, you can see it's missing from the list of pairing kinds.  It's not in our backlog yet if you file Feedback Hub feedback and share the link, I'll promote it to a backlog item. Then we can collect a business case for prioritizing correctly and you'll know when it's completed.

    #2b Yes that item is in our backlog also as 'Support L2Cap via WinSock', we'd like to get to this soon, but need more takers. Please file Feedback Hub feedback and share the link, I'll attach it to the existing item, and we'll reach out for business case.  Did you also want 'LE L2CAP Connection Oriented Channels' with it it, others have given feedback they'd like both? Again, we'd need business case information to justify the work.

    Friday, September 6, 2019 5:45 PM

All replies

  • Hmmm... no response for a year and a half...  let's wake this up again.

    Let's change the wording:

    Since we need a way to have two BLE devices (one ioT in Central mode, the other Windows in peripheral mode) wake up and talk to each other time and time again, WHAT methods can we use to accomplish this in the face of Windows insisting that ONLY random addresses will be used to maintain security for Windows?

    Tuesday, August 27, 2019 6:34 PM
  • Hey Happy Dawg,

    For a paired device, we'll resolve the address internally using the IRK and you should get the address first used. If the device is unpaired, it's by design that one cannot tell it's the same device from the advertisement. It's pointed out this is a design goal on page 16 of Robin's book (Bluetooth Low Energy: The Developer's Handbook) and more detail later.

    Can you provide more details on the scenario? Perhaps we can suggest a design that enables privacy and your scenario.



    Wednesday, September 4, 2019 5:00 PM
  • An ioT device operating in Central mode needs to be able to awaken from complete dormancy, connect to a workstation operating in Peripheral mode, upload its data, then disconnect and return to complete dormancy.  The total time to connect, upload and disconnect is preferably 0.5 seconds, max 2 seconds.  We are currently within this window, but are still concerned about having the GattServer open to attacks 24x7, and have created a home-brewed method to deal with that area.  We would prefer to put our ioT devices on a whitelist during a pairing process with the workstation, and let the workstation reject all connection requests that are not on the whitelist. We do not use UWP, and plan on remaining with BTFramework's much simpler, and so far, more trustworthy long-term, Bluetooth library that interfaces with yours.  After dissecting your broadcast packets, I believe I understand better how you decided to implement the parts you have chosen to implement.  How do we pair our ioT device once to our application on the workstation, and never have to worry about addresses again?  That I haven't found in documentation.

    Wednesday, September 4, 2019 5:29 PM
  • Happy Dawg,

    The scanning device is the typically the most power intensive operation, and the peripheral is the device that is designed to conserve power, this is why for mouse and PC, the PC is Central and the mouse is Peripheral. This way the mouse will advertise as connectable only when there is data to send, the host will be scanning to connect (more power intensive) and connect. The peripheral will then use notifications / indications to send the data.  Adopting this a pattern will likely improve the performance of your solution.

    However, if you want the IoT device to be central, and our host to be peripheral after you start advertising we'll be discover-able and the Central can initiate pairing, you'll see an inbound toast, or notification if using Windows Device Portal of the pairing request.  You can simulate this with two Windows PCs (assuming one supports Peripheral Role) using Bluetooth LE Explorer.

    I am curious why you believe another layer of software (BTFramework) overlayed on our own software is more reliable can you provide some details on this? It seems unusually that a something that consumes our APIs could be more reliable than the API it's consuming.



    Wednesday, September 4, 2019 5:57 PM
  • Let's see the issues we now have to discuss.

    One --- old business. Can we increase the size of the MTU on the GattServer side, if we continue using that route?  Say, 250 bytes?

    Two --- BTFramework has maintained their API and isolates us from the ever-changing Microsoft world of partial Bluetooth implementations.  We have worked with Bluetooth on XP, even Vista, Windows7, Windows10, and have been very happy when your new releases caught up in dribs and drabs with the rest of the Bluetooth world, because the team at BTFramework has always jumped on those new features immediately and surfaced them to us in a much, much simpler manner.  And they rapidly fix bugs OR deliver workarounds to defects in your code whereas it would take months (or never) waiting for Microsoft to respond to bug reports. If you would like, I could probably obtain their wish list of things they wish would be fixed or surfaced... just let me know.  

    Three - power consumption. I must reconsider. We consume 5mA listening, and 9mA transmitting.  I'll re-evaluate what passive discovery mode consumes versus the advertising mode.  I also have to balance memory consumption (putting both central role and peripheral role in one ioT) when we are bumping up against ceilings at the moment.

    Four- architecture.  To paraphrase, you are saying one BLE Central on the workstation can (a) continually scan for (discover) any one of multiple previously-paired peripherals that are first OFF, then which start advertising, then (b) instantly (yes, subject to cycle times) reaching out and connecting to the peripheral (with (c) the Central at that point terminating its discovery process - which termination process has, if I recall, some behavior problems at times), then (d) writing to the peripheral to tell it to upload via the notification/indication method, then (e) confirming the transmission, then having the peripheral disconnect and return to OFF, with the Central (f) immediately recognizing the disconnect and (g) re-launching the discovery process to work with the next peripheral that starts advertising.  If that is how you are proposing it, and if all of that is functional with current software, then the only remaining problem I have is the reliability issue. Reliability (see below), and also a connection count issue.  How many peripherals can the workstation Central support?  We normally have only two or three, but can have as many as twelve per site.

    Reliability - I have experienced unexplained delays of five to fifteen minutes when an asynchronous service enumeration request just sort of went off the deep end... eventually completing, of course, it just takes its time doing so.  The application becomes nonresponsive, even taking the Bluetooth radio off the air if I terminate the app.  I don't know of a way to implement a deadman's switch to terminate that one enumeration request.  If I knew what caused that behavior perhaps I could shoot it.  But I am wary of any API that behaves in that manner, even if only once in ten times, when the documents that are available don't go deep into the details.

    Wednesday, September 4, 2019 7:08 PM
  • Happy Dawg,

    #1 I believe we indicate a preference of 527 for the ATT MTU, have you looked at a snoop log to see which side is declaring the lower value? Do you have a trace of using a value below 527?

    #2 I would love specifics about what issues they've had to work around, and traces if possible. I've only been on the Bluetooth team during Windows 10 so I don't have experience before that.

    #3 Yes transmitting temporarily requires more power, but it's for a shorter time, if you look at the net consumption over time it will be less. All these fitness trackers, asset trackers and mice use this strategy successfully.

    #4 The spec section LE piconet channel explains this well, basically there is relatively no limit on devices in piconet and it uses multiplexing to participate in multiple piconets.  There is no Windows specific limits for bearers beyond the spec and the radios.

    #5 What does the snoop log show when you have delays on discovering services, I am assuming you're in central role in that case, and we are attempting to connect to the peripheral role device. This means we need to see the advertisement indicating it's connectable, then connect, then complete service discovery.  Do you have a trace of this taking many minutes to investigate?

    Wednesday, September 4, 2019 7:57 PM
  • On item #1, I think that when I researched this point before, the recommendation from Microsoft was to plan to have a transmission packet broken into a series of 37-byte messages - because the MTU was not accessible to end user developers.   Apparently that was never true, or not true now.  Either way, good!

    Item #2 --- requested.  

    Item #3, we may have a cause and effect situation. A mfr of a fitness tracker built a product at a time when the peripheral mode was their only option --- and not the result of a decision involving power consumption. A coin cell battery could operate a microprocessor without needing power booster chips, could go into sleep mode at an acceptably low power level, and the battery would last a couple of years, whether it was listening to advertisements and deciding what to connect to, or transmitting those advertisements awaiting a connection.  The workstation peripheral functionality was perfected long after workstation central mode functionality.  I seem to recall that basically all Bluetooth radio vendors brought out USB dongles that supported the BLE central mode aspect, but very few (I know of two vendors, only one of which is currently active) offered devices that supported the peripheral role.  And smartphones went through the same sequence. My research on this topic some time ago indicated some smartphones supported it, then subsequently dropped it. 

    Still, I am all ears --- do you have your hands on power consumption studies that look at that issue? Every microAmp, nanoAmp and even picoAmp matters a great deal to us.  We have more stringent requirements than a relatively power-hungry fitness tracker.

    Item #4. Where do I read in detail about how Microsoft implemented that LE piconet spec, and what limitations exist? I missed that Microsoft  documentation in my research, and would enjoy reading it. So one peripheral (and a few dozen other peripheral devices) can each simultaneously "belong" to four central clients residing on one workstation... and each of those central clients can "share" those few dozen peripheral devices all talking at once to the one Microsoft workstation.  Which by extension means that if each peripheral device is smart enough, then each peripheral device can be "owned" by four central clients that are actually located separately on different workstations. Truly no limits. Powerful !

    Item #5. I don't have access to a full tool like that. I use a BLE sniffer with fewer abilities.   <sniff>

    Wednesday, September 4, 2019 10:42 PM
  • Frank,

    Following up on item 2, the list of defects and desired features for BLE, it is in the works.  I am asking for some detailed explanation from the BTFramework team, so do you want it posted here, or should I send it directly to you?

    New items, #6 and then #7.  I see from running multiple GattServers on a workstation that Microsoft treats all broadcasted services as being offered by the workstation, rather than being offered by an application residing on a workstation. (#6a) I have to guess that architecture must use a single master table instead of separate tables, one per application, that would have allowed each application and its ioT audience to operate independently of other applications and their ioT audiences.  Now, apparently, each application and its ioT audience are all forced to deal with the realities of a non-virtualized, smushed-together BLE world on a Microsoft workstation.  (#6b) So is it true that once I, using a sneaky ioT device, gain access to the workstation, I have 100% full undefended access to ALL of the surface areas of those multiple applications on the workstation?  Makes me want to write a hacking program and post it just to let others enjoy what they can do with that.  (#6c) From another viewpoint, is it true that when a sneaky ioT device wants access to MY secure application, all it has to do is to first gain access to the workstation by convincing some consumer to download a sneaky app, pair to the workstation, and voila! it can see all services and all characteristics of all other applications on that workstation, including mine, even though there is no way we would have approved that app to see any of our information?

    (#6d) To deal with this security exposure: What will it take to provide an OnConnectRequest event my GattServer can use to prevent the connection attempt to all of the services my application offers?  Or if that is truly impossible, then to provide an OnServiceEnumerationRequest? I have this already installed on our ioT devices.  Suspect apps are stopped before they gain access to and can enumerate our services and characteristics. When will I be able to do this on something as intelligent as a Microsoft workstation? Stopping access this late in the process is probably a lost cause --- once a hacking app gains access to the workstation, it can just brute force the rest of the process and jam up the works.

    #7a - Back to the single master table architecture in Microsoft's implementation.  This results in an application's service handles and their characteristic handles being dynamically assigned relative to the workstation's master list of services and characteristics, rather than relative to the application and its proprietary services and characteristics and their handles (that on a Microsoft product are now no longer under the app's full control).  As with dynamically changing the advertised address of the radio every 15 minutes or so, this dynamically changes the characteristic handles every time the workstation reboots and applications are relaunched in whatever sequence may occur.   This means that any memorized handles saved by the ioT to save time in the future are now of no value --- meaning the ioT device must re-enumerate the service and characteristics every single time it connects to the workstation. This morning, service 0xFFF1 might have a handle of 1C, and its first characteristic a handle of 1E.  This afternoon, after a bootup, that service handle might be 3D and the first characteristic handle of 3F.  (#7b opinion) Guys, these are not Windows handles that reflect a rapidly changing environment and therefore need to remain Windows handles.  These are handles that belong to and are engineered by the application, should be under its control only, and the application handle is what rightly belongs to Windows.

    (#7c) - Is this documented anywhere?  Please provide a link to that publicly available document.  It is an architectural decision that is far from obvious.  

    (#7d) - Since the services and handles on a Microsoft workstation are subject to spontaneous and random change, can we put some key data into the advertisement to tell the ioT device when this is necessary?  Can you provide sample code to do this in a passive advertising situation?

    Thursday, September 5, 2019 5:31 PM
  • #3 our profiling data is for a confidential project, sorry I cannot share it. However I can tell you it's aligned with others in the eco system where the peripheral ended up using less power then a central.  You can do your own experimentation, or model it. The key is that advertising only needs to happen on send and for a short period, vs scanning.

    #4 Microsoft doesn't implement the piconet the radio does. The spec section is from the Core Specification fro Bluetooth.  Also covered in the spec is the HCI interface so you can see the HCI LE Create Connection and parameters.

    #5 You have access to snoop logs on our host via our logging plus BTETLParse or BTVS (in the WDK) will create a CFA (snoop log) and you can use Wireshark which is free, or other paid tools.

    #6 & #7  A single radio (host) has a single database, and as services change, so do the handles, you can observe this on iOS as well.  The GATT spec explains this and the GATT Caching feature relies on this. This is why there is a service change notification. To partition the database you'd need a radio that's capable of virtualizing itself, or a host with many radios, neither are supported on Windows.  As for the security implications, the link protections are transport level protections, they are not application level protections. It's similar in Bluetooth Mesh, where if you associate to the network you get access to the messages, however there may be application layer protections as well. There are well written applications running across platform (including on Windows) that implement application level protection. It is of course recommended you'd do the same on a multi-application / multi-user host.  The necessity to do this exists across all host OSes, it's not unique to Windows and I'd strongly recommend you include such considerations in your design. A poorly written application can indeed impact a user's privacy there has been research on this before and it's well understood, it's no different then any other service using any other transport to the host, if the endpoint doesn't have authentication beyond the transport itself.

    Thursday, September 5, 2019 5:57 PM
  • Re item#2 from above - from the BTFramework team.


    OOB pairing:

    With OOB pairing remote and local devices exchange pairing information out of Bluetooth band. However, they both should exchange some keys to be able to decrypt pairing data. The first way to do that is to exchange some information using Bluetooth. In this case one device sends OOB pairing request which includes “key” for OOB pairing. The other device receives this “key” and can now check pairing information. This should be provided by Microsoft's OOB pairing (as it is already implemented in the BlueSoleil stack). The other way is to rely on the Bluetooth radio hardware that generates this “key” so local device can query Bluetooth dongle for this “key” data and then it is used in OOB pairing. BlueSoleil provides methods to query the Bluetooth dongle for the “key”. Microsoft should provide a method to do so.

    They provided a link that points to the www -- bluetooth -- com site, Let's see if I can get this past the censor...

    slash blog slash 



    Access to L2CAP in BLE as we already have in Classic:
    This this is very important feature. If we talk about Classic we can implement non-RfComm profiles: HID, AVRCP and a lot of others which are based on L2CAP.

    Friday, September 6, 2019 5:22 PM
  • Hey Happy Dawg,

    #2a Is the question is do we APIs to support BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H | Out of band, in our current APIs, we do not, you can see it's missing from the list of pairing kinds.  It's not in our backlog yet if you file Feedback Hub feedback and share the link, I'll promote it to a backlog item. Then we can collect a business case for prioritizing correctly and you'll know when it's completed.

    #2b Yes that item is in our backlog also as 'Support L2Cap via WinSock', we'd like to get to this soon, but need more takers. Please file Feedback Hub feedback and share the link, I'll attach it to the existing item, and we'll reach out for business case.  Did you also want 'LE L2CAP Connection Oriented Channels' with it it, others have given feedback they'd like both? Again, we'd need business case information to justify the work.

    Friday, September 6, 2019 5:45 PM
  • Thanks, Frank, I think that wraps it up.

    Lot of good feedback -- many, many thanks.

    Friday, September 6, 2019 5:48 PM
  • Thanks Happy Dawg,

    I appreciate your feedback too. I really hope you find success using Windows for your IoT scenario. Please feel free to send me a Linked In invite if you like for my direct contact details.


    Friday, September 6, 2019 5:55 PM
  • Frank,

    Apparently there is a third item from the BTFramework team.  It would explain why I see no events on a laptop GattServer when the workstation GattClient has initiated a pairing attempt, and the attempt times out.  Is it true there is no way for a standard dot NET or Forms (non-UWP) application to access Microsoft's BLE pairing mechanisms?

    Friday, September 6, 2019 11:01 PM
  • Hey Happy Dawg,

    A WinRT API be can be used in a non-UWP app, look for the attribute DualApiPartitionAttribute, if present they can via COM or Cpp/WinRT.  However PairAsync does not have this attribute, so they are correct.

    If you are asking about incoming pairing (as in handling an incoming request) then it can only be done on our IoT edition, as the desktop policy requires user consent.  If you have scenario feedback on this please share.

    Friday, September 6, 2019 11:16 PM
  • Hello Frank,

    Original poster here.  Sorry I've missed your response.

    I'm getting the resolvable private address through advertisement (BluetoothLEAdvertisementWatcher's Received event) and I'd like to check if it's one of the paired device or not.  I believe, in this scenario, Windows doesn't "resolve internally".  Did I miss any option to setup the advertisement watcher?



    Thursday, March 26, 2020 1:50 AM