* Re: btusb_intr_complete returns -EPIPE
From: Oliver Neukum @ 2014-10-15 10:11 UTC (permalink / raw)
To: Alan Stern
Cc: Naveen Kumar Parna, linux-bluetooth@vger.kernel.org, linux-usb,
acho
In-Reply-To: <Pine.LNX.4.44L0.1410091030580.1372-100000@iolanthe.rowland.org>
On Thu, 2014-10-09 at 10:31 -0400, Alan Stern wrote:
> On Thu, 9 Oct 2014, Naveen Kumar Parna wrote:
>
> > Hi Oliver & Alan,
> >
> >
> >
> > Thanks for your inputs.
> >
> >
> >
> > I enabled the dynamic debugging for USB HC driver. Please correct me
> > if I am wrong.
>
> Debugging the kernel (or doing anything else to the kernel, for that
> matter) won't solve the problem if it is caused by a buggy hub.
Indeed. Could you just try a different hub?
Regards
Oliver
^ permalink raw reply
* BT-4.1 features (e.g. concurrent GAP operations) support
From: Min Jun,Xi @ 2014-10-15 7:25 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Where can I find the latest BT-4.1 features support for
Bluetooth-subsystem and BlueZ?
In the 4.1 features, I know connection-oriented channels has been supported;
I have one question about this new feature (Bluetooth Specification
Version 4.1[Vol 3] page 293 of 668, ): "2.2.2.5 Concurrent Operation
in Multiple GAP Roles"; this feature is very useful to support
mesh-like topology,
>From the description in chapter 2.2.2.5, the controller should support
operations in multiple GAP roles concurrently, and the host should
read the supported Link Layer States and State combinations from the
Controller before any procedures or modes are used.
Can anyone tell me if the bluetooth subsystem has supported the Link
Layer states and the States combinations? I am also looking for the
Controller support operations in multiple GAP roles concurrently, can
anyone know if CSR/Nordic/Broadcom has got the USB dongles which
supports concurrent operation and can used under Linux?
Thank you!
--
Best regards,
Xi Minjun
^ permalink raw reply
* Re: Not getting an AVDTP: incoming connect
From: John Tobias @ 2014-10-14 22:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZLK3w+feOuikzWrG4VhsAR7Ky+S7WZpnBOsHJGR_kE+gA@mail.gmail.com>
Hi Luiz,
I was able to reproduce again and here are the logs.
HCI LOGS:
HCI Event: Connect Request (0x04) plen 10
bdaddr 00:1B:DC:07:32:D3 class 0x080418 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:1B:DC:07:32:D3 role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 1 bdaddr 00:1B:DC:07:32:D3 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 1
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:1B:DC:07:32:D3 mode 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 1
Features: 0xff 0xff 0x8f 0x7e 0xd8 0x1f 0x5b 0x87
< HCI Command: Read Remote Extended Features (0x01|0x001c) plen 3
handle 1 page 1
> HCI Event: Command Status (0x0f) plen 4
Read Remote Extended Features (0x01|0x001c) status 0x00 ncmd 1
> HCI Event: Max Slots Change (0x1b) plen 3
handle 1 slots 5
> HCI Event: Read Remote Extended Features (0x23) plen 13
status 0x00 handle 1 page 1 max 1
Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:1B:DC:07:32:D3 mode 2 clkoffset 0x0000
> 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:1B:DC:07:32:D3 name 'PTS-A2DP-WIN-4MP7G5VHB2U'
< HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
> HCI Event: Command Complete (0x0e) plen 10
Read BD ADDR (0x04|0x0009) ncmd 1
status 0x00 bdaddr D0:E7:82:ED:B0:1A
Additionally, I've encounter a scenario where I was able to respond to
the prompt (Confirm passkey 773535 (yes/no):), after entering yes and
enter, the hcidump did not logs any event.
Regards,
john
On Tue, Oct 14, 2014 at 2:51 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi John,
>
> On Tue, Oct 14, 2014 at 3:09 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
>> Hi Marcell / Bluez Team:
>>
>> I was running the PTS 5.2 and there were an occurrences that the bluez
>> did not show a similar message below:
>>
>> [agent] Authorize service 0000110d-0000-1000-8000-00805f9b34fb (yes/no):
>>
>>
>> 1. I logs below are the traces of the bluetoothd not prompting the
>> Authorize service message:
>>
>> t 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
>> connected eir_len 31
>> Oct 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:dev_disconnected() Device 00:1B:DC:07:32:D3
>> disconnected, reason 2
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:adapter_remove_connection()
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> plugins/policy.c:disconnect_cb() reason 2
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:1B:DC:07:32:D3
>> type 0 status 0xe
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/device.c:device_bonding_complete() bonding (nil) status 0x0e
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/device.c:device_bonding_failed() status 14
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:resume_discovery()
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_disconnected
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: setting adv
>> params failed: Operation not permitted
>> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: failed to enable
>> advertising
>>
>>
>> 2. These messages are the traces of the bluetoothd showing the
>> Authorize service message:
>>
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
>> connected eir_len 31
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
>> 00:1B:DC:07:32:D3
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/source.c:source_set_state() State changed
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_DISCONNECTED ->
>> SOURCE_STATE_CONNECTING
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_ref() 0x77a601d0: ref=2
>> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_authorize_service() authorize service request was
>> sent for /org/bluez/hci0/dev_00_1B_DC_07_32_D3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_ref() 0x77a601d0: ref=3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_unref() 0x77a601d0: ref=2
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/agent.c:agent_unref() 0x77a601d0: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected signaling
>> channel to 00:1B:DC:07:32:D3
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP imtu=672, omtu=672
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received DISCOVER_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
>> GET_CAPABILITIES_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:endpoint_getcap_ind() Sink 0x77a69bd8:
>> Get_Capability_Ind
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
>> SET_CONFIGURATION_CMD
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:endpoint_setconf_ind() Sink 0x77a69bd8:
>> Set_Configuration_Ind
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_ref() 0x77a5d040: ref=1
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/media.c:media_endpoint_async_call() Calling
>> SetConfiguration: name = :1.6 path = /MediaEndpoint/A2DPSink
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=2
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
>> IDLE -> CONFIGURED
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_unref() 0x77a5d040: ref=0
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:setup_free() 0x77a5d040
>> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_unref() 0x77a6afa8: ref=1
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:session_cb()
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/a2dp.c:open_ind() Sink 0x77a69bd8: Open_Ind
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
>> 00:1B:DC:07:32:D3
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected transport
>> channel to 00:1B:DC:07:32:D3
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
>> CONFIGURED -> OPEN
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> src/service.c:change_state() 0x77a70eb8: device 00:1B:DC:07:32:D3
>> profile a2dp-source state changed: disconnected -> connected (0)
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> plugins/policy.c:service_cb() Added a2dp-source reconnect 1
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/source.c:source_set_state() State changed
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_CONNECTING ->
>> SOURCE_STATE_CONNECTED
>> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
>> profiles/audio/transport.c:transport_update_playing()
>> /org/bluez/hci0/dev_00_1B_DC_07_32_D3/fd19 State=TRANSPORT_STATE_IDLE
>>
>>
>> It seems the avdtp_server_socket did not received the signals and
>> that's the reason why the avdtp_confirm_cb function did not execute. I
>> would like to know what are the possible scenario why the bluetoothd
>> did not receive the event?.
>> Because, if I re-run the PTS with the same test case, the bluez could
>> received the event.
>
> It would probably help if you have the HCI logs as well, perhaps there
> is something wrong with authentication or we are rejecting the L2CAP
> connection for some reason. Also note that the server socket is only
> initialized if once a endpoint is registered so perhaps in case 1 you
> did not have any endpoint available.
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* Re: GATT Notification not sending
From: Nathan Jozwiak @ 2014-10-14 16:58 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <543D474D.1040700@mlsw.biz>
Update: I downloaded the LightBlue app from the Apple Store. The app
allows you to connect to a GATT server and select available services to
interact with. My notification characteristic showed up properly with an
initial value of 0x00 and a CCC value of 0. But when attempted to
register with the notification I saw this error from my bluetoothd output:
bluetoothd[8754]: Refusing storage path for private addressed device
/org/bluez/hci0/dev_59_F2_63_47_1D_90
bluetoothd[8754]: Unable to get ccc storage path for device
bluetoothd[8754]: attrib/gattrib.c:g_attrib_ref() 0xa073bd8: ref=3
bluetoothd[8754]: attrib/gattrib.c:g_attrib_unref() 0xa073bd8: ref=2
Unfortunately, I do not know the command LightBlue was sending to set
the CCC, but I figured this might be a clue for someone.
Am I not properly setting up the notification characteristic? I followed
the same logic as the power level characteristic setup in
profiles/proximity/reporter.c register_tx_power().
Thanks
Nate
On 10/14/14 11:54 AM, Nathan Jozwiak wrote:
> Hi all,
>
> I'm trying to send a notification to a client when a characteristic
> value is updated by the server.
>
> Here is the characteristics creation in the GATT server:
>
> /* Notification characteristic */
> bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
> atval[0] = GATT_CHR_PROP_READ | GATT_CHR_PROP_NOTIFY;
> put_le16(h + 1, &atval[1]);
> put_le16(UUID_NOTIFY, &atval[3]);
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
> ATT_NOT_PERMITTED, atval, 5);
>
> /* Notification value */
> bt_uuid16_create(&uuid, UUID_NOTIFY);
> ekey_valid_handle = h;
> atval[0] = 0x00;
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
> ATT_NOT_PERMITTED, atval, 1);
>
> /* Notification Client Characteristic Config (CCC) */
> bt_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
> atval[0] = 0x00;
> attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE, ATT_NONE,
> atval, 1);
>
> I am connecting to the GATT server using the gatttool on another Linux
> system.
>
> [CON][00:02:72:C9:5E:0F][LE]> char-desc 0x18
> handle: 0x0018, uuid: 2803
> handle: 0x0019, uuid: f005
> handle: 0x001a, uuid: 2902
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x1a
> Characteristic value/descriptor: 00 01
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
> Characteristic value/descriptor: 00
>
> Should the CCC init to 0x01? That doesn't make sense to me. Wouldn't
> that indicate the client was already setup for notifications?
>
> I have an application that communicates with bluetoothd over TCP
> sockets. So when I send bluetoothd a command it will forward it, my
> application will process it, and respond to bluetoothd which will then
> update the Notification characteristic value depending on the
> success/failure of processing. I then need to notify the client of the
> change so it can reread the value to see if the command was successful.
>
> [CON][00:02:72:C9:5E:0F][LE]> char-write-cmd 0x000b 0x1234567890
> [CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
> Characteristic value/descriptor: ff
>
> The update of the characteristic value worked fine. But I am using btmon
> to monitor traffic between the two devices and I see no messages going
> out from the server to the client.
>
>
> Thanks,
> Nate
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Nathan Jozwiak
MapleLeaf Software, Inc.
858-598-4814
^ permalink raw reply
* GATT Notification not sending
From: Nathan Jozwiak @ 2014-10-14 15:54 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
I'm trying to send a notification to a client when a characteristic
value is updated by the server.
Here is the characteristics creation in the GATT server:
/* Notification characteristic */
bt_uuid16_create(&uuid, GATT_CHARAC_UUID);
atval[0] = GATT_CHR_PROP_READ | GATT_CHR_PROP_NOTIFY;
put_le16(h + 1, &atval[1]);
put_le16(UUID_NOTIFY, &atval[3]);
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
ATT_NOT_PERMITTED, atval, 5);
/* Notification value */
bt_uuid16_create(&uuid, UUID_NOTIFY);
ekey_valid_handle = h;
atval[0] = 0x00;
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE,
ATT_NOT_PERMITTED, atval, 1);
/* Notification Client Characteristic Config (CCC) */
bt_uuid16_create(&uuid, GATT_CLIENT_CHARAC_CFG_UUID);
atval[0] = 0x00;
attrib_db_add(adapter->adapter, h++, &uuid, ATT_NONE, ATT_NONE,
atval, 1);
I am connecting to the GATT server using the gatttool on another Linux
system.
[CON][00:02:72:C9:5E:0F][LE]> char-desc 0x18
handle: 0x0018, uuid: 2803
handle: 0x0019, uuid: f005
handle: 0x001a, uuid: 2902
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x1a
Characteristic value/descriptor: 00 01
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
Characteristic value/descriptor: 00
Should the CCC init to 0x01? That doesn't make sense to me. Wouldn't
that indicate the client was already setup for notifications?
I have an application that communicates with bluetoothd over TCP
sockets. So when I send bluetoothd a command it will forward it, my
application will process it, and respond to bluetoothd which will then
update the Notification characteristic value depending on the
success/failure of processing. I then need to notify the client of the
change so it can reread the value to see if the command was successful.
[CON][00:02:72:C9:5E:0F][LE]> char-write-cmd 0x000b 0x1234567890
[CON][00:02:72:C9:5E:0F][LE]> char-read-hnd 0x19
Characteristic value/descriptor: ff
The update of the characteristic value worked fine. But I am using btmon
to monitor traffic between the two devices and I see no messages going
out from the server to the client.
Thanks,
Nate
^ permalink raw reply
* Re: [PATCH v3 1/2] core: Add Manufacturer Specific Data EIR field
From: Alfonso Acosta @ 2014-10-14 12:48 UTC (permalink / raw)
To: Alfonso Acosta, BlueZ development
In-Reply-To: <CAHF=Y4r9ua3W0=kfbL6=3K+xxGda61gn2e8fb9P-1vzUQjTeOw@mail.gmail.com>
>>> + case EIR_MANUFACTURER_DATA:
>>> + if (data_len < 2 || data_len > 2 + sizeof(eir->msd->data))
>>> + break;
>>> + eir->msd = g_malloc(sizeof(*eir->msd));
>>> + eir->msd->company = get_le16(data);
>>> + eir->msd->data_len = data_len - 2;
>>> + memcpy(&eir->msd->data, data + 2, eir->msd->data_len);
>>> + break;
>>
>> Wouldn't this lead to a memory leaks if a device (violating the spec. but
>> still) had two or more manufacturer data entries in it's AD/EIR data?
>> Taking example from how remote name entries are handled you should
>> probably g_free(eir->msd) before allocating a new one.
>
> Very good point. So, should I support multiple MSD fields or just the
> first (last) one for now?
>
> In all honesty, just like Johan, I didn't even know it was legal to
> provide multiple ones.
The v4 bundle I just sent supports multiple MSD fields in the same EIR
data block.
--
Alfonso Acosta
Embedded Systems Engineer at Spotify
Birger Jarlsgatan 61, Stockholm, Sweden
http://www.spotify.com
^ permalink raw reply
* [PATCH v4 2/2] core: Add subscription API for Manufacturer Specific Data
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413290765-20398-1-git-send-email-fons@spotify.com>
This patch allows plugins to be notified whenever an adapter receives
Manufacturer Specific Data in the advertising reports from a device.
This can happen when new device is discovered or when we autoconnect
to it.
---
src/adapter.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
src/adapter.h | 10 ++++++++++
2 files changed, 54 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 92ee1a0..f23db62 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -206,6 +206,7 @@ struct btd_adapter {
gboolean initialized;
GSList *pin_callbacks;
+ GSList *msd_callbacks;
GSList *drivers;
GSList *profiles;
@@ -4549,6 +4550,9 @@ static void adapter_remove(struct btd_adapter *adapter)
g_slist_free(adapter->pin_callbacks);
adapter->pin_callbacks = NULL;
+
+ g_slist_free(adapter->msd_callbacks);
+ adapter->msd_callbacks = NULL;
}
const char *adapter_get_path(struct btd_adapter *adapter)
@@ -4647,6 +4651,28 @@ static void confirm_name(struct btd_adapter *adapter, const bdaddr_t *bdaddr,
confirm_name_timeout, adapter);
}
+void adapter_msd_notify(struct btd_adapter *adapter, struct btd_device *dev,
+ GSList *msd_list)
+{
+ GSList *cb_l, *cb_next;
+ GSList *msd_l, *msd_next;
+
+ for (cb_l = adapter->msd_callbacks; cb_l != NULL; cb_l = cb_next) {
+ btd_msd_cb_t cb = cb_l->data;
+
+ cb_next = g_slist_next(cb_l);
+
+ for (msd_l = msd_list; msd_l != NULL; msd_l = msd_next) {
+ const struct eir_msd *msd = msd_l->data;
+
+ msd_next = g_slist_next(msd_l);
+
+ cb(adapter, dev, msd->company, msd->data,
+ msd->data_len);
+ }
+ }
+}
+
static void update_found_devices(struct btd_adapter *adapter,
const bdaddr_t *bdaddr,
uint8_t bdaddr_type, int8_t rssi,
@@ -4738,6 +4764,9 @@ static void update_found_devices(struct btd_adapter *adapter,
device_add_eir_uuids(dev, eir_data.services);
+ if (eir_data.msd_list)
+ adapter_msd_notify(adapter, dev, eir_data.msd_list);
+
eir_data_free(&eir_data);
/*
@@ -5173,6 +5202,18 @@ void btd_adapter_unregister_pin_cb(struct btd_adapter *adapter,
adapter->pin_callbacks = g_slist_remove(adapter->pin_callbacks, cb);
}
+void btd_adapter_unregister_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb)
+{
+ adapter->msd_callbacks = g_slist_remove(adapter->msd_callbacks, cb);
+}
+
+void btd_adapter_register_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb)
+{
+ adapter->msd_callbacks = g_slist_prepend(adapter->msd_callbacks, cb);
+}
+
int btd_adapter_set_fast_connectable(struct btd_adapter *adapter,
gboolean enable)
{
@@ -6663,6 +6704,9 @@ static void connected_callback(uint16_t index, uint16_t length,
btd_device_device_set_name(device, eir_data.name);
}
+ if (eir_data.msd_list)
+ adapter_msd_notify(adapter, device, eir_data.msd_list);
+
eir_data_free(&eir_data);
}
diff --git a/src/adapter.h b/src/adapter.h
index 6801fee..8f4098a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -138,6 +138,16 @@ struct btd_adapter_pin_cb_iter *btd_adapter_pin_cb_iter_new(
void btd_adapter_pin_cb_iter_free(struct btd_adapter_pin_cb_iter *iter);
bool btd_adapter_pin_cb_iter_end(struct btd_adapter_pin_cb_iter *iter);
+typedef void (*btd_msd_cb_t) (struct btd_adapter *adapter,
+ struct btd_device *dev,
+ uint16_t company,
+ const uint8_t *data,
+ uint8_t data_len);
+void btd_adapter_register_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb);
+void btd_adapter_unregister_msd_cb(struct btd_adapter *adapter,
+ btd_msd_cb_t cb);
+
/* If TRUE, enables fast connectabe, i.e. reduces page scan interval and changes
* type. If FALSE, disables fast connectable, i.e. sets page scan interval and
* type to default values. Valid for both connectable and discoverable modes. */
--
1.9.1
^ permalink raw reply related
* [PATCH v4 1/2] core: Add Manufacturer Specific Data EIR field
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413290765-20398-1-git-send-email-fons@spotify.com>
Add data structure and parsing support.
---
src/eir.c | 22 ++++++++++++++++++++++
src/eir.h | 8 ++++++++
2 files changed, 30 insertions(+)
diff --git a/src/eir.c b/src/eir.c
index d22ad91..2ea8731 100644
--- a/src/eir.c
+++ b/src/eir.c
@@ -53,6 +53,8 @@ void eir_data_free(struct eir_data *eir)
eir->hash = NULL;
g_free(eir->randomizer);
eir->randomizer = NULL;
+ g_slist_free_full(eir->msd_list, g_free);
+ eir->msd_list = NULL;
}
static void eir_parse_uuid16(struct eir_data *eir, const void *data,
@@ -137,6 +139,22 @@ static char *name2utf8(const uint8_t *name, uint8_t len)
return g_strdup(utf8_name);
}
+static void eir_parse_msd(struct eir_data *eir, const uint8_t *data,
+ uint8_t len)
+{
+ struct eir_msd *msd;
+
+ if (len < 2 || len > 2 + sizeof(msd->data))
+ return;
+
+ msd = g_malloc(sizeof(*msd));
+ msd->company = get_le16(data);
+ msd->data_len = len - 2;
+ memcpy(&msd->data, data + 2, msd->data_len);
+
+ eir->msd_list = g_slist_append(eir->msd_list, msd);
+}
+
void eir_parse(struct eir_data *eir, const uint8_t *eir_data, uint8_t eir_len)
{
uint16_t len = 0;
@@ -240,6 +258,10 @@ void eir_parse(struct eir_data *eir, const uint8_t *eir_data, uint8_t eir_len)
eir->did_product = data[4] | (data[5] << 8);
eir->did_version = data[6] | (data[7] << 8);
break;
+
+ case EIR_MANUFACTURER_DATA:
+ eir_parse_msd(eir, data, data_len);
+ break;
}
eir_data += field_len + 1;
diff --git a/src/eir.h b/src/eir.h
index e486fa2..1d5d3b3 100644
--- a/src/eir.h
+++ b/src/eir.h
@@ -37,6 +37,7 @@
#define EIR_SSP_RANDOMIZER 0x0F /* SSP Randomizer */
#define EIR_DEVICE_ID 0x10 /* device ID */
#define EIR_GAP_APPEARANCE 0x19 /* GAP appearance */
+#define EIR_MANUFACTURER_DATA 0xFF /* Manufacturer Specific Data */
/* Flags Descriptions */
#define EIR_LIM_DISC 0x01 /* LE Limited Discoverable Mode */
@@ -47,6 +48,12 @@
#define EIR_SIM_HOST 0x10 /* Simultaneous LE and BR/EDR to Same
Device Capable (Host) */
+struct eir_msd {
+ uint16_t company;
+ uint8_t data[HCI_MAX_EIR_LENGTH];
+ uint8_t data_len;
+};
+
struct eir_data {
GSList *services;
unsigned int flags;
@@ -62,6 +69,7 @@ struct eir_data {
uint16_t did_product;
uint16_t did_version;
uint16_t did_source;
+ GSList *msd_list;
};
void eir_data_free(struct eir_data *eir);
--
1.9.1
^ permalink raw reply related
* [PATCH v4 0/2] core: Add plugin-support for Manufacturer Specific Data EIR
From: Alfonso Acosta @ 2014-10-14 12:46 UTC (permalink / raw)
To: linux-bluetooth
v4:
* Support for multiple MSD fields in the same EIR data block.
* Moved parsing to a separate function: eir_parse_msd()
v3:
* Corrections suggested by Johan on the handling of eir.h
* Parser sanity check on the size of the MSD payload.
* Minor typo correction on commit message.
Alfonso Acosta (2):
core: Add Manufacturer Specific Data EIR field
core: Add subscription API for Manufacturer Specific Data
src/adapter.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
src/adapter.h | 10 ++++++++++
src/eir.c | 22 ++++++++++++++++++++++
src/eir.h | 8 ++++++++
4 files changed, 84 insertions(+)
--
1.9.1
^ permalink raw reply
* [PATCH v2 5/5] android/ipc-tester: Add cases for MAP client msg size
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Add cases testing message size verification for MAP client opcodes.
---
android/ipc-tester.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/android/ipc-tester.c b/android/ipc-tester.c
index 7dd25e8..357dda9 100644
--- a/android/ipc-tester.c
+++ b/android/ipc-tester.c
@@ -1486,5 +1486,19 @@ int main(int argc, char *argv[])
HAL_SERVICE_ID_BLUETOOTH,
HAL_SERVICE_ID_HANDSFREE_CLIENT);
+ /* check for valid data size for MAP CLIENT */
+ test_datasize_valid("MAP CLIENT Get instances+",
+ HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_OP_MAP_CLIENT_GET_INSTANCES,
+ sizeof(struct hal_cmd_map_client_get_instances),
+ 1, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+ test_datasize_valid("MAP CLIENT Get instances-",
+ HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_OP_MAP_CLIENT_GET_INSTANCES,
+ sizeof(struct hal_cmd_map_client_get_instances),
+ -1, HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+
return tester_run();
}
--
1.9.3
^ permalink raw reply related
* [PATCH v2 4/5] android/ipc-tester: Add case for MAP client service opcode boundries
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
This patch adds test sending out of range opcode for service.
---
android/ipc-tester.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/android/ipc-tester.c b/android/ipc-tester.c
index 161777d..7dd25e8 100644
--- a/android/ipc-tester.c
+++ b/android/ipc-tester.c
@@ -940,6 +940,10 @@ int main(int argc, char *argv[])
HAL_SERVICE_ID_BLUETOOTH,
HAL_SERVICE_ID_HANDSFREE_CLIENT);
+ test_opcode_valid("MAP_CLIENT", HAL_SERVICE_ID_MAP_CLIENT, 0x01, 0,
+ HAL_SERVICE_ID_BLUETOOTH,
+ HAL_SERVICE_ID_MAP_CLIENT);
+
/* check for valid data size */
test_datasize_valid("CORE Register+", HAL_SERVICE_ID_CORE,
HAL_OP_REGISTER_MODULE,
--
1.9.3
^ permalink raw reply related
* [PATCH v2 3/5] android/map-client: Add support for get remote MAS instances
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
This allows to get remote mas instances. In case of wrong sdp record
fail status will be returned in notification.
---
android/map-client.c | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 129 insertions(+), 1 deletion(-)
diff --git a/android/map-client.c b/android/map-client.c
index 142c680..2069fbe 100644
--- a/android/map-client.c
+++ b/android/map-client.c
@@ -30,21 +30,149 @@
#include <stdint.h>
#include <glib.h>
+#include "lib/sdp.h"
+#include "lib/sdp_lib.h"
+#include "src/sdp-client.h"
+
#include "ipc.h"
#include "lib/bluetooth.h"
#include "map-client.h"
#include "src/log.h"
#include "hal-msg.h"
+#include "ipc-common.h"
+#include "utils.h"
+#include "src/shared/util.h"
static struct ipc *hal_ipc = NULL;
static bdaddr_t adapter_addr;
+static int fill_mce_inst(void *buf, int32_t id, int32_t scn, int32_t msg_type,
+ const void *name, uint8_t name_len)
+{
+ struct hal_map_client_mas_instance *inst = buf;
+
+ inst->id = id;
+ inst->scn = scn;
+ inst->msg_types = msg_type;
+ inst->name_len = name_len;
+
+ if (name_len)
+ memcpy(inst->name, name, name_len);
+
+ return sizeof(*inst) + name_len;
+}
+
+static void map_client_sdp_search_cb(sdp_list_t *recs, int err, gpointer data)
+{
+ uint8_t buf[IPC_MTU];
+ struct hal_ev_map_client_remote_mas_instances *ev = (void *) buf;
+ bdaddr_t *dst = data;
+ sdp_list_t *list, *protos;
+ uint8_t status;
+ int32_t id, scn, msg_type, name_len, num_instances = 0;
+ char *name;
+ size_t size;
+
+ size = sizeof(*ev);
+ bdaddr2android(dst, &ev->bdaddr);
+
+ if (err < 0) {
+ error("mce: Unable to get SDP record: %s", strerror(-err));
+ status = HAL_STATUS_FAILED;
+ goto fail;
+ }
+
+ for (list = recs; list != NULL; list = list->next) {
+ sdp_record_t *rec = list->data;
+ sdp_data_t *data;
+
+ data = sdp_data_get(rec, SDP_ATTR_MAS_INSTANCE_ID);
+ if (!data) {
+ error("mce: cannot get mas instance id");
+ continue;
+ }
+
+ id = data->val.uint8;
+
+ data = sdp_data_get(rec, SDP_ATTR_SVCNAME_PRIMARY);
+ if (!data) {
+ error("mce: cannot get mas instance name");
+ continue;
+ }
+
+ name = data->val.str;
+ name_len = data->unitSize;
+
+ data = sdp_data_get(rec, SDP_ATTR_SUPPORTED_MESSAGE_TYPES);
+ if (!data) {
+ error("mce: cannot get mas instance msg type");
+ continue;
+ }
+
+ msg_type = data->val.uint8;
+
+ if (sdp_get_access_protos(rec, &protos)) {
+ error("mce: cannot get mas instance sdp protocol list");
+ continue;
+ }
+
+ scn = sdp_get_proto_port(protos, RFCOMM_UUID);
+ if (scn) {
+ error("mce: cannot get mas instance rfcomm channel");
+ continue;
+ }
+
+ sdp_list_foreach(protos, (sdp_list_func_t) sdp_list_free, NULL);
+ sdp_list_free(protos, NULL);
+
+ size += fill_mce_inst(buf + size, id, scn, msg_type, name,
+ name_len);
+ num_instances++;
+ }
+
+ status = HAL_STATUS_SUCCESS;
+
+fail:
+ ev->num_instances = num_instances;
+ ev->status = status;
+
+ ipc_send_notif(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_EV_MAP_CLIENT_REMOTE_MAS_INSTANCES, size, buf);
+
+ free(dst);
+}
+
static void handle_get_instances(const void *buf, uint16_t len)
{
+ const struct hal_cmd_map_client_get_instances *cmd = buf;
+ uint8_t status;
+ bdaddr_t *dst;
+ uuid_t uuid;
+
DBG("");
+ dst = new0(bdaddr_t, 1);
+ if (!dst) {
+ error("mce: Fail to allocate cb data");
+ status = HAL_STATUS_FAILED;
+ goto failed;
+ }
+
+ android2bdaddr(&cmd->bdaddr, dst);
+ sdp_uuid16_create(&uuid, MAP_MSE_SVCLASS_ID);
+
+ if (bt_search_service(&adapter_addr, dst, &uuid,
+ map_client_sdp_search_cb, dst, free, 0)) {
+ error("mce: Failed to search SDP details");
+ status = HAL_STATUS_FAILED;
+ goto failed;
+ }
+
+ status = HAL_STATUS_SUCCESS;
+
+failed:
ipc_send_rsp(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
- HAL_OP_MAP_CLIENT_GET_INSTANCES, HAL_STATUS_FAILED);
+ HAL_OP_MAP_CLIENT_GET_INSTANCES, status);
}
static const struct ipc_handler cmd_handlers[] = {
--
1.9.3
^ permalink raw reply related
* [PATCH v2 2/5] android/map-client: Add stubs for MAP client commands handlers
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
Add empty handlers for MAP client IPC commands.
---
android/map-client.c | 34 +++++++++++++++++++++++++++++++++-
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/android/map-client.c b/android/map-client.c
index 4556461..142c680 100644
--- a/android/map-client.c
+++ b/android/map-client.c
@@ -28,17 +28,49 @@
#include <stdbool.h>
#include <stdlib.h>
#include <stdint.h>
+#include <glib.h>
#include "ipc.h"
#include "lib/bluetooth.h"
#include "map-client.h"
+#include "src/log.h"
+#include "hal-msg.h"
+
+static struct ipc *hal_ipc = NULL;
+static bdaddr_t adapter_addr;
+
+static void handle_get_instances(const void *buf, uint16_t len)
+{
+ DBG("");
+
+ ipc_send_rsp(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
+ HAL_OP_MAP_CLIENT_GET_INSTANCES, HAL_STATUS_FAILED);
+}
+
+static const struct ipc_handler cmd_handlers[] = {
+ /* HAL_OP_MAP_CLIENT_GET_INSTANCES */
+ { handle_get_instances, false,
+ sizeof(struct hal_cmd_map_client_get_instances) },
+};
bool bt_map_client_register(struct ipc *ipc, const bdaddr_t *addr, uint8_t mode)
{
- return false;
+ DBG("");
+
+ bacpy(&adapter_addr, addr);
+
+ hal_ipc = ipc;
+
+ ipc_register(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT, cmd_handlers,
+ G_N_ELEMENTS(cmd_handlers));
+
+ return true;
}
void bt_map_client_unregister(void)
{
+ DBG("");
+ ipc_unregister(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT);
+ hal_ipc = NULL;
}
--
1.9.3
^ permalink raw reply related
* [PATCH v2 1/5] android/map-client: Add initial files
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1413285875-17814-1-git-send-email-grzegorz.kolodziejczyk@tieto.com>
This adds initial daemon code for MAP client profile.
---
android/Android.mk | 1 +
android/Makefile.am | 1 +
android/main.c | 12 ++++++++++++
android/map-client.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
android/map-client.h | 26 ++++++++++++++++++++++++++
5 files changed, 84 insertions(+)
create mode 100644 android/map-client.c
create mode 100644 android/map-client.h
diff --git a/android/Android.mk b/android/Android.mk
index 2b59fb8..aefe41c 100644
--- a/android/Android.mk
+++ b/android/Android.mk
@@ -57,6 +57,7 @@ LOCAL_SRC_FILES := \
bluez/android/gatt.c \
bluez/android/health.c \
bluez/profiles/health/mcap.c \
+ bluez/android/map-client.c \
bluez/src/log.c \
bluez/src/shared/mgmt.c \
bluez/src/shared/util.c \
diff --git a/android/Makefile.am b/android/Makefile.am
index b013095..b3eb1c5 100644
--- a/android/Makefile.am
+++ b/android/Makefile.am
@@ -46,6 +46,7 @@ android_bluetoothd_SOURCES = android/main.c \
android/gatt.h android/gatt.c \
android/health.h android/health.c \
profiles/health/mcap.h profiles/health/mcap.c \
+ android/map-client.h android/map-client.c \
attrib/att.c attrib/att.h \
attrib/gatt.c attrib/gatt.h \
attrib/gattrib.c attrib/gattrib.h \
diff --git a/android/main.c b/android/main.c
index 703b3b6..b5f6937 100644
--- a/android/main.c
+++ b/android/main.c
@@ -62,6 +62,7 @@
#include "gatt.h"
#include "health.h"
#include "handsfree-client.h"
+#include "map-client.h"
#include "utils.h"
#define DEFAULT_VENDOR "BlueZ"
@@ -235,6 +236,14 @@ static void service_register(const void *buf, uint16_t len)
}
break;
+ case HAL_SERVICE_ID_MAP_CLIENT:
+ if (!bt_map_client_register(hal_ipc, &adapter_bdaddr,
+ m->mode)) {
+ status = HAL_STATUS_FAILED;
+ goto failed;
+ }
+
+ break;
default:
DBG("service %u not supported", m->service_id);
status = HAL_STATUS_FAILED;
@@ -288,6 +297,9 @@ static bool unregister_service(uint8_t id)
case HAL_SERVICE_ID_HANDSFREE_CLIENT:
bt_hf_client_unregister();
break;
+ case HAL_SERVICE_ID_MAP_CLIENT:
+ bt_map_client_unregister();
+ break;
default:
DBG("service %u not supported", id);
return false;
diff --git a/android/map-client.c b/android/map-client.c
new file mode 100644
index 0000000..4556461
--- /dev/null
+++ b/android/map-client.c
@@ -0,0 +1,44 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdbool.h>
+#include <stdlib.h>
+#include <stdint.h>
+
+#include "ipc.h"
+#include "lib/bluetooth.h"
+#include "map-client.h"
+
+bool bt_map_client_register(struct ipc *ipc, const bdaddr_t *addr, uint8_t mode)
+{
+ return false;
+}
+
+void bt_map_client_unregister(void)
+{
+
+}
diff --git a/android/map-client.h b/android/map-client.h
new file mode 100644
index 0000000..0e63072
--- /dev/null
+++ b/android/map-client.h
@@ -0,0 +1,26 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+bool bt_map_client_register(struct ipc *ipc, const bdaddr_t *addr,
+ uint8_t mode);
+void bt_map_client_unregister(void);
--
1.9.3
^ permalink raw reply related
* [PATCH v2 0/5] android/map-client: Add MAP client daemon implementation
From: Grzegorz Kolodziejczyk @ 2014-10-14 11:24 UTC (permalink / raw)
To: linux-bluetooth
v1.
*Add MAP client daemon implementation (skeleton, body)
*Add haltest MAP client support
v2.
*Fix style issue in cmd handler
*Change if-else to if statements for map client instance create
*Check if allocation of cb data has failed
*Set free as destroy callback function for search service
*Fix status overwrite (add fail label)
Grzegorz Kolodziejczyk (5):
android/map-client: Add initial files
android/map-client: Add stubs for MAP client commands handlers
android/map-client: Add support for get remote MAS instances
android/ipc-tester: Add case for MAP client service opcode boundries
android/ipc-tester: Add cases for MAP client msg size
android/Android.mk | 1 +
android/Makefile.am | 1 +
android/ipc-tester.c | 18 +++++
android/main.c | 12 +++
android/map-client.c | 204 +++++++++++++++++++++++++++++++++++++++++++++++++++
android/map-client.h | 26 +++++++
6 files changed, 262 insertions(+)
create mode 100644 android/map-client.c
create mode 100644 android/map-client.h
--
1.9.3
^ permalink raw reply
* Re: [PATCH v2 1/5] shared/att: Drop the connection if a request is received while one is pending.
From: Luiz Augusto von Dentz @ 2014-10-14 10:37 UTC (permalink / raw)
To: Arman Uguray; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1413234602-20566-2-git-send-email-armansito@chromium.org>
Hi Arman,
On Tue, Oct 14, 2014 at 12:09 AM, Arman Uguray <armansito@chromium.org> wrote:
> With this patch, when bt_att is being used for the server role, it now makes
> sure that a second request drops the connection unless a response for a previous
> request has been sent.
> ---
> src/shared/att.c | 101 +++++++++++++++++++++++++++++++++----------------------
> 1 file changed, 61 insertions(+), 40 deletions(-)
>
> diff --git a/src/shared/att.c b/src/shared/att.c
> index de35aef..96f34a3 100644
> --- a/src/shared/att.c
> +++ b/src/shared/att.c
> @@ -64,6 +64,8 @@ struct bt_att {
> bool in_disconn;
> bool need_disconn_cleanup;
>
> + bool in_req; /* There's a pending incoming request */
> +
> uint8_t *buf;
> uint16_t mtu;
>
> @@ -460,6 +462,9 @@ static bool can_write_data(struct io *io, void *user_data)
> case ATT_OP_TYPE_IND:
> att->pending_ind = op;
> break;
> + case ATT_OP_TYPE_RSP:
> + /* Set in_req to false to indicate that no request is pending */
> + att->in_req = false;
> default:
> destroy_att_send_op(op);
> return true;
> @@ -604,6 +609,46 @@ static void handle_notify(struct bt_att *att, uint8_t opcode, uint8_t *pdu,
> bt_att_unref(att);
> }
>
> +static void disconn_handler(void *data, void *user_data)
> +{
> + struct att_disconn *disconn = data;
> +
> + if (disconn->removed)
> + return;
> +
> + if (disconn->callback)
> + disconn->callback(disconn->user_data);
> +}
> +
> +static bool disconnect_cb(struct io *io, void *user_data)
> +{
> + struct bt_att *att = user_data;
> +
> + io_destroy(att->io);
> + att->io = NULL;
> +
> + util_debug(att->debug_callback, att->debug_data,
> + "Physical link disconnected");
> +
> + bt_att_ref(att);
> + att->in_disconn = true;
> + queue_foreach(att->disconn_list, disconn_handler, NULL);
> + att->in_disconn = false;
> +
> + if (att->need_disconn_cleanup) {
> + queue_remove_all(att->disconn_list, match_disconn_removed, NULL,
> + destroy_att_disconn);
> + att->need_disconn_cleanup = false;
> + }
> +
> + bt_att_cancel_all(att);
> + bt_att_unregister_all(att);
> +
> + bt_att_unref(att);
> +
> + return false;
> +}
> +
> static bool can_read_data(struct io *io, void *user_data)
> {
> struct bt_att *att = user_data;
> @@ -635,6 +680,22 @@ static bool can_read_data(struct io *io, void *user_data)
> util_debug(att->debug_callback, att->debug_data,
> "ATT opcode cannot be handled: 0x%02x", opcode);
> break;
> + case ATT_OP_TYPE_REQ:
> + /* If a request is currently pending, then the sequential
> + * protocol was violated. Disconnect the bearer and notify the
> + * upper-layer.
> + */
It seems this code is not following our coding style regarding multi
line comments, check doc/coding-style.txt(M2: Multiple line comment)
the first line should be empty.
> + if (att->in_req) {
> + util_debug(att->debug_callback, att->debug_data,
> + "Received request while another is "
> + "pending: 0x%02x", opcode);
> + disconnect_cb(att->io, att);
> + return false;
> + }
> +
> + att->in_req = true;
> +
> + /* Fall through to the next case */
This might cause a problem with our own code when connecting to each
other if bt_att_cancel is used, apparently bt_att_cancel does not send
anything to the remote side which seems to enable sending a new
request without waiting any response for the first one.
> default:
> /* For all other opcodes notify the upper layer of the PDU and
> * let them act on it.
> @@ -648,46 +709,6 @@ static bool can_read_data(struct io *io, void *user_data)
> return true;
> }
>
> -static void disconn_handler(void *data, void *user_data)
> -{
> - struct att_disconn *disconn = data;
> -
> - if (disconn->removed)
> - return;
> -
> - if (disconn->callback)
> - disconn->callback(disconn->user_data);
> -}
> -
> -static bool disconnect_cb(struct io *io, void *user_data)
> -{
> - struct bt_att *att = user_data;
> -
> - io_destroy(att->io);
> - att->io = NULL;
> -
> - util_debug(att->debug_callback, att->debug_data,
> - "Physical link disconnected");
> -
> - bt_att_ref(att);
> - att->in_disconn = true;
> - queue_foreach(att->disconn_list, disconn_handler, NULL);
> - att->in_disconn = false;
> -
> - if (att->need_disconn_cleanup) {
> - queue_remove_all(att->disconn_list, match_disconn_removed, NULL,
> - destroy_att_disconn);
> - att->need_disconn_cleanup = false;
> - }
> -
> - bt_att_cancel_all(att);
> - bt_att_unregister_all(att);
> -
> - bt_att_unref(att);
> -
> - return false;
> -}
> -
> struct bt_att *bt_att_new(int fd)
> {
> struct bt_att *att;
> --
> 2.1.0.rc2.206.gedb03e5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH ] obexd/mas: Add Support fo MSETime filter
From: Bharat Panda @ 2014-10-14 10:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: cpgs, Bharat Panda
Changes made to add support for MSE local time parameter
along with GetMessageListing response.
---
obexd/plugins/mas.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/obexd/plugins/mas.c b/obexd/plugins/mas.c
index fb97fe3..7f14bf8 100644
--- a/obexd/plugins/mas.c
+++ b/obexd/plugins/mas.c
@@ -30,6 +30,7 @@
#include <glib.h>
#include <fcntl.h>
#include <inttypes.h>
+#include <sys/time.h>
#include <gobex/gobex.h>
#include <gobex/gobex-apparam.h>
@@ -228,6 +229,25 @@ static void g_string_append_escaped_printf(GString *string,
va_end(ap);
}
+static gchar *get_mse_timestamp(void)
+{
+ struct timeval time_val;
+ struct tm ltime;
+ gchar *local_ts;
+
+ gettimeofday(&time_val, NULL);
+
+ if (!localtime_r(&time_val.tv_sec, <ime))
+ return NULL;
+
+ local_ts = g_strdup_printf("%04d%02d%02dT%02d%02d%02d",
+ ltime.tm_year + 1900, ltime.tm_mon + 1,
+ ltime.tm_mday, ltime.tm_hour,
+ ltime.tm_min, ltime.tm_sec);
+
+ return local_ts;
+}
+
static const char *yesorno(gboolean a)
{
if (a)
@@ -243,6 +263,7 @@ static void get_messages_listing_cb(void *session, int err, uint16_t size,
{
struct mas_session *mas = user_data;
uint16_t max = 1024;
+ gchar *mse_time;
if (err < 0 && err != -EAGAIN) {
obex_object_set_io_flags(mas, G_IO_ERR, err);
@@ -358,6 +379,13 @@ proceed:
mas->outparams = g_obex_apparam_set_uint8(mas->outparams,
MAP_AP_NEWMESSAGE,
newmsg ? 1 : 0);
+ /* Response to report the local time of MSE */
+ mse_time = get_mse_timestamp();
+ if (mse_time) {
+ g_obex_apparam_set_string(mas->outparams,
+ MAP_AP_MSETIME, mse_time);
+ g_free(mse_time);
+ }
}
if (err != -EAGAIN)
--
1.9.1
^ permalink raw reply related
* Re: Not getting an AVDTP: incoming connect
From: Luiz Augusto von Dentz @ 2014-10-14 9:51 UTC (permalink / raw)
To: John Tobias; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CACUGKYPh7MZ7gLgnBWm=rtAbkRSis-qy3UwcCmKiLdyg9aop6w@mail.gmail.com>
Hi John,
On Tue, Oct 14, 2014 at 3:09 AM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hi Marcell / Bluez Team:
>
> I was running the PTS 5.2 and there were an occurrences that the bluez
> did not show a similar message below:
>
> [agent] Authorize service 0000110d-0000-1000-8000-00805f9b34fb (yes/no):
>
>
> 1. I logs below are the traces of the bluetoothd not prompting the
> Authorize service message:
>
> t 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
> connected eir_len 31
> Oct 13 23:27:22 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:dev_disconnected() Device 00:1B:DC:07:32:D3
> disconnected, reason 2
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:adapter_remove_connection()
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> plugins/policy.c:disconnect_cb() reason 2
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:1B:DC:07:32:D3
> type 0 status 0xe
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/device.c:device_bonding_complete() bonding (nil) status 0x0e
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/device.c:device_bonding_failed() status 14
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:resume_discovery()
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_disconnected
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: setting adv
> params failed: Operation not permitted
> Oct 13 23:27:26 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: failed to enable
> advertising
>
>
> 2. These messages are the traces of the bluetoothd showing the
> Authorize service message:
>
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/adapter.c:connected_callback() hci0 device 00:1B:DC:07:32:D3
> connected eir_len 31
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]: on_connected
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
> 00:1B:DC:07:32:D3
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/source.c:source_set_state() State changed
> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_DISCONNECTED ->
> SOURCE_STATE_CONNECTING
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/agent.c:agent_ref() 0x77a601d0: ref=2
> Oct 13 23:29:48 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/agent.c:agent_authorize_service() authorize service request was
> sent for /org/bluez/hci0/dev_00_1B_DC_07_32_D3
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/agent.c:agent_ref() 0x77a601d0: ref=3
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/agent.c:agent_unref() 0x77a601d0: ref=2
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/agent.c:agent_unref() 0x77a601d0: ref=1
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected signaling
> channel to 00:1B:DC:07:32:D3
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP imtu=672, omtu=672
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:session_cb()
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_parse_cmd() Received DISCOVER_CMD
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:session_cb()
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
> GET_CAPABILITIES_CMD
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:endpoint_getcap_ind() Sink 0x77a69bd8:
> Get_Capability_Ind
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:session_cb()
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_parse_cmd() Received
> SET_CONFIGURATION_CMD
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:endpoint_setconf_ind() Sink 0x77a69bd8:
> Set_Configuration_Ind
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=1
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:setup_ref() 0x77a5d040: ref=1
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/media.c:media_endpoint_async_call() Calling
> SetConfiguration: name = :1.6 path = /MediaEndpoint/A2DPSink
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_ref() 0x77a6afa8: ref=2
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
> IDLE -> CONFIGURED
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:setup_unref() 0x77a5d040: ref=0
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:setup_free() 0x77a5d040
> Oct 13 23:29:52 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_unref() 0x77a6afa8: ref=1
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:session_cb()
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_parse_cmd() Received OPEN_CMD
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/a2dp.c:open_ind() Sink 0x77a69bd8: Open_Ind
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_confirm_cb() AVDTP: incoming connect from
> 00:1B:DC:07:32:D3
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_connect_cb() AVDTP: connected transport
> channel to 00:1B:DC:07:32:D3
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/avdtp.c:avdtp_sep_set_state() stream state changed:
> CONFIGURED -> OPEN
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> src/service.c:change_state() 0x77a70eb8: device 00:1B:DC:07:32:D3
> profile a2dp-source state changed: disconnected -> connected (0)
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> plugins/policy.c:service_cb() Added a2dp-source reconnect 1
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/source.c:source_set_state() State changed
> /org/bluez/hci0/dev_00_1B_DC_07_32_D3: SOURCE_STATE_CONNECTING ->
> SOURCE_STATE_CONNECTED
> Oct 13 23:29:53 DEV9MRCNERGAAAQYDKGP bluetoothd[152]:
> profiles/audio/transport.c:transport_update_playing()
> /org/bluez/hci0/dev_00_1B_DC_07_32_D3/fd19 State=TRANSPORT_STATE_IDLE
>
>
> It seems the avdtp_server_socket did not received the signals and
> that's the reason why the avdtp_confirm_cb function did not execute. I
> would like to know what are the possible scenario why the bluetoothd
> did not receive the event?.
> Because, if I re-run the PTS with the same test case, the bluez could
> received the event.
It would probably help if you have the HCI logs as well, perhaps there
is something wrong with authentication or we are rejecting the L2CAP
connection for some reason. Also note that the server socket is only
initialized if once a endpoint is registered so perhaps in case 1 you
did not have any endpoint available.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 04/10] android/ipc-tester: Add missing service opcode boundries test cases
From: Grzegorz Kolodziejczyk @ 2014-10-14 9:02 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <2172179.Nvf6HcAWOB@athlon>
Hi Szymon,
On 13 October 2014 22:32, Szymon Janc <szymon.janc@gmail.com> wrote:
> Hi Grzegorz,
>
> On Thursday 09 October 2014 14:45:08 Grzegorz Kolodziejczyk wrote:
>> This patch adds tests sending out of range opcode for each service.
>> ---
>> android/ipc-tester.c | 14 ++++++++++++++
>> 1 file changed, 14 insertions(+)
>>
>> diff --git a/android/ipc-tester.c b/android/ipc-tester.c
>> index ea71c8d..161777d 100644
>> --- a/android/ipc-tester.c
>> +++ b/android/ipc-tester.c
>> @@ -919,9 +919,23 @@ int main(int argc, char *argv[])
>> test_opcode_valid("PAN", HAL_SERVICE_ID_PAN, 0x05, 0,
>> HAL_SERVICE_ID_BLUETOOTH, HAL_SERVICE_ID_PAN);
>>
>> + test_opcode_valid("HANDSFREE", HAL_SERVICE_ID_HANDSFREE, 0x0f, 0,
>> + HAL_SERVICE_ID_BLUETOOTH,
>> + HAL_SERVICE_ID_HANDSFREE);
>> +
>> test_opcode_valid("A2DP", HAL_SERVICE_ID_A2DP, 0x03, 0,
>> HAL_SERVICE_ID_BLUETOOTH, HAL_SERVICE_ID_A2DP);
>>
>> + test_opcode_valid("HEALTH", HAL_SERVICE_ID_HEALTH, 0x06, 0,
>> + HAL_SERVICE_ID_BLUETOOTH,
>> + HAL_SERVICE_ID_HEALTH);
>> +
>> + test_opcode_valid("AVRCP", HAL_SERVICE_ID_AVRCP, 0x0b, 0,
>> + HAL_SERVICE_ID_BLUETOOTH, HAL_SERVICE_ID_AVRCP);
>> +
>> + test_opcode_valid("GATT", HAL_SERVICE_ID_GATT, 0x24, 0,
>> + HAL_SERVICE_ID_BLUETOOTH, HAL_SERVICE_ID_GATT);
>> +
>> test_opcode_valid("HF_CLIENT", HAL_SERVICE_ID_HANDSFREE_CLIENT, 0x10, 0,
>> HAL_SERVICE_ID_BLUETOOTH,
>> HAL_SERVICE_ID_HANDSFREE_CLIENT);
>
> In future please don't send unrelated patches as part of serie. This makes
> review easier and also makes no unnecessary delays in getting such patches
> merged.
>
> Applied. Thanks.
>
Ok, sorry, I must forgot to move this patch to another set.
> --
> Szymon K. Janc
> szymon.janc@gmail.com
Best regards,
Grzegorz
^ permalink raw reply
* Re: [PATCH 03/10] android/map-client: Add support for get remote MAS instances
From: Grzegorz Kolodziejczyk @ 2014-10-14 9:01 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1609087.iuvzY7v4pk@athlon>
Hi Szymon,
On 13 October 2014 22:19, Szymon Janc <szymon.janc@gmail.com> wrote:
> On Thursday 09 October 2014 14:45:07 Grzegorz Kolodziejczyk wrote:
>> This allows to get remote mas instances. In case of wrong sdp record
>> fail status will be returned in notification.
>> ---
>> android/map-client.c | 124
>> ++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 123
>> insertions(+), 1 deletion(-)
>>
>> diff --git a/android/map-client.c b/android/map-client.c
>> index 1001b36..adeae4b 100644
>> --- a/android/map-client.c
>> +++ b/android/map-client.c
>> @@ -30,21 +30,143 @@
>> #include <stdint.h>
>> #include <glib.h>
>>
>> +#include "lib/sdp.h"
>> +#include "lib/sdp_lib.h"
>> +#include "src/sdp-client.h"
>> +
>> #include "ipc.h"
>> #include "lib/bluetooth.h"
>> #include "map-client.h"
>> #include "src/log.h"
>> #include "hal-msg.h"
>> +#include "ipc-common.h"
>> +#include "utils.h"
>> +#include "src/shared/util.h"
>>
>> static struct ipc *hal_ipc = NULL;
>> static bdaddr_t adapter_addr;
>>
>> +static int fill_mce_inst(void *buf, int32_t id, int32_t scn, int32_t
>> msg_type, + const void *name, uint8_t name_len)
>> +{
>> + struct hal_map_client_mas_instance *inst = buf;
>> +
>> + inst->id = id;
>> + inst->scn = scn;
>> + inst->msg_types = msg_type;
>> + inst->name_len = name_len;
>> +
>> + if (name_len)
>> + memcpy(inst->name, name, name_len);
>> +
>> + return sizeof(*inst) + name_len;
>> +}
>> +
>> +static void map_client_sdp_search_cb(sdp_list_t *recs, int err, gpointer
>> data) +{
>> + uint8_t buf[IPC_MTU];
>> + struct hal_ev_map_client_remote_mas_instances *ev = (void *) buf;
>> + bdaddr_t *dst = data;
>> + sdp_list_t *list, *protos;
>> + uint8_t status;
>> + int32_t id, scn, msg_type, name_len, num_instances = 0;
>> + char *name;
>> + size_t size;
>> +
>> + size = sizeof(*ev);
>> + bdaddr2android(dst, &ev->bdaddr);
>> +
>> + if (err < 0) {
>> + error("mce: Unable to get SDP record: %s", strerror(-err));
>> + status = HAL_STATUS_FAILED;
>> + goto fail;
>> + }
>> +
>> + for (list = recs; list != NULL; list = list->next) {
>> + sdp_record_t *rec = list->data;
>> + sdp_data_t *data;
>> +
>> + data = sdp_data_get(rec, SDP_ATTR_MAS_INSTANCE_ID);
>> + if (data) {
>> + id = data->val.uint8;
>> + } else {
>> + error("mce: cannot get mas instance id");
>> + status = HAL_STATUS_FAILED;
>> + goto fail;
>
> I'm not sure if we should fail here. Lets just skip record (we can leave error
> message) and continue with search.
>
> Also make it like: if (!data) {error(); continue;};
> Not need for if-else
>
Ok.
>> + }
>> +
>> + data = sdp_data_get(rec, SDP_ATTR_SVCNAME_PRIMARY);
>> + if (data) {
>> + name = data->val.str;
>> + name_len = data->unitSize;
>> + } else {
>> + error("mce: cannot get mas instance name");
>> + status = HAL_STATUS_FAILED;
>> + goto fail;
>> + }
>> +
>> + data = sdp_data_get(rec, SDP_ATTR_SUPPORTED_MESSAGE_TYPES);
>> + if (data) {
>> + msg_type = data->val.uint8;
>> + } else {
>> + error("mce: cannot get mas instance msg type");
>> + status = HAL_STATUS_FAILED;
>> + goto fail;
>> + }
>> +
>> + if (!sdp_get_access_protos(rec, &protos)) {
>> + scn = sdp_get_proto_port(protos, RFCOMM_UUID);
>> +
>> + sdp_list_foreach(protos,
>> + (sdp_list_func_t) sdp_list_free, NULL);
>> + sdp_list_free(protos, NULL);
>> + } else {
>> + error("mce: cannot get mas instance rfcomm channel");
>> + status = HAL_STATUS_FAILED;
>> + goto fail;
>> + }
>> +
>> + size += fill_mce_inst(buf + size, id, scn, msg_type, name,
>> + name_len);
>> + num_instances++;
>> + }
>> +
>> + status = HAL_STATUS_SUCCESS;
>
> Please check if we are expected to return error if no instances were found.
>
Ok, I'll check it.
>> +
>> +fail:
>> + ev->num_instances = num_instances;
>> + ev->status = status;
>> +
>> + ipc_send_notif(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
>> + HAL_EV_MAP_CLIENT_REMOTE_MAS_INSTANCES, size, buf);
>> +
>> + free(dst);
>> +}
>> +
>> static void handle_get_instances(const void *buf, uint16_t len)
>> {
>> + const struct hal_cmd_map_client_get_instances *cmd = buf;
>> + uint8_t status;
>> + bdaddr_t *dst;
>> + uuid_t uuid;
>> +
>> DBG("");
>>
>> + dst = new0(bdaddr_t, 1);
>
> Please check if allocation failed.
>
I forgot this check, I'll fix this.
>> + android2bdaddr(&cmd->bdaddr, dst);
>> +
>> + sdp_uuid16_create(&uuid, MAP_MSE_SVCLASS_ID);
>> +
>> + if (bt_search_service(&adapter_addr, dst, &uuid,
>> + map_client_sdp_search_cb, dst, NULL, 0)) {
>
> Just a hint: you can pass free as destroy function here instead of taking care
> of that in callback.
>
>> + error("mce: Failed to search SDP details");
>> + status = HAL_STATUS_FAILED;
>> + free(dst);
>> + }
>> +
>> + status = HAL_STATUS_SUCCESS;
>
> In case of error status is overwritten.
>
I'll re-check those statuses.
>> ipc_send_rsp(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
>> - HAL_OP_MAP_CLIENT_GET_INSTANCES, HAL_STATUS_FAILED);
>> + HAL_OP_MAP_CLIENT_GET_INSTANCES, status);
>> }
>>
>> static const struct ipc_handler cmd_handlers[] = {
>
> --
> Szymon K. Janc
> szymon.janc@gmail.com
Best regards,
Grzegorz
^ permalink raw reply
* Re: [PATCH 02/10] android/map-client: Add stubs for MAP client commands handlers
From: Grzegorz Kolodziejczyk @ 2014-10-14 8:58 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1797034.Wjt854TcTE@athlon>
Hi Szymon,
On 13 October 2014 21:58, Szymon Janc <szymon.janc@gmail.com> wrote:
> Hi Grzegorz,
>
> On Thursday 09 October 2014 14:45:06 Grzegorz Kolodziejczyk wrote:
>> Add empty handlers for MAP client IPC commands.
>> ---
>> android/map-client.c | 33 ++++++++++++++++++++++++++++++++-
>> 1 file changed, 32 insertions(+), 1 deletion(-)
>>
>> diff --git a/android/map-client.c b/android/map-client.c
>> index 4556461..1001b36 100644
>> --- a/android/map-client.c
>> +++ b/android/map-client.c
>> @@ -28,17 +28,48 @@
>> #include <stdbool.h>
>> #include <stdlib.h>
>> #include <stdint.h>
>> +#include <glib.h>
>>
>> #include "ipc.h"
>> #include "lib/bluetooth.h"
>> #include "map-client.h"
>> +#include "src/log.h"
>> +#include "hal-msg.h"
>> +
>> +static struct ipc *hal_ipc = NULL;
>> +static bdaddr_t adapter_addr;
>> +
>> +static void handle_get_instances(const void *buf, uint16_t len)
>> +{
>> + DBG("");
>> +
>> + ipc_send_rsp(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT,
>> + HAL_OP_MAP_CLIENT_GET_INSTANCES, HAL_STATUS_FAILED);
>> +}
>> +
>> +static const struct ipc_handler cmd_handlers[] = {
>> + {handle_get_instances, false,
>> + sizeof(struct hal_cmd_map_client_get_instances)},
>
> Style issue: there should be spaces after { and before }.
> Also please add comment about define type just like in other handlers (I'm
> aware that there is just 1 handler here but lets be consistent).
>
Ok, I'll fix it.
>> +};
>>
>> bool bt_map_client_register(struct ipc *ipc, const bdaddr_t *addr, uint8_t
>> mode) {
>> - return false;
>> + DBG("");
>> +
>> + bacpy(&adapter_addr, addr);
>> +
>> + hal_ipc = ipc;
>> +
>> + ipc_register(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT, cmd_handlers,
>> + G_N_ELEMENTS(cmd_handlers));
>> +
>> + return true;
>> }
>>
>> void bt_map_client_unregister(void)
>> {
>> + DBG("");
>>
>> + ipc_unregister(hal_ipc, HAL_SERVICE_ID_MAP_CLIENT);
>> + hal_ipc = NULL;
>> }
>
> --
> Szymon K. Janc
> szymon.janc@gmail.com
Best regards,
Grzegorz
^ permalink raw reply
* Re: [PATCH bluetooth] Bluetooth: Fix missing channel unlock in l2cap_le_credits
From: Johan Hedberg @ 2014-10-14 8:38 UTC (permalink / raw)
To: Jukka Rissanen; +Cc: Martin Townsend, linux-bluetooth, marcel
In-Reply-To: <1413275501.2705.110.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
On Tue, Oct 14, 2014, Jukka Rissanen wrote:
> On ma, 2014-10-13 at 19:24 +0100, Martin Townsend wrote:
> > In the error case where credits is greater than max_credits there
> > is a missing l2cap_chan_unlock before returning.
> >
> > Signed-off-by: Martin Townsend <mtownsend1973@gmail.com>
> > ---
> > net/bluetooth/l2cap_core.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 46547b9..bfb6af8 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -5544,6 +5544,7 @@ static inline int l2cap_le_credits(struct l2cap_conn *conn,
> > if (credits > max_credits) {
> > BT_ERR("LE credits overflow");
> > l2cap_send_disconn_req(chan, ECONNRESET);
> > + l2cap_chan_unlock(chan);
> >
> > /* Return 0 so that we don't trigger an unnecessary
> > * command reject packet.
>
> I did some testing with this patch and although it did not fix the
> inconsistent lock issue I am seeing, it did fix the mutex hang. I have
> two locking issue and this patch fixed the other one.
When this code branch is taken it means that the remote side is not
behaving properly and is sending a ridiculous amount of credits. It's
worth investigating this further to fix such an issue (assuming that
other side is also running BlueZ).
> Tested-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Thanks for testing!
Johan
^ permalink raw reply
* Re: [PATCH v6 bluetooth-next] 6lowpan: Use skb_cow in IPHC decompression.
From: Alexander Aring @ 2014-10-14 8:38 UTC (permalink / raw)
To: Jukka Rissanen
Cc: Martin Townsend, Martin Townsend, linux-bluetooth, linux-wpan,
marcel
In-Reply-To: <1413275705.2705.114.camel@jrissane-mobl.ger.corp.intel.com>
Hi Jukka,
On Tue, Oct 14, 2014 at 11:35:05AM +0300, Jukka Rissanen wrote:
> Hi Alex,
>
> On ma, 2014-10-13 at 19:22 +0200, Alexander Aring wrote:
> > Hi Jukka,
> >
> > sorry.
> >
> > I was a little too fast here, because I am sure now this should solve your
> > lockdep issue.
>
> Unfortunately this patch did not help with the issue.
>
mhh, ok.
> >
> > On Mon, Oct 13, 2014 at 07:11:11PM +0200, Alexander Aring wrote:
> > > Hi Jukka,
> > >
> > > On Mon, Oct 13, 2014 at 06:09:14PM +0300, Jukka Rissanen wrote:
> > > > Hi Martin,
> > > >
> > > > On ma, 2014-10-13 at 15:56 +0100, Martin Townsend wrote:
> > > > > Hi Jukka,
> > > > >
> > > > > Does this patch help?
> > > >
> > > > Unfortunately no, I still see inconsistent lock state. It would probably
> > > > have been too easy :)
> > > >
> > >
> > > I remeber something, I think 802.15.4 had similar issues long time ago.
> > >
> > s/remeber/remember/
> >
> > > The fix was 20e7c4e80dcd01dad5e6c8b32455228b8fe9c619 ("6lowpan: fix
> > > lockdep splats"). Please check that, you need something like that!
> > >
> >
> > Something like that:
> >
> > diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> > index 4ebc806..02fd21a 100644
> > --- a/net/bluetooth/6lowpan.c
> > +++ b/net/bluetooth/6lowpan.c
> > @@ -642,7 +642,27 @@ static netdev_tx_t bt_xmit(struct sk_buff *skb, struct net_device *netdev)
> > return err < 0 ? NET_XMIT_DROP : err;
> > }
> >
> > +static struct lock_class_key bt_tx_busylock;
> > +static struct lock_class_key bt_netdev_xmit_lock_key;
> > +
> > +static void bt_set_lockdep_class_one(struct net_device *dev,
> > + struct netdev_queue *txq,
> > + void *_unused)
> > +{
> > + lockdep_set_class(&txq->_xmit_lock,
> > + &bt_netdev_xmit_lock_key);
> > +}
> > +
> > +
> > +static int bt_dev_init(struct net_device *dev)
> > +{
> > + netdev_for_each_tx_queue(dev, bt_set_lockdep_class_one, NULL);
> > + dev->qdisc_tx_busylock = &bt_tx_busylock;
> > + return 0;
> > +}
> > +
> > static const struct net_device_ops netdev_ops = {
> > + .ndo_init = bt_dev_init,
> > .ndo_start_xmit = bt_xmit,
> > };
> >
> >
> > - Alex
> >
> > [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=20e7c4e80dcd01dad5e6c8b32455228b8fe9c619
>
>
> Martin had an idea about the issue being related to work queues, I will
> investigate that further.
>
ok. The above one should fix if some dev_queue_xmit call another
dev_queue_xmit. Don't know if you have some architecture like this in
bluetooth.
- Alex
^ permalink raw reply
* Re: [PATCH v6 bluetooth-next] 6lowpan: Use skb_cow in IPHC decompression.
From: Jukka Rissanen @ 2014-10-14 8:35 UTC (permalink / raw)
To: Alexander Aring
Cc: Martin Townsend, Martin Townsend, linux-bluetooth, linux-wpan,
marcel
In-Reply-To: <20141013172229.GB25249@omega>
Hi Alex,
On ma, 2014-10-13 at 19:22 +0200, Alexander Aring wrote:
> Hi Jukka,
>
> sorry.
>
> I was a little too fast here, because I am sure now this should solve your
> lockdep issue.
Unfortunately this patch did not help with the issue.
>
> On Mon, Oct 13, 2014 at 07:11:11PM +0200, Alexander Aring wrote:
> > Hi Jukka,
> >
> > On Mon, Oct 13, 2014 at 06:09:14PM +0300, Jukka Rissanen wrote:
> > > Hi Martin,
> > >
> > > On ma, 2014-10-13 at 15:56 +0100, Martin Townsend wrote:
> > > > Hi Jukka,
> > > >
> > > > Does this patch help?
> > >
> > > Unfortunately no, I still see inconsistent lock state. It would probably
> > > have been too easy :)
> > >
> >
> > I remeber something, I think 802.15.4 had similar issues long time ago.
> >
> s/remeber/remember/
>
> > The fix was 20e7c4e80dcd01dad5e6c8b32455228b8fe9c619 ("6lowpan: fix
> > lockdep splats"). Please check that, you need something like that!
> >
>
> Something like that:
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 4ebc806..02fd21a 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -642,7 +642,27 @@ static netdev_tx_t bt_xmit(struct sk_buff *skb, struct net_device *netdev)
> return err < 0 ? NET_XMIT_DROP : err;
> }
>
> +static struct lock_class_key bt_tx_busylock;
> +static struct lock_class_key bt_netdev_xmit_lock_key;
> +
> +static void bt_set_lockdep_class_one(struct net_device *dev,
> + struct netdev_queue *txq,
> + void *_unused)
> +{
> + lockdep_set_class(&txq->_xmit_lock,
> + &bt_netdev_xmit_lock_key);
> +}
> +
> +
> +static int bt_dev_init(struct net_device *dev)
> +{
> + netdev_for_each_tx_queue(dev, bt_set_lockdep_class_one, NULL);
> + dev->qdisc_tx_busylock = &bt_tx_busylock;
> + return 0;
> +}
> +
> static const struct net_device_ops netdev_ops = {
> + .ndo_init = bt_dev_init,
> .ndo_start_xmit = bt_xmit,
> };
>
>
> - Alex
>
> [0] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=20e7c4e80dcd01dad5e6c8b32455228b8fe9c619
Martin had an idea about the issue being related to work queues, I will
investigate that further.
Cheers,
Jukka
^ permalink raw reply
* Re: [PATCH bluetooth] Bluetooth: Fix missing channel unlock in l2cap_le_credits
From: Jukka Rissanen @ 2014-10-14 8:31 UTC (permalink / raw)
To: Martin Townsend; +Cc: linux-bluetooth, marcel, johan.hedberg
In-Reply-To: <1413224685-3700-1-git-send-email-mtownsend1973@gmail.com>
Hi,
On ma, 2014-10-13 at 19:24 +0100, Martin Townsend wrote:
> In the error case where credits is greater than max_credits there
> is a missing l2cap_chan_unlock before returning.
>
> Signed-off-by: Martin Townsend <mtownsend1973@gmail.com>
> ---
> net/bluetooth/l2cap_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 46547b9..bfb6af8 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -5544,6 +5544,7 @@ static inline int l2cap_le_credits(struct l2cap_conn *conn,
> if (credits > max_credits) {
> BT_ERR("LE credits overflow");
> l2cap_send_disconn_req(chan, ECONNRESET);
> + l2cap_chan_unlock(chan);
>
> /* Return 0 so that we don't trigger an unnecessary
> * command reject packet.
I did some testing with this patch and although it did not fix the
inconsistent lock issue I am seeing, it did fix the mutex hang. I have
two locking issue and this patch fixed the other one.
Tested-by: Jukka Rissanen <jukka.rissanen@linux.intel.com>
Cheers,
Jukka
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox