Advertising a service but not connectable?

[Roger Clark]

I noticed while running a Bluetooth scanner app on my iPad, while testing one of my devices, that it was showing someone else's device in the locality.

What I found strange about this was that the device was not advertising as being connectable, but did advertise a service and had manufacturer data but also service data

{
    kCBAdvDataIsConnectable = 0;
    kCBAdvDataManufacturerData = <e0000104 ca525670>;
    kCBAdvDataServiceData =     {
        FE9F = <02425043 2d425f33 367a4877 0000015d db6deb30>;
    };
    kCBAdvDataServiceUUIDs =     (
        FE9F
    );
}

Could anyone tell, me why a device would advertise as having a service but not be connectable?

And why they have Service Data as well as manufacturer data

BTW. I noticed the service uuid also looks to be very strange number.

[Roger Clark]

Its not my code and I don't know what device is broadcasting it.

I have started to notice a lot of devices when I scan to check my code is working OK.

I think my neighbours must have bought some BLE equiped appliances, as one device has the name "Kitchen home" and one is a Samsung TV.

But the device in question does not have a name, and the service ID is not a standard code.

I was not aware that there was an advertising type called "Data service data", which appears to be similar to manufacturer data, but carries the overhead of the service ID.

I can't think why anyone would send both manufacturer data, in a private format, and also Data service data.

I have not run the packet sniffer to get the raw data, but I suspect it may not be sending the flags either, but that iOS has them by default in its data structure.

[RK]

yes I know it's not your code, your post was quite clear on that point. Service data is a standard data type which says "this is the actual value for this service" so a central can read data without connecting. It's generally not very useful because it only takes 16 bit UUIDs and thus can only be used for properly BLE registered services. In this case FE9F is registered to google so it's probably some google alexa spy device or something.

[Roger Clark]

Sorry.

I thought I made it clear it was not my device

" it was showing someone else's device in the locality."

Re: FE9F UUID

umm. I "googled" for that UUID and it didnt turn up any obvious hits

e.g.

site:www.bluetooth.org FE9F

finds nothing,

but

site:www.bluetooth.org 180A

finds the device information service.

I did now find it here,

sourceforge.net/.../uuid.c

but its not a definitive source.

Is there a definitive source where these services can be looked up, or is it a secret society ?

[RK]

why is there so much confusion here. I KNOW it's not your device. Nothing I have said says it's your device, all my replies have fully grokked that it is not your device, nor your code. I even corrected the other poster who thought it was your code. I know it's your neighbors device and you are scanning it. I wrote

he's scanning random devices and found one (which isn't his device nor coded by him) 

what's this about 'secret society'? FE9F is in the member assigned range (bluetooth org publishes the ranges) so you can just go right to that document if you know that, else all you need to do is type 'bluetooth FE9F' into google (amusingly enough) to find as the second link

www.bluetooth.com/.../16-bit-uuids-for-members

which has FE9F on it, belonging to google, and FEA0 as well.

[Roger Clark]

OK

I found it now.

www.bluetooth.com/.../16-bit-uuids-for-members

I have not looked at robots.txt on bluetooth.org, but its strange that google didn;t show this in its list and instead from some code on sourceforge.

Edit.

I take a general interest in the devices I happen to notice while scanning BLE when testing.

I have noticed a lot of Chinese made products advertise with unlisted 16 bit UUID,s in the range 7xxx

I now see that they do this because it appears that Bluetooth.org seem to allocate 16 bit services to members, starting from 0xFEFF descending, and the general purpose 16 bit uuids are much lower 16 bit numbers e.g 1800 upwards

So I presume the companies who used these unregistered 7xxx codes hop that Bluetooth.org will not allocate that range for many many years, why which time they will be long gone