[Interest] [Bluetooth] Cannot identify the SPP service

Fri Jul 3 17:13:31 CEST 2015

Hi Claudiu,

there might be several reasons here. All of them together may appear as rather random.

1.) It is not unusual that it may take a while until a new device is discovered in the vicinity of your scanning device. Especially devices never seen before may take some time. bluetoothd tends to cache information of already found devices which enables quicker discovery once you had the first glimpse. At the end of the day though there is a radio layer in between the devices. They may not notice each other on the radio layer (out of range, under the table etc.)

2.) When you scan using sdptool you directly interact with the Bluez subsystem in the kernel and potentially with the local SDP server. When you use the Qt API you initially interact with the dbus interface layer in bluetoothd. It in turn will forward the call in siniliar ways you are doing manually with sdptool. I would not rule out that the dbus layer doesn't notice the service scan results when you do a scan via sdptool.

3.) There is a chance that your scan is filtering the wrong thing (based on your log below this doesn't seem to be the case here though). A service can be identified by its service (class) id and the protocol descriptor list (& its list of uuids). After all the SPP uuid 0x1101 can act as service uuid and protocol uuid. If you use a qt example they usually use a custom uuid as service uuid and only add the SPP uuid as protocol descriptor to the SDP record. If your discovering device only filters by service uuid and not protocol descriptor uuid you may simply not notice it. Different platforms have differing matching patterns.

4.) Last but not least it might be a bug. Although I have no trouble picking it up on my Fedora 22 (bluez 5.29). In such a case I would need a bit more info posted to bugreports.qt.io. We have had bugs in the past and I am certain we have more. Note that QtBluetooth forwards full discoveries to an external tool called sdptool which circumvents the dbus layer too (like sdptool). It should pick up the same things. Unfortunately its output is base64 encoded. I might just add a debug mode where it prints clear output for debugging purposes. The Minimal discovery uses the dbus layer and here you could debug it using qdbusviewer and inspecting the relevant objects (iface: org.bluez.Device1, in particular its "UUIDs" property).

--
Alex

________________________________________
From: Claudiu Olteanu <olteanu.claudiu at ymail.com>
Sent: Thursday, July 2, 2015 20:07
To: interest at qt-project.org
Cc: Blasche Alexander; Thiago Macieira
Subject: [Bluetooth] Cannot identify the SPP service

Hi there,

I encountered some problems when I tried to connect to a specific service (Serial Port Profile) on a Bluetooth device.
Apparently it cannot identify the service.  Here you can find some logs:

qt.bluetooth: Starting discovery
qt.bluetooth: UUID filter ("{00001101-0000-1000-8000-00805f9b34fb}")
qt.bluetooth.bluez: Discovery on:  "00:12:6F:2A:0B:6E" Mode: 1
qt.bluetooth: Socket discovery finished
qt.bluetooth: Didn't find any

Initially I thought that maybe there is a problem with the implementation of connectToService method.
Therefore I decided to use the QBluetoothServiceDiscoveryAgent to list all the available services. I was surprised to see that when I do a FullDescovery I cannot identify any service for this device.

When I use the sdptool to interrogate the SDP servers I can see the SPP service.

claudiu at linux-qpot:~> sdptool -i hci0 records 00:12:6F:2A:0B:6E
Service Name: SPP
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100

You can find at the end of the e-mail the HCI events captured during both scannings. I couldn't see anything wrong.
The same thing happens randomly when I use a different remote Bluetooth device which exposes only the SPP service. There are moments when it can discover the service and moments when the scanning ends with no results. I couldn't see a pattern.

Details about my environment:
- OS: openSUSE 13.2 (Harlequin) (x86_64) - KDE
- Qt 5.5 (beta version)
- BlueZ 5.30
- Remote Bluetooth Devices: HW (HeinrichsWeikamp) OSTC sport, HW OSTC 2

Also I asked a friend to do the Qt SDP search and he has the same problem. The SPP service is never identified. Details about his environment:
- OS: Fedora 22
- Qt 5.4.1
- BlueZ 5.28
- Remote Bluetooth Device: Shearwater Petrel 2

The interesting thing is that when I search for SDP servers exposed by my smartphone I can always discover them, but it doesn't expose a Serial Port Profile.

Regards,
Claudiu

--- SDP scanning using the QT Bluetooth API ----
claudiu at linux-qpot:~> hcidump
HCI sniffer - Bluetooth packet analyzer ver 5.30
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 37 bdaddr 00:12:6F:2A:0B:6E type ACL encrypt 0x00
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
> HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 37
    Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 37 page 1 max 0
    Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:12:6F:2A:0B:6E name 'OSTCs 0892'
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 37 reason 0x16
    Reason: Connection Terminated by Local Host

--- SDP scanning using the sdptool ----
claudiu at linux-qpot:~> hcidump
HCI sniffer - Bluetooth packet analyzer ver 5.30
device: hci0 snap_len: 1500 filter: 0xffffffffffffffff
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 34 bdaddr 00:12:6F:2A:0B:6E type ACL encrypt 0x00
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
> HCI Event: Command Status (0x0f) plen 4
    Unknown (0x00|0x0000) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
    status 0x00 handle 34
    Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x59 0x87
> HCI Event: Command Status (0x0f) plen 4
    Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Read Remote Extended Features (0x23) plen 13
    status 0x00 handle 34 page 1 max 0
    Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
> HCI Event: Command Status (0x0f) plen 4
    Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Remote Name Req Complete (0x07) plen 255
    status 0x00 bdaddr 00:12:6F:2A:0B:6E name 'OSTCs 0892'
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 34 reason 0x16
    Reason: Connection Terminated by Local Host