To:     linux-bluetooth@vger.kernel.org,
        Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
From:   Arnaud Mouiche <arnaud.mouiche@invoxia.com>
Subject: Bug: no PropertiesChanged signal for
 org.bluez.Device1.AdvertisingData
Message-ID: <c23a8986-5654-275c-26a8-9f9a4bf5d005@invoxia.com>
Date:   Tue, 8 Jan 2019 17:03:29 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hello Luiz,

I was playing with latest sources (git) and experimental features 
enabled in order to:
- perform a BLE scan
- find AdvertisingData (in particularly the BT_AD_INDOOR_POSITIONING (0x25))

I found that:
- once scanning is done org.bluez.Device1.AdvertisingData is correctly 
set to the expected value (the one advertised)
- yet, there was no PropertiesChanged signal corresponding to this 
AdvertisingData property update (despite I received PropertiesChanged 
for RSSI)


Indeed src/device.c:: add_data() performs a particular filtering to only 
signal EIR_TRANSPORT_DISCOVERY data.

> static void add_data(void *data, void *user_data)
> {
>     struct eir_ad *ad = data;
>     struct btd_device *dev = user_data;
>
>     if (!bt_ad_add_data(dev->ad, ad->type, ad->data, ad->len))
>         return;
>
>     if (ad->type == EIR_TRANSPORT_DISCOVERY)
>         g_dbus_emit_property_changed(dbus_conn, dev->path,
>                         DEVICE_INTERFACE,
>                         "AdvertisingData");
> }

Is there a particular reason for this behavior ?

Regards,
Arnaud