none
Rerouting bluetooth traffic RRS feed

  • Question

  • Hi,

    I have 3rd party application on one computer (Comp A) that communicates with a 3rd party device via a bluetooth dongle. I would like to connect the 3rd party device to a different computer (comp B) by a means of a physical dongle attached to comp B, and reroute or clone the traffic or stream from the application on comp A, via TCP/IP, to  the bluetooth dongle in computer B. Then re-transmit the stream to this dongle. In other words, I'm interested in establishing a virtual link between comp A and the bluetooth dongle in Comp B, such that any application on comp A will be invisible to the change. Note that I'm not interested in decoding the packet contents, but rather have a 1-1 copy or transfer the packets.

    What would be the best option to do so?

    I thought of two options:

    1) create a virtual bluetooth dongle, configure the 3rd party application to use this dongle, and then transmit the bit-stream that is sent by this dongle to the different computer. Two difficulties in this case: How to I get the source code of a generic bluetooth dongle radio, and how do I keep the other bluetooth devices functioning. Do I need some wrapper rather than a driver?

    2) Somehow clone or sniff the packets that are sent to the virtual driver and resend them by means of TCP/IP protocol to another computer. Any suggestion how to write an application that does that?

    First, What would you recommended me to do? What building blocks are available (e.g, the virtual bluetooth windows driver)? I would be very helpful if you can send me some links/tips that will help in performing this task.

    Finally, how long do you think it would take me, a beginner-intermediate programmer, to create this application?

    Thanks ahead!


    Wednesday, January 22, 2014 1:25 PM

Answers

  • There are virtual USB over tcp solutions in the market, I would suggest considering any one of them first. This is not a simple project for a beginner. If you want to remote Bluetooth audio, it becomes much more difficult to accomplish since you are now dealing with sco and isoch USB traffic

    spec on the USB dongle: this is a standard, published by the Bluetooth org in the H section of the spec

    on the host side you would write a virtual bthport miniport that sends packets over the wire. On the remote side a filter below bthusb that sends thebpackrts, but is stateful enough to understand the hci credit count, not at all simple

    .


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, January 22, 2014 3:12 PM

All replies

  • There are virtual USB over tcp solutions in the market, I would suggest considering any one of them first. This is not a simple project for a beginner. If you want to remote Bluetooth audio, it becomes much more difficult to accomplish since you are now dealing with sco and isoch USB traffic

    spec on the USB dongle: this is a standard, published by the Bluetooth org in the H section of the spec

    on the host side you would write a virtual bthport miniport that sends packets over the wire. On the remote side a filter below bthusb that sends thebpackrts, but is stateful enough to understand the hci credit count, not at all simple

    .


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, January 22, 2014 3:12 PM
  • Silly question , but presumably you don't have the source to the app?

    If you did, and it uses RFCOMM through sockets, then one could be simplest to have it create an AF_INTERNET, SOCK_STREAM TCP/IP socket to talk to the peer app instead of the AF_BLUETOOTH, SOCK_STREAM RFCOMM socket. And have the peer app would open both sockets and transfer the data between them. Also all the discovery/etc code (WSALookupServiceBegin calls etc) would need to be done in the the peer app and some communication protocol made between the two apps.

    There are likely three bits to the Bluetooth use:

    a) Comms (if RFCOMM, a socket);
    b) Discovery (likely WSALookupServiceBegin etc);
    c) and find radios, handle authentication etc.  (BluetoothFindFirstRadio etc)

    One could intercept the RFCOMM socket creation and put one's own socket in place, but that catches a) only. Or even create a Winsock provider that pretends to be the Bluetooth one. That would catch a) and b), but if the app uses the real API calls it would miss them.

    All depends on what APIs the app uses...


    http://www.alanjmcf.me.uk/ Please follow-up in the newsgroup. If I help, please vote and/or mark the question answered. Available for contract programming.

    Sunday, January 26, 2014 1:45 PM