is there any way to wirelessly detect a cell phone's model number?

[Isaac]

Hi,

Does anyone know if there is a way to wirelessly (esp. in close proximity)
get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.

TIA,
Isaac

[Richard B. Gilbert]

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close proximity)
get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?

Maybe you should start with the problem you are trying to solve!!

[R. Mark Clayton]

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

Imagine someone is a pickpocket.

Imagine someone wants to steal high value mobile phones (or the well filled
wallets of those carrying them).

Imagine why being able to detect such phones would give such a person an
advantage...

[Richard B. Gilbert]

Post by R. Mark Clayton

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

Imagine someone is a pickpocket.
Imagine someone wants to steal high value mobile phones (or the well filled
wallets of those carrying them).
Imagine why being able to detect such phones would give such a person an
advantage...

Well, that's a good reason NOT to give phones the ability to identify
themselves to strangers. Since, AFAIK, no cell phone has this
capability, perhaps this was thought of long ago.

[Isaac]

that is way too devious thinking here. They would already have to know
there was a high value Smartphone within a few feet, and be ready to mug the
person. You don't need a fancy scanning device to do that, they just watch
people use there fancy phones and follow them to mug them. I don't think
that is a real issue. Please advise on your ideas, though, on the
legitimate use I as about.

thanks again,
Isaac

Post by Richard B. Gilbert

Post by R. Mark Clayton

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

Imagine someone is a pickpocket.
Imagine someone wants to steal high value mobile phones (or the well
filled wallets of those carrying them).
Imagine why being able to detect such phones would give such a person an
advantage...

Well, that's a good reason NOT to give phones the ability to identify
themselves to strangers. Since, AFAIK, no cell phone has this capability,
perhaps this was thought of long ago.

[Chris Blunt]

On Sat, 06 Feb 2010 17:50:06 -0500, "Richard B. Gilbert"

Post by Richard B. Gilbert

Post by R. Mark Clayton

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

Imagine someone is a pickpocket.
Imagine someone wants to steal high value mobile phones (or the well filled
wallets of those carrying them).
Imagine why being able to detect such phones would give such a person an
advantage...

Well, that's a good reason NOT to give phones the ability to identify
themselves to strangers. Since, AFAIK, no cell phone has this
capability, perhaps this was thought of long ago.

I believe that a phone reveals its model number to a web site when it
connects via its mini-browser, so it not totally implausible.that it
may do something similar via Bluetooth.

Chris

[Isaac]

Chris, this is very interesting. The thought had crossed my since I see
full user IP and OS/browser configuration info at the bottom of form mail
submissions off websites.

I did a quick search on this and quick found that info for the mini-browser
at:
http://www.zytrax.com/tech/web/mobile_ids.html

They call that a "Mobile Browser ID (User-Agent) Strings".

Now that you have confirmed it is possible, I need to find out if it
actually and practically doable.

Unfortunately, I did not have any luck yet finding developer level info on
Bluetooth protocol/stack . Bluetooth.org requires a high level corporate
membership to get access to the Bluetooth specification.

Do you have any tips on how I might find at least top level info that
confirms Bluetooth can do it in general, and then icing on the cake would be
to know if all cell phones (esp. those w/o Internet capability) implement it
even if it is in the general specification.

Thanks a bunch!
Isaac

Post by Chris Blunt
On Sat, 06 Feb 2010 17:50:06 -0500, "Richard B. Gilbert"

Post by Richard B. Gilbert

Post by R. Mark Clayton

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I
need
to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

Imagine someone is a pickpocket.
Imagine someone wants to steal high value mobile phones (or the well filled
wallets of those carrying them).
Imagine why being able to detect such phones would give such a person an
advantage...

Well, that's a good reason NOT to give phones the ability to identify
themselves to strangers. Since, AFAIK, no cell phone has this
capability, perhaps this was thought of long ago.

I believe that a phone reveals its model number to a web site when it
connects via its mini-browser, so it not totally implausible.that it
may do something similar via Bluetooth.
Chris

[Isaac]

Thanks for your reply.

I was thinking that it might be built into phones that support various
Bluetooth devices. For example, if you had Bluetooth device (e.g., headset,
stereo headphones, larger sized remote keyboard, etc) with many options not
supported by all phones, then it could be helpful to offer the user an auto
configured profile having optimal settings for each phone model supported
(at the time) and load the one that matches there phone model.

I believe when a Bluetooth device registers with the cell phone it provides
its model number (isn't that what we see on the display when a connection is
established?). So, maybe there is a certain Bluetooth protocol that allows
that to go the other direction. I should mention that on many phones it is
almost impossible to find the model number, so such a Bluetooth device as I
describe could not rely on the user the manually entering the #, which is
why I need to have find an automatic, wireless way to get it.

Any ideas?

Thanks!
Isaac

Post by Richard B. Gilbert

Post by Isaac
Hi,
Does anyone know if there is a way to wirelessly (esp. in close
proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.
TIA,
Isaac

I'm inclined to doubt it! Why would anyone need the model of someone
else's phone?? Why would the manufacturer build such a capability into
the phone? How could he justify the cost of doing so?
Maybe you should start with the problem you are trying to solve!!

[Richard B. Gilbert]

Post by Isaac
Thanks for your reply.
I was thinking that it might be built into phones that support various
Bluetooth devices. For example, if you had Bluetooth device (e.g., headset,
stereo headphones, larger sized remote keyboard, etc) with many options not
supported by all phones, then it could be helpful to offer the user an auto
configured profile having optimal settings for each phone model supported
(at the time) and load the one that matches there phone model.
I believe when a Bluetooth device registers with the cell phone it provides
its model number (isn't that what we see on the display when a connection is
established?). So, maybe there is a certain Bluetooth protocol that allows
that to go the other direction. I should mention that on many phones it is
almost impossible to find the model number, so such a Bluetooth device as I
describe could not rely on the user the manually entering the #, which is
why I need to have find an automatic, wireless way to get it.
Any ideas?

I'm not familiar with Bluetooth devices. . . . I have hearing aids in
both ears so there's very little room in my life for a Bluetooth dongle.

I don't talk on the phone so much that holding it to my ear is any hardship!

YMMV!

[John Henderson]

Post by Isaac
Does anyone know if there is a way to wirelessly (esp. in close proximity)
get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.

Yes, via Bluetooth if activated, but only if the two devices are
paired. Then use the command "AT+CGMI" (manufacturer) and
"AT+CGMM" (model) via an SPP (Serial Port Profile) session.

Alternatively, as above via IrDA without pairing. But very short
range line-of-sight. And IrDA support is rare these days.

John H

[Isaac]

John, this is extremely helpful!

It seems perfect, however, I did a quick Google search and came across an
apparent issue. That is,
apparently an application may connect to a cell phone via Bluetooth for the
purpose of sending AT commands via Serial Port service (SPS) (UUID 0x1101)
and/or the Dial-Up Networking service (DUNS) (UUID 0x1103); however, is the
SPS generally intended for use with the AT command set, or does it just does
it work sometimes but with no guarantee. It seems that using AT commands
with a DUNS may be more guaranteed to always be supported (given the history
of AT commands being used for modem control).
In short, is the AT command set you indicate supported on all cell phones
with a basic Bluetooth capability (e.g., ones that only support Bluetooth
headsets), or is it only guaranteed support on advanced phones (e.g., 3G,
smartphones, etc.)?

Thanks a million!
Isaac

Post by John Henderson

Is there a way to wirelessly (esp. in close proximity) get/read a cell
phone's model number; e.g., maybe like by using Bluetooth, etc? I need
to
find a way to do this so any ideas or helpful pointers would be greatly
appreciated.

Yes, via Bluetooth if activated, but only if the two devices are
paired. Then use the command "AT+CGMI" (manufacturer) and
"AT+CGMM" (model) via an SPP (Serial Port Profile) session.
Alternatively, as above via IrDA without pairing. But very short
range line-of-sight. And IrDA support is rare these days.
John H

[John Henderson]

Post by Isaac
John, this is extremely helpful!
It seems perfect, however, I did a quick Google search and came across an
apparent issue. That is,
apparently an application may connect to a cell phone via Bluetooth for the
purpose of sending AT commands via Serial Port service (SPS) (UUID 0x1101)
and/or the Dial-Up Networking service (DUNS) (UUID 0x1103); however, is the
SPS generally intended for use with the AT command set, or does it just does
it work sometimes but with no guarantee. It seems that using AT commands
with a DUNS may be more guaranteed to always be supported (given the history
of AT commands being used for modem control).
In short, is the AT command set you indicate supported on all cell phones
with a basic Bluetooth capability (e.g., ones that only support Bluetooth
headsets), or is it only guaranteed support on advanced phones (e.g., 3G,
smartphones, etc.)?

My feeling is that either SPS or DUNS will do the job, and that
virtually all phones with Bluetooth capability will support both.

The ability to send SMS text messages via a desktop application
is fairly standard these days on Bluetooth phones, and always
uses SPS as far as I know.

There's no guarantee that any of this will work with untried
devices. You'll find an "Implementation: optional" rider on
features you'll depend on.

John

[Isaac]

I see. That is very encouraging.

Do you happen to know if there is a way to use these AT commands without
pairing first? Or, if there is another way to get the model info without
pairing. My problem is that the application I am working on needs to first
determine if the phone is supported (i.e., by first knowing the model
number) before conditionally proceeding to the pairing process. So, I'm in a
kind of a catch-22. I'm hoping there is maybe some protocol or option
whereby this
basic device info can be requested as part of the initial connection
establishment steps, but before going through the security procedure and
pairing. It would be great to have a Bluetooth option as in IrDA, which
allows AT commands without pairing.

TIA,
Isaac

Post by John Henderson

Post by Isaac
John, this is extremely helpful!
It seems perfect, however, I did a quick Google search and came across an
apparent issue. That is,
apparently an application may connect to a cell phone via Bluetooth for the
purpose of sending AT commands via Serial Port service (SPS) (UUID 0x1101)
and/or the Dial-Up Networking service (DUNS) (UUID 0x1103); however, is the
SPS generally intended for use with the AT command set, or does it just does
it work sometimes but with no guarantee. It seems that using AT commands
with a DUNS may be more guaranteed to always be supported (given the history
of AT commands being used for modem control).
In short, is the AT command set you indicate supported on all cell phones
with a basic Bluetooth capability (e.g., ones that only support Bluetooth
headsets), or is it only guaranteed support on advanced phones (e.g., 3G,
smartphones, etc.)?

My feeling is that either SPS or DUNS will do the job, and that
virtually all phones with Bluetooth capability will support both.
The ability to send SMS text messages via a desktop application
is fairly standard these days on Bluetooth phones, and always
uses SPS as far as I know.
There's no guarantee that any of this will work with untried
devices. You'll find an "Implementation: optional" rider on
features you'll depend on.
John

[John Henderson]

Post by Isaac
Do you happen to know if there is a way to use these AT commands without
pairing first?

As far as I'm aware, the only thing you can do without pairing is
read the Bluetooth address, name and protocol/class of visible
devices within range.

By "visible devices" I mean active Bluetooth devices with
visibility (inquiry scan mode) turned on.

I'm far from being an expert in this esoteric field, but I doubt
that a decode of the Bluetooth protocol field will give you
anything like enough information. It's three bytes, giving
major service class, major device class, and minor device
class. But you might turn up some possibilities I haven't
encountered.

Post by Isaac
It would be great to have a Bluetooth option as in IrDA, which allows AT commands without pairing.

That would be a major security flaw. You would have immediate
access to most functionality, if PIN security wasn't active on
the phone. With IrDA, you've really got to intend to make a
connection, because the range is so limited.

John

[Isaac]

Post by John Henderson

Post by Isaac
Do you happen to know if there is a way to use these AT commands without
pairing first?

As far as I'm aware, the only thing you can do without pairing is
read the Bluetooth address, name and protocol/class of visible
devices within range.
By "visible devices" I mean active Bluetooth devices with
visibility (inquiry scan mode) turned on.
I'm far from being an expert in this esoteric field, but I doubt
that a decode of the Bluetooth protocol field will give you
anything like enough information. It's three bytes, giving
major service class, major device class, and minor device
class. But you might turn up some possibilities I haven't
encountered.

this sounds right, but I will post anything else I might discover.

Post by John Henderson

Post by Isaac
It would be great to have a Bluetooth option as in IrDA, which allows AT
commands without pairing.

That would be a major security flaw. You would have immediate
access to most functionality, if PIN security wasn't active on
the phone.

Are you aware of any partial access (i.e., "gray") security levels whereby
you don't have to do full pairing but can get authorized for limited
connectivity (like some kind of a "sandbox" mode) to at least do some basic
AT commands like make/model discovery, or is it full phone system/profile
access/control or nothing? I ask this because, as a fall back, it would be
much more acceptable to the user if the app would first confirm phone model
support without any privacy/security issues and the user then can decide on
allowing full access if there phone is supported. Maybe there are different
Bluetooth stack profiles that allow this (e.g., file sharing, etc.). I
would think that if Bluetooth is supposed to be a generic wireless
connection protocol to support all kind of devices and 3rd party
applications it should have at least some gray levels off security access,
not just black or white. I need to offer the user a 100% safe (no risk) way
to first determine if their phone is supported by my App before they decide
on allowing any (esp. full) pairing. Any thoughts on this?

Post by John Henderson
With IrDA, you've really got to intend to make a
connection, because the range is so limited.

that makes sense.


Thanks a million!
Isaac

Post by John Henderson
John

[John Henderson]

Post by Isaac
Are you aware of any partial access (i.e., "gray") security levels whereby
you don't have to do full pairing but can get authorized for limited
connectivity (like some kind of a "sandbox" mode) to at least do some basic
AT commands like make/model discovery, or is it full phone system/profile
access/control or nothing? I ask this because, as a fall back, it would be
much more acceptable to the user if the app would first confirm phone model
support without any privacy/security issues and the user then can decide on
allowing full access if there phone is supported. Maybe there are different
Bluetooth stack profiles that allow this (e.g., file sharing, etc.). I
would think that if Bluetooth is supposed to be a generic wireless
connection protocol to support all kind of devices and 3rd party
applications it should have at least some gray levels off security access,
not just black or white. I need to offer the user a 100% safe (no risk) way
to first determine if their phone is supported by my App before they decide
on allowing any (esp. full) pairing. Any thoughts on this?

I'm not aware of anything like that.

You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol.

If you could rely on people not changing the Bluetooth name,
then that often carries model information. If I scan in a busy
place, I see recurring protocol, name combinations like:

200408 Nokia CK-7W
5A0204 SGH-A561

along with lots of customized names, of course.

John

[Isaac]

Hey John,

The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can be
change, which I assume few people do. Even better, though, I searched this
further and found the below info, which indicates that any Bluetooth device
will give, among other technical info, the make and model of the phone on
demand as part of a discovery mode inquiry. This is *exactly* what I need!
It is not clear to me if the AT Commands will work or if it a certain
Bluetooth program script protocol. That is, do you happen to know what is
the method/mode to properly inquire and access this public Bluetooth device
info during a discovery mode inquiry? Bluejacking or a modern, legit
version is interesting too if it is possible for my App to send the
prospective user a pop-up text message stating something like "Please wait
while we determine if your phone is supported"... then "your phone is
supported, please ....". However, sending text messages w/o pairing would
be icing on the cake, though.
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following
information on demand:

a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)
Any device may perform an inquiry to find other devices to connect to, and
any device can be configured to respond to such inquiries. However, if the
device trying to connect knows the address of the device, it always responds
to direct connection requests and transmits the information shown in the
list above if requested. Use of a device's services may require pairing or
acceptance by its owner, but the connection itself can be initiated by any
device and held until it goes out of range. Some devices can be connected to
only one device at a time, and connecting to them prevents them from
connecting to other devices and appearing in inquiries until they disconnect
from the other device.

Every device has a unique 48-bit address. However, these addresses are
generally not shown in inquiries. Instead, friendly Bluetooth names are
used, which can be set by the user. This name appears when another user
scans for devices and in lists of paired devices.

Most phones have the Bluetooth name set to the manufacturer and model of the
phone by default. Most phones and laptops show only the Bluetooth names and
special programs are required to get additional information about remote
devices. This can be confusing as, for example, there could be several
phones in range named T610 (see Bluejacking).

---------------

Thanks,
Ariel-

Post by John Henderson

Post by Isaac
Are you aware of any partial access (i.e., "gray") security levels whereby
you don't have to do full pairing but can get authorized for limited
connectivity (like some kind of a "sandbox" mode) to at least do some basic

<snip>

Post by John Henderson
I'm not aware of anything like that.
You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol.
If you could rely on people not changing the Bluetooth name,
then that often carries model information. If I scan in a busy
200408 Nokia CK-7W
5A0204 SGH-A561
along with lots of customized names, of course.
John

[John Henderson]

Post by Isaac
Hey John,
The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can be
change, which I assume few people do.

I'd estimate that more than half do personalize the name in my
part of the world.

Post by Isaac
Even better, though, I searched this
further and found the below info, which indicates that any Bluetooth device
will give, among other technical info, the make and model of the phone on
demand as part of a discovery mode inquiry. This is *exactly* what I need!
It is not clear to me if the AT Commands will work or if it a certain
Bluetooth program script protocol. That is, do you happen to know what is
the method/mode to properly inquire and access this public Bluetooth device
info during a discovery mode inquiry? Bluejacking or a modern, legit
version is interesting too if it is possible for my App to send the
prospective user a pop-up text message stating something like "Please wait
while we determine if your phone is supported"... then "your phone is
supported, please ....". However, sending text messages w/o pairing would
be icing on the cake, though.

You can open a socket and send some text to a Bluetooth phone.
On my Samsung phone at least, it disappears into a black hole.

You can also send some text in the form of a business card, which
is usually handled better.

Post by Isaac
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following
a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)

Using the bluetooth.discover_devices() function followed by the
bluetooth.find_service() query to the specific discovered
addresses from the following Python module, I get no manufacturer
or model info returned in the dictionaries specified.

http://org.csail.mit.edu/pybluez/docs-0.6/bluetooth.html#DeviceDiscoverer

I get results like this from bluetooth.find_service() when
connecting to 00:23:39:9F:BA:8A.

Host: 00:23:39:9F:BA:8A
Name: Serial Server
Description: None
Protocol: RFCOMM
Provider: None
Port: 4
Service id: None
Service-classes: ['1101']
Profiles: [('1101', 256)]

That's my own Samsung phone's host address, so I have no qualms
about making it public. My Siemens and Sony Ericsson phones
likewise return no make or model info in this way.

If there's more to be found, I haven't found it.

John

[Isaac]

Post by John Henderson

Post by Isaac
Hey John,
The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can be
change, which I assume few people do.

I'd estimate that more than half do personalize the name in my
part of the world.

bummer

<snip>

Post by John Henderson

Post by Isaac
supported, please ....". However, sending text messages w/o pairing would
be icing on the cake, though.

You can open a socket and send some text to a Bluetooth phone.
On my Samsung phone at least, it disappears into a black hole.
You can also send some text in the form of a business card, which
is usually handled better.

this could be helpful. Thanks.

Post by John Henderson

Post by Isaac
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following

<snip>

Post by John Henderson

Post by Isaac
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)

Using the bluetooth.discover_devices() function followed by the
bluetooth.find_service() query to the specific discovered
addresses from the following Python module, I get no manufacturer
or model info returned in the dictionaries specified.
http://org.csail.mit.edu/pybluez/docs-0.6/bluetooth.html#DeviceDiscoverer
I get results like this from bluetooth.find_service() when
connecting to 00:23:39:9F:BA:8A.
Host: 00:23:39:9F:BA:8A
Name: Serial Server
Description: None
Protocol: RFCOMM
Provider: None
Port: 4
Service id: None
Service-classes: ['1101']
Profiles: [('1101', 256)]
That's my own Samsung phone's host address, so I have no qualms
about making it public. My Siemens and Sony Ericsson phones
likewise return no make or model info in this way.
If there's more to be found, I haven't found it.

I get the sense that what you point to above is a first step in that
direction. However, I did a little checking and it seems like there is a
standard way to get the make/model info under the SDP (Service discovery
protocol) that all Bluetooth devices must support. Check this out and let me
know what you think:
http://trifinite.org/Downloads/Blueprinting.pdf

It is vintage 2005 so it is a bit dated; however, it clearly states:

"With Blueprinting it is possible to determine the manufacturer, the device
model and the firmware version of the respective device. The complexity of
the introduced method is intentionally simple so that this procedure can be
executed on constrained devices that are not capable of calculating common
hashes such as MD5: the J2ME Connected Limited Device Configuration (CLDC)
Version 1.0 (as used in many mobile handsets) can perform it.
...
One of the purposes that Blueprinting could be used for is statistical
examination of different environments. This way, it is possible to create
statistics over manufacturer and device models in special places as it was
done in the CeBIT field trial report [1].
...
Blueprinting is combining the different information that Bluetooth-enabled
devices reveal in order to identify the manufacturer as well
as the model of the device.
....
Therefore, for identifying a manufacturer's model, Blueprinting takes the
SDP [8] profiles, which can be queried from devices that offer services,
into account"

So, there seems to be a simple way to do it at least back in 2005. Do you
have any thoughts on this? I'll keep digging...

Thanks!
Isaac

[John Henderson]

Post by Isaac
I get the sense that what you point to above is a first step in that
direction. However, I did a little checking and it seems like there is a
standard way to get the make/model info under the SDP (Service discovery
protocol) that all Bluetooth devices must support. Check this out and let me
http://trifinite.org/Downloads/Blueprinting.pdf

That's a nice find.

It says that the manufacturer can be determined from the
Bluetooth address, as I suggested a few replies ago when I wrote:

"You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol."

The model apparently gets interpolated from the likes of data
returned by the bluetooth.find_service() function from the
Python PyBluez module I mentioned. But it looks like you're going
to have to build and maintain your own lookup tables to enable
this. New model phones come out quite often.

You need to code up some programs and start experimenting with
the data you find.

John

[Isaac]

Post by John Henderson

Post by Isaac
I get the sense that what you point to above is a first step in that
direction. However, I did a little checking and it seems like there is a
standard way to get the make/model info under the SDP (Service discovery
protocol) that all Bluetooth devices must support. Check this out and let me
http://trifinite.org/Downloads/Blueprinting.pdf

That's a nice find.

very glad this nailed it for you (and me!).

Post by John Henderson
It says that the manufacturer can be determined from the
"You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol."

Yeah, like I mentioned back then I did not understand what you meant.

Post by John Henderson
The model apparently gets interpolated from the likes of data
returned by the bluetooth.find_service() function from the
Python PyBluez module I mentioned.

Awesome! This makes perfect sense now, and tracks with all the info I've
learned to date. Thanks a million!

Post by John Henderson
But it looks like you're going
to have to build and maintain your own lookup tables to enable
this. New model phones come out quite often.

Yes, this is a bummer, though, because it is not clear how I could be sure
to get bluetooth addresses for every new phone constantly released. I
wonder if the manufacturers provide this info or maybe some online
dbase/service/resource. Again, you've been such a help!

Post by John Henderson
You need to code up some programs and start experimenting with
the data you find.

Will do! Actually, if your interested, check this out:
http://trifinite.org/Downloads/bp_v01-3.zip

This seems like the *actual* Pearl code they used to identify Bluetooth
devices. Maybe that can work "out of the box".

This has all been very enlightening!

Cheers!
Isaac

Post by John Henderson
John

[John Henderson]

Post by Isaac
Yes, this is a bummer, though, because it is not clear how I could be sure
to get bluetooth addresses for every new phone constantly released. I
wonder if the manufacturers provide this info or maybe some online
dbase/service/resource.

I think the best way to approach this is to become more or less
self-sufficient.

Constantly or periodically scan for new visible devices. That
will give you the Bluetooth addresses, the protocols, and
possibly the names (although my experience is that reading the
name requires the device to be "in view" for longer").

If you find any addresses for which you don't have a
manufacturer, approach the owner for that information (assuming
you can within the context of your application).

Post by Isaac
http://trifinite.org/Downloads/bp_v01-3.zip
This seems like the *actual* Pearl code they used to identify Bluetooth
devices. Maybe that can work "out of the box".

Agreed, that's what it looks like. But I find Perl a very
difficult language to comprehend.

John

[Isaac]

Post by John Henderson

Post by Isaac
Yes, this is a bummer, though, because it is not clear how I could be sure
to get bluetooth addresses for every new phone constantly released. I
wonder if the manufacturers provide this info or maybe some online
dbase/service/resource.

I think the best way to approach this is to become more or less
self-sufficient.
Constantly or periodically scan for new visible devices. That
will give you the Bluetooth addresses, the protocols, and
possibly the names (although my experience is that reading the
name requires the device to be "in view" for longer").

I was thinking the same way, but it seems like an impossible task to keep up
with constant and large # of new models always coming out from so many
different makers. Do you think the manufacturers would provide the model's
BD_ADDR base digits to developers/companies for legitimate commercial use,
or is that secret/closely held info?

Post by John Henderson
If you find any addresses for which you don't have a
manufacturer, approach the owner for that information (assuming
you can within the context of your application).

that could work if was just one BT device in range, however, how would you
ID a particular owner from a list of BT names within range, which should be
the common case since you'd have to go to dense cell phone areas to even
have a chance to efficiently catch new phone models.

Post by John Henderson

Post by Isaac
http://trifinite.org/Downloads/bp_v01-3.zip
This seems like the *actual* Pearl code they used to identify Bluetooth
devices. Maybe that can work "out of the box".

Agreed, that's what it looks like. But I find Perl a very
difficult language to comprehend.

I take it that Python is the best in your opinion. I looked at the Python
bluetooth module you pointed to. I see a function named "find_devices()".
It mentions "ADVANCED PARAMETERS". I wonder if there are any cool options
there to dig deeper into a BT device's technical info. This site you
pointed to said that DeviceDiscoverer class is a "Skeleton class". Do you
think maybe there are more in-depth BT device inquiry/discovery functions
available somewhere else?

thanks,
Isaac

Post by John Henderson
John

[John Henderson]

Post by Isaac
I was thinking the same way, but it seems like an impossible task to keep up
with constant and large # of new models always coming out from so many
different makers. Do you think the manufacturers would provide the model's
BD_ADDR base digits to developers/companies for legitimate commercial use,

I doubt it.

Post by Isaac
that could work if was just one BT device in range, however, how would you
ID a particular owner from a list of BT names within range, which should be
the common case since you'd have to go to dense cell phone areas to even
have a chance to efficiently catch new phone models.

Request a session with the new device, pair with it, and read off
and store the manufacturer and model info with the standard "AT"
commands. This requires the cooperation of the new device's
owner, of course.

Post by Isaac
I take it that Python is the best in your opinion. I looked at the Python
bluetooth module you pointed to. I see a function named "find_devices()".
It mentions "ADVANCED PARAMETERS". I wonder if there are any cool options
there to dig deeper into a BT device's technical info. This site you
pointed to said that DeviceDiscoverer class is a "Skeleton class". Do you
think maybe there are more in-depth BT device inquiry/discovery functions
available somewhere else?

Maybe. I simply don't know.

John

[Isaac]

Post by John Henderson

Post by Isaac
I was thinking the same way, but it seems like an impossible task to keep up
with constant and large # of new models always coming out from so many
different makers. Do you think the manufacturers would provide the model's
BD_ADDR base digits to developers/companies for legitimate commercial use,

I doubt it.

Post by Isaac
that could work if was just one BT device in range, however, how would you
ID a particular owner from a list of BT names within range, which should be
the common case since you'd have to go to dense cell phone areas to even
have a chance to efficiently catch new phone models.

Request a session with the new device, pair with it, and read off
and store the manufacturer and model info with the standard "AT"
commands. This requires the cooperation of the new device's
owner, of course.

Now, who is the "glass half full type"?? :) People in a public space would
never let a 3rd party app or person to pair with there device. If people
allowed that in general, I would have no problem to begin with because I
could have my app request pairing and then do AT commands as you say. That
would be awesome and a no brainer, but many, if not most, people are afraid
of the security risk and won't allow it. Correct me, though, if you think
I'm wrong.

Post by John Henderson

Post by Isaac
I take it that Python is the best in your opinion. I looked at the Python
bluetooth module you pointed to. I see a function named
"find_devices()".
It mentions "ADVANCED PARAMETERS". I wonder if there are any cool options
there to dig deeper into a BT device's technical info. This site you
pointed to said that DeviceDiscoverer class is a "Skeleton class". Do you
think maybe there are more in-depth BT device inquiry/discovery functions
available somewhere else?

Maybe. I simply don't know.

confirmed.

Post by John Henderson
John

[John Henderson]

Post by Isaac
Now, who is the "glass half full type"?? :) People in a public space would
never let a 3rd party app or person to pair with there device. If people
allowed that in general, I would have no problem to begin with because I
could have my app request pairing and then do AT commands as you say. That
would be awesome and a no brainer, but many, if not most, people are afraid
of the security risk and won't allow it. Correct me, though, if you think
I'm wrong.

Agreed. But previously you hadn't been so explicit about what
you're intending to do.

Still, you could try sending a message to come and see you, and
maybe get something for their trouble.

John

[John Henderson]

Post by John Henderson
Agreed. But previously you hadn't been so explicit about what
you're intending to do.

Unless it's a secret, maybe you could also tell us why you need
manufacturer and model information. That might lead to other
suggestions.

John

[Isaac]

John, I'd rather not post the exact details of my app, but generally, it is
a hardware (HW) app in a public setting that needs to physically interact
with (most) any cell phones. However, how it mechanically does that
completely depends on the phone model. If the user's phone is supported
then they would use my HW app. So, I need to automatically determine phone
model numbers to first tell the prospective user that there phone is
supported, and then configure the HW to work with their phone. As a 3rd
party HW app in a public setting, pairing is not something most people would
be comfortable doing; hence, the need for inquiry mode model # discovery, or
some other non-pairing means. I think this should be specific enough.
Please ask where more details would be helpful.

Thanks again,
Isaac

Post by John Henderson

Post by John Henderson
Agreed. But previously you hadn't been so explicit about what
you're intending to do.

Unless it's a secret, maybe you could also tell us why you need
manufacturer and model information. That might lead to other
suggestions.
John

[Isaac]

Bluejacking a message like "I'll give you $10 if you tell me your phone's
model #. See me at ..." seems like a plausible, good idea, but, at best,
only works for discoverable devices, which, unfortunately, seem to be
generally only ~10% of BT phones. So, it would be a painfully slow rate
(maybe < 3% respondents, and <.3% to catch unknown models) of learning the
base codes in BD_ADDR for new phone models. Moreover, it s unclear how many
different venues and how much time would be need to even cover the most
popular new models, let alone the less common, yet significant ones. Seems
like a daunting task.

Why do you suspect that manufacturers would not be freely willing to share
this info? It seems very benign from their point of view. I can see,
however, why the carriers would want to block that. Carriers hate the fact
BT allows from free connectivity so they would want to block anything that
makes it easier for better BT apps and services.

Thanks,
Isaac

Post by John Henderson

Post by Isaac
Now, who is the "glass half full type"?? :) People in a public space would
never let a 3rd party app or person to pair with there device. If people
allowed that in general, I would have no problem to begin with because I
could have my app request pairing and then do AT commands as you say.
That
would be awesome and a no brainer, but many, if not most, people are afraid
of the security risk and won't allow it. Correct me, though, if you think
I'm wrong.

Agreed. But previously you hadn't been so explicit about what
you're intending to do.
Still, you could try sending a message to come and see you, and
maybe get something for their trouble.
John

[John Henderson]

Post by Isaac
Why do you suspect that manufacturers would not be freely willing to share
this info?

A long career as an analyst/programmer who's had trouble getting
information from manufacturers. You've often got to
reverse-engineer things to get informtion, or devise some other
way of helping yourself to get what you want.

Post by Isaac
It seems very benign from their point of view.

It's in the spirit of free-enterprise that you can get anything
you want if you offer a good-enough price.

Seriously, what's in it for them to give you that information for
free? The possibility of legal threats from you if you find an
error?

John

[Isaac]

OK, you convinced me that glass is half empty!!! ;-(

Post by John Henderson

Post by Isaac
Why do you suspect that manufacturers would not be freely willing to share
this info?

A long career as an analyst/programmer who's had trouble getting
information from manufacturers. You've often got to
reverse-engineer things to get informtion, or devise some other
way of helping yourself to get what you want.

Post by Isaac
It seems very benign from their point of view.

It's in the spirit of free-enterprise that you can get anything
you want if you offer a good-enough price.
Seriously, what's in it for them to give you that information for
free? The possibility of legal threats from you if you find an
error?
John

[Isaac]

After more digging, I came across something that made me think about this
post. That is, it turns out that the BlueZ open source Bluetooth stack
(which BTW the Android uses) supports the BT 2.1 EIR spec. It supported EIR
device names from as far back as version 3.6 (currently its at ver 4.6), so
this should be a well supported feature by now in BlueZ. Here are the
revision history snips I farmed wrt EIR fixes (got it at BlueZ in Maemo
Bluetooth):
=================
ver 4.28: Set the adapter alias only after checking the EIR data.ver 3.6:
Add initial support for device names via EIR.ver 3.21: Publish device id
information through EIR.ver 3.18: Add more detailed decoding of EIR
elements.ver 3.16: Set EIR information from SDP database.ver 3.14: Add
correct Simple Pairing and EIR interaction.===================Now, I came
across another bit of info that links BlueZ to Python, which is what you
mentioned before. An app called "Blueman " at:
http://linux.softpedia.com/get/Utilities/Blueman-30673.shtmlsays "Blueman is
a GTK+ bluetooth management utility for GNOME using bluez dbus backend. The
aim is to create a full featured graphical bluetooth manager for
Linux."Unfortunately, I do not have access to a unix machine so I cannot try
"Blueman" to see if it gives EIR data. Do you know of a windows
version?Also, among other things it requires "Requirements: · GTK+ >= 2.8.x,
· python-bluez"So, it seems that "python-bluez" indeed might be what I'm
looking for to get phone model number info. However, pyblues is EXACTLY
what you sent me before! Maybe you can now better tell, based on the above
info, where I might look in pybluez to find functions that can get the
extended inquiry response (EIR) data elements?I'm real close now. I'm hoping
for some luck here.Thanks again!Isaac"John Henderson"

Post by John Henderson

Post by Isaac
I was thinking the same way, but it seems like an impossible task to keep up
with constant and large # of new models always coming out from so many
different makers. Do you think the manufacturers would provide the model's
BD_ADDR base digits to developers/companies for legitimate commercial use,

I doubt it.

Post by Isaac
that could work if was just one BT device in range, however, how would you
ID a particular owner from a list of BT names within range, which should be
the common case since you'd have to go to dense cell phone areas to even
have a chance to efficiently catch new phone models.

Request a session with the new device, pair with it, and read off
and store the manufacturer and model info with the standard "AT"
commands. This requires the cooperation of the new device's
owner, of course.

Post by Isaac
I take it that Python is the best in your opinion. I looked at the Python
bluetooth module you pointed to. I see a function named
"find_devices()".
It mentions "ADVANCED PARAMETERS". I wonder if there are any cool options
there to dig deeper into a BT device's technical info. This site you
pointed to said that DeviceDiscoverer class is a "Skeleton class". Do you
think maybe there are more in-depth BT device inquiry/discovery functions
available somewhere else?

Maybe. I simply don't know.
John

[John Henderson]

Post by Isaac
After more digging, I came across something that made me think about this
post. That is, it turns out that the BlueZ open source Bluetooth stack
(which BTW the Android uses) supports the BT 2.1 EIR spec. It supported EIR
device names from as far back as version 3.6 (currently its at ver 4.6), so
this should be a well supported feature by now in BlueZ. Here are the
revision history snips I farmed wrt EIR fixes (got it at BlueZ in Maemo
=================
Add initial support for device names via EIR.ver 3.21: Publish device id
information through EIR.ver 3.18: Add more detailed decoding of EIR
elements.ver 3.16: Set EIR information from SDP database.ver 3.14: Add
correct Simple Pairing and EIR interaction.===================Now, I came
across another bit of info that links BlueZ to Python, which is what you
http://linux.softpedia.com/get/Utilities/Blueman-30673.shtmlsays "Blueman is
a GTK+ bluetooth management utility for GNOME using bluez dbus backend. The
aim is to create a full featured graphical bluetooth manager for
Linux."Unfortunately, I do not have access to a unix machine so I cannot try
"Blueman" to see if it gives EIR data. Do you know of a windows
version?Also, among other things it requires "Requirements: · GTK+ >= 2.8.x,
· python-bluez"So, it seems that "python-bluez" indeed might be what I'm
looking for to get phone model number info. However, pyblues is EXACTLY
what you sent me before! Maybe you can now better tell, based on the above
info, where I might look in pybluez to find functions that can get the
extended inquiry response (EIR) data elements?I'm real close now. I'm hoping
for some luck here.Thanks again!Isaac"

As far as I can see, EIR is what is giving us the
user-modifiable device name already. This is not the holy grail
you're looking for.

John

[Isaac]

No. Those are the "friendly names" that BT Spec 2.0 (at least) supported.
EIR when available is a deeper set of technical data meant to enable BT
device Plug-and-Play and/or to help filter out BT devices before pairing.
The "friendly" BT names, as you remark, are pretty useless b/c most people
change them.

Post by John Henderson

Post by Isaac
After more digging, I came across something that made me think about this
post. That is, it turns out that the BlueZ open source Bluetooth stack
(which BTW the Android uses) supports the BT 2.1 EIR spec. It supported EIR
device names from as far back as version 3.6 (currently its at ver 4.6), so
this should be a well supported feature by now in BlueZ. Here are the
revision history snips I farmed wrt EIR fixes (got it at BlueZ in Maemo

<snip>

Post by John Henderson

Post by Isaac
info, where I might look in pybluez to find functions that can get the
extended inquiry response (EIR) data elements?I'm real close now. I'm hoping
for some luck here.Thanks again!Isaac"

As far as I can see, EIR is what is giving us the
user-modifiable device name already. This is not the holy grail
you're looking for.
John

[John Henderson]

Post by Isaac
No. Those are the "friendly names" that BT Spec 2.0 (at least) supported.
EIR when available is a deeper set of technical data meant to enable BT
device Plug-and-Play and/or to help filter out BT devices before pairing.
The "friendly" BT names, as you remark, are pretty useless b/c most people
change them.

I note your answer without agreeing with it.

John

[Isaac]

See here:
http://trifinite.org/trifinite_stuff_blueprinting.html#method

where it says:
Service Discovery Protocol Records
Every Bluetooth-enabled device that offers services to other
Bluetooth-enabled devices does announce these services via the service
discovery protocol (SDP). So, remote devices can query devices upon the
offered capabilities. SDP records are returned to the querying device and
hold information on how to access the respective service. Our method now
hashes certain values out of the records and calculates a fingerprint value
that then is used in order to refer to the respective model.

===========

I wonder if this is reliable, or just a heuristic that does not always work.
I'll keep digging.

Thanks,
Isaac-

Post by John Henderson

Post by Isaac
Hey John,
The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can be
change, which I assume few people do.

I'd estimate that more than half do personalize the name in my
part of the world.

Post by Isaac
Even better, though, I searched this
further and found the below info, which indicates that any Bluetooth device
will give, among other technical info, the make and model of the phone on
demand as part of a discovery mode inquiry. This is *exactly* what I need!
It is not clear to me if the AT Commands will work or if it a certain
Bluetooth program script protocol. That is, do you happen to know what is
the method/mode to properly inquire and access this public Bluetooth device
info during a discovery mode inquiry? Bluejacking or a modern, legit
version is interesting too if it is possible for my App to send the
prospective user a pop-up text message stating something like "Please wait
while we determine if your phone is supported"... then "your phone is
supported, please ....". However, sending text messages w/o pairing would
be icing on the cake, though.

You can open a socket and send some text to a Bluetooth phone.
On my Samsung phone at least, it disappears into a black hole.
You can also send some text in the form of a business card, which
is usually handled better.

Post by Isaac
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following
a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)

Using the bluetooth.discover_devices() function followed by the
bluetooth.find_service() query to the specific discovered
addresses from the following Python module, I get no manufacturer
or model info returned in the dictionaries specified.
http://org.csail.mit.edu/pybluez/docs-0.6/bluetooth.html#DeviceDiscoverer
I get results like this from bluetooth.find_service() when
connecting to 00:23:39:9F:BA:8A.
Host: 00:23:39:9F:BA:8A
Name: Serial Server
Description: None
Protocol: RFCOMM
Provider: None
Port: 4
Service id: None
Service-classes: ['1101']
Profiles: [('1101', 256)]
That's my own Samsung phone's host address, so I have no qualms
about making it public. My Siemens and Sony Ericsson phones
likewise return no make or model info in this way.
If there's more to be found, I haven't found it.
John

[Isaac]

Maybe the following is a much easier, more robust, approach. After reading
that info I found more carefully (see
http://en.wikipedia.org/wiki/Bluetooth#Setting_up_connections),
I realize there is a catch. That is, there seems to be two conditional words
I don't understand in the
following section:
1." > Any device may perform an inquiry to find other devices to connect to,
and

any device can be configured to respond to such inquiries. "

Here it says "can be configured". Not sure if that means the user has to
enter a special option/mode setting to enable the "discoverable mode", or if
the "discoverable mode" the default mode when the Bluetooth radio is
enabled. Any idea?

2.>However, if the

device trying to connect knows the *address* of the device, it always
responds to direct connection requests and transmits the information shown
in the list above if requested. "

Here, I don't know what "address" they are mean in "if the device trying to
connect knows the *address* of the device"? Any idea what address they are
talking about? If it means a certain Bluetooth (stack?) address, then is
that
publicly known or is it secret? However, if it means a MAC address, then
that should be publicly available based on this website Bluetooth public
scanner data:
http://www.bluetoothtracking.org/

From this explanation, if I know what that "address" is then I should be
able query the
make/model info if "discoverable mode" is enabled. This would be a far
easier and more robust approach than the base address interpolation method
you just figured out. So any help to nail this near last step will go a
long way towards cracking this nut.

Much appreciated!
Isaac

Hey John,
The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can
be change, which I assume few people do. Even better, though, I searched
this further and found the below info, which indicates that any Bluetooth
device will give, among other technical info, the make and model of the
phone on demand as part of a discovery mode inquiry. This is *exactly*
what I need! It is not clear to me if the AT Commands will work or if it a
certain Bluetooth program script protocol. That is, do you happen to know
what is the method/mode to properly inquire and access this public
Bluetooth device info during a discovery mode inquiry? Bluejacking or a
modern, legit version is interesting too if it is possible for my App to
send the prospective user a pop-up text message stating something like
"Please wait while we determine if your phone is supported"... then "your
phone is supported, please ....". However, sending text messages w/o
pairing would be icing on the cake, though.
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following
a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)
Any device may perform an inquiry to find other devices to connect to, and
any device can be configured to respond to such inquiries. However, if the
device trying to connect knows the address of the device, it always
responds to direct connection requests and transmits the information shown
in the list above if requested. Use of a device's services may require
pairing or acceptance by its owner, but the connection itself can be
initiated by any device and held until it goes out of range. Some devices
can be connected to only one device at a time, and connecting to them
prevents them from connecting to other devices and appearing in inquiries
until they disconnect from the other device.
Every device has a unique 48-bit address. However, these addresses are
generally not shown in inquiries. Instead, friendly Bluetooth names are
used, which can be set by the user. This name appears when another user
scans for devices and in lists of paired devices.
Most phones have the Bluetooth name set to the manufacturer and model of
the phone by default. Most phones and laptops show only the Bluetooth
names and special programs are required to get additional information
about remote devices. This can be confusing as, for example, there could
be several phones in range named T610 (see Bluejacking).

Post by John Henderson

Post by Isaac
Are you aware of any partial access (i.e., "gray") security levels whereby
you don't have to do full pairing but can get authorized for limited
connectivity (like some kind of a "sandbox" mode) to at least do some basic

<snip>

Post by John Henderson
I'm not aware of anything like that.
You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol.
If you could rely on people not changing the Bluetooth name,
then that often carries model information. If I scan in a busy
200408 Nokia CK-7W
5A0204 SGH-A561
along with lots of customized names, of course.
John

[John Henderson]

Post by Isaac
Here it says "can be configured". Not sure if that means the user has to
enter a special option/mode setting to enable the "discoverable mode", or if
the "discoverable mode" the default mode when the Bluetooth radio is
enabled. Any idea?

I think you'll find that late-model Bluetooth phones have
visibility/discoverability turned off by default. That is to
say, when Bluetooth is turned on they default to "page scan
mode" rather than "inquiry scan mode". To do otherwise would be
construed as a security flaw.

Post by Isaac
Here, I don't know what "address" they are mean in "if the device trying to
connect knows the *address* of the device"? Any idea what address they are
talking about?

It's the unique address of the Bluetooth device. It responds to
an inquiry scan with that and its protocol/class.

As I mentioned in an earlier post, my Samsung phone's Bluetooth
address is 00:23:39:9F:BA:8A, alternatively written without the
colons as 0023399FBA8A. It is sometimes called a MAC address.

Post by Isaac
If it means a certain Bluetooth (stack?) address, then is that
publicly known or is it secret? However, if it means a MAC address, then
that should be publicly available based on this website Bluetooth public
http://www.bluetoothtracking.org/

Only if the device in question got within Bluetooth range of
the monitoring device when inquiry scan mode was active.

Post by Isaac
From this explanation, if I know what that "address" is then I should be
able query the make/model info if "discoverable mode" is enabled.

You need visibility/discoverability/"inquiry scan mode" to be
turned on to even know the device is in your vicinity.

John

[Isaac]

I've been doing some homework on this the past few days. See my reply below.

Post by John Henderson

Post by Isaac
Here it says "can be configured". Not sure if that means the user has to
enter a special option/mode setting to enable the "discoverable mode", or if
the "discoverable mode" the default mode when the Bluetooth radio is
enabled. Any idea?

I think you'll find that late-model Bluetooth phones have
visibility/discoverability turned off by default. That is to
say, when Bluetooth is turned on they default to "page scan
mode" rather than "inquiry scan mode". To do otherwise would be
construed as a security flaw.

Yes, I found a site that indirectly confirms this, with some additional
interesting info. Here is a snip: "90% of clients have Bluetooth turned
off, -for the 10% of customers, when asked if they will receive a file, 75%
will say no, -and of the 25% that say yes, 50% of the times the transmission
is dropped because the mobile phone cannot communicate well from large
distance. If you want to broadcast messages from a central location, you
should expect a hit rate less than 1.25% of your population"

Post by John Henderson

Post by Isaac
Here, I don't know what "address" they are mean in "if the device trying to
connect knows the *address* of the device"? Any idea what address they are
talking about?

It's the unique address of the Bluetooth device. It responds to
an inquiry scan with that and its protocol/class.

then why does Wikipedia say it will also respond with the phone's technical
info "on demand" in response to an inquiry scan? As a reminder:
http://en.wikipedia.org/wiki/Bluetooth#Communication_and_connection
"Any Bluetooth device in discoverable mode will transmit the following
information on demand:

a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)
...
However, if the device trying to connect knows the address of the device, it
always responds to direct connection requests and transmits the information
shown in the list above if requested."

This seems to indicate that if you know the destination's BD_ADDR and their
BT radio is turned on in discoverable mode, then you can get "Technical
information" on demand, which includes the BT device's manufacturer, and I
would expect model number as well.

Post by John Henderson
As I mentioned in an earlier post, my Samsung phone's Bluetooth
address is 00:23:39:9F:BA:8A, alternatively written without the
colons as 0023399FBA8A. It is sometimes called a MAC address.

my understanding is that a few digits of this BD_ADDR ID the maker, and a
few others ID the model number.

Post by John Henderson

Post by Isaac
If it means a certain Bluetooth (stack?) address, then is that
publicly known or is it secret? However, if it means a MAC address, then
that should be publicly available based on this website Bluetooth public
http://www.bluetoothtracking.org/

Only if the device in question got within Bluetooth range of
the monitoring device when inquiry scan mode was active.

OK, so you agree we can get the unique BT address (BD_ADDR) on an inquiry
scan. So, one question is that once we have BD_ADDR can we send messaging
requests to that BD_ADDR, which prompt the user to accept, even when the BT
is not discoverable, but turned on (e.g., may be in page scan mode)?

Post by John Henderson

Post by Isaac

Post by Isaac
From this explanation, if I know what that "address" is then I should be

able query the make/model info if "discoverable mode" is enabled.

You need visibility/discoverability/"inquiry scan mode" to be
turned on to even know the device is in your vicinity.

confirmed. I would have signage or instructions that prompts users in the
area to turn on their BT is discoverable mode.

Thanks again,
Isaac

Post by John Henderson
John

[Michael Mauch]

Post by Isaac
then why does Wikipedia say it will also respond with the phone's technical
http://en.wikipedia.org/wiki/Bluetooth#Communication_and_connection
"Any Bluetooth device in discoverable mode will transmit the following
a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)
...
However, if the device trying to connect knows the address of the device, it
always responds to direct connection requests and transmits the information
shown in the list above if requested."
This seems to indicate that if you know the destination's BD_ADDR and their
BT radio is turned on in discoverable mode, then you can get "Technical
information" on demand, which includes the BT device's manufacturer, and I
would expect model number as well.

Here's what I get with Linux/Bluez "hcitool info" for a T-Mobile G2 Touch
(HTC Hero):

# hcitool info $BTmmg2
Requesting information ...
BD Address: 00:22:A5:B3:AD:47
Device Name: mmg2
LMP Version: 2.1 (0x4) LMP Subversion: 0x15b5
Manufacturer: Texas Instruments Inc. (13)
Features page 0: 0xff 0xff 0x2d 0xfe 0x9b 0xff 0x79 0x83
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
<transparent SCO> <EDR ACL 2 Mbps> <EDR ACL 3 Mbps>
<enhanced iscan> <interlaced iscan> <interlaced pscan>
<inquiry with RSSI> <extended SCO> <EV4 packets> <EV5 packets>
<AFH cap. slave> <AFH class. slave> <3-slot EDR ACL>
<5-slot EDR ACL> <sniff subrating> <pause encryption>
<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended inquiry>
<simple pairing> <encapsulated PDU> <err. data report>
<non-flush flag> <LSTO> <inquiry TX power> <extended features>
Features page 1: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

The manufacturer apparently is the BT device's manufacturer, not the
phone manufacturer or vendor. You also don't get the firmware version,
which might affect what the phone is able to do.

With "hcitool inq" you can get the "clock offset" (whatever that is) and
the device class.

With "sdptool browse" or "sdptool records" you can get the available
BT services like "Handsfree Audio Gateway".

Regards...
Michael

[John Henderson]

Post by Isaac
Yes, I found a site that indirectly confirms this, with some additional
interesting info. Here is a snip: "90% of clients have Bluetooth turned
off, -for the 10% of customers, when asked if they will receive a file, 75%
will say no, -and of the 25% that say yes, 50% of the times the transmission
is dropped because the mobile phone cannot communicate well from large
distance. If you want to broadcast messages from a central location, you
should expect a hit rate less than 1.25% of your population"

Phones are class 2 Bluetooth devices. This gives a nominal range
of around 10 metres.

I have a class 1 device attached to my PC. Class 1 has a nominal
range of 100 metres, and I find that using this device to
communicate with phones gives such interactions a considerably
greater range than 10 metres.

Furthermore, I have a optional extra-large
omnidirectional antenna fitted to my class 1 device. This is
supposed to give 400 metre range between itself and another
identically-equiped device. The important point is that this
antenna also noticably further extends the useful range of the
phones it's communicating with.

Post by Isaac
then why does Wikipedia say it will also respond with the phone's technical
info "on demand" in response to an inquiry scan?

In my experience, that's wrong. Only address, name and class are
returned. Getting the "technical information" requires an extra
step, directed specifically at the returned address.

Post by Isaac
This seems to indicate that if you know the destination's BD_ADDR and their
BT radio is turned on in discoverable mode, then you can get "Technical
information" on demand, which includes the BT device's manufacturer, and I
would expect model number as well.

You're definitely a "glass half full" person :)

Post by Isaac
my understanding is that a few digits of this BD_ADDR ID the maker, and a
few others ID the model number.

I understood maker only, although model is a distinct possibility
for some manufacturers if they are free to allocate addresses
within their manufacturer block in any way they choose.

Post by Isaac
OK, so you agree we can get the unique BT address (BD_ADDR) on an inquiry
scan. So, one question is that once we have BD_ADDR can we send messaging
requests to that BD_ADDR, which prompt the user to accept, even when the BT
is not discoverable, but turned on (e.g., may be in page scan mode)?

In general, yes. But be prepared for some such requests to be
dropped or not handled in the way you might expect.

John

[Isaac]

<snip>

Post by John Henderson

Post by Isaac
should expect a hit rate less than 1.25% of your population"

Phones are class 2 Bluetooth devices. This gives a nominal range
of around 10 metres.
I have a class 1 device attached to my PC. Class 1 has a nominal
range of 100 metres, and I find that using this device to
communicate with phones gives such interactions a considerably
greater range than 10 metres.
Furthermore, I have a optional extra-large
omnidirectional antenna fitted to my class 1 device. This is
supposed to give 400 metre range between itself and another
identically-equiped device. The important point is that this
antenna also noticably further extends the useful range of the
phones it's communicating with.

way cool!

Post by John Henderson

Post by Isaac
then why does Wikipedia say it will also respond with the phone's technical
info "on demand" in response to an inquiry scan?

In my experience, that's wrong. Only address, name and class are
returned. Getting the "technical information" requires an extra
step, directed specifically at the returned address.

How about BT device tech info in "Extended inquiry" mode- per Wiki:
http://en.wikipedia.org/wiki/Bluetooth#Bluetooth_2.1_.2B_EDR
"Extended inquiry response (EIR)
Provides more information during the inquiry procedure to allow better
filtering of devices before connection. This information may include the
name of the device, a list of services the device supports, the transmission
power level used for inquiry responses, and manufacturer defined data."

It would be very interesting to see what device info is in that hole. Can
you get into that? It could be very fruitful.

Post by John Henderson

Post by Isaac
This seems to indicate that if you know the destination's BD_ADDR and their
BT radio is turned on in discoverable mode, then you can get "Technical
information" on demand, which includes the BT device's manufacturer, and I
would expect model number as well.

You're definitely a "glass half full" person :)

Point well taken... I guess I would never look to solve the
impossible/improbable otherwise... even if it is dumb luck.

Post by John Henderson

Post by Isaac
my understanding is that a few digits of this BD_ADDR ID the maker, and a
few others ID the model number.

I understood maker only, although model is a distinct possibility
for some manufacturers if they are free to allocate addresses
within their manufacturer block in any way they choose.

yes, I have confirmed that the maker's ID # is encoded into the BD_ADDR,
however the model # seems to be a guessing game. I was hoping it is always
there, but you feel it is at the whim of the maker's discression. What do
you base this conclusion on?

Looking at:
http://www.palowireless.com/INFOTOOTH/glossary.asp#NAP

Do you think that their manufacturer block is only in this 16 bit (4 Hex
digit) NAP portion of the BD_ADDR or can they extend there make/model codes
into the lower/upper parts (LAP or UAP)?

Post by John Henderson

Post by Isaac
OK, so you agree we can get the unique BT address (BD_ADDR) on an inquiry
scan. So, one question is that once we have BD_ADDR can we send messaging
requests to that BD_ADDR, which prompt the user to accept, even when the BT
is not discoverable, but turned on (e.g., may be in page scan mode)?

In general, yes. But be prepared for some such requests to be
dropped or not handled in the way you might expect.

this makes good sense. do you have any feel for what happens most of the
time?

Post by John Henderson
John

[John Henderson]

Post by Isaac
http://en.wikipedia.org/wiki/Bluetooth#Bluetooth_2.1_.2B_EDR
"Extended inquiry response (EIR)
Provides more information during the inquiry procedure to allow better
filtering of devices before connection. This information may include the
name of the device, a list of services the device supports, the transmission
power level used for inquiry responses, and manufacturer defined data."
It would be very interesting to see what device info is in that hole. Can
you get into that? It could be very fruitful.

Yes, I wasn't aware of that extension, so it's outside my
experience. Maybe this helps:

[***@localhost ~]$ python
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38)
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Post by Isaac

import bluetooth
dir(bluetooth)

['ADVANCED_AUDIO_CLASS', 'ADVANCED_AUDIO_PROFILE', 'AUDIO_SINK_CLASS',
'AUDIO_SINK_PROFILE', 'AUDIO_SOURCE_CLASS',
'AUDIO_SOURCE_PROFILE', 'AVCTP_UUID', 'AVDTP_UUID', 'AV_CLASS',
'AV_PROFILE', 'AV_REMOTE_CLASS', 'AV_REMOTE_PROFILE',
'AV_REMOTE_TARGET_CLASS', 'AV_REMOTE_TARGET_PROFILE',
'BASIC_PRINTING_CLASS', 'BASIC_PRINTING_PROFILE',
'BLUETOOTH_PROFILE_DESCRIPTOR_LIST_ATTRID', 'BNEP_UUID',
'BROWSE_GROUP_LIST_ATTRID', 'BROWSE_GRP_DESC_CLASS',
'BROWSE_GRP_DESC_PROFILE', 'BluetoothError', 'BluetoothSocket',
'CIP_CLASS', 'CIP_PROFILE', 'CLIENT_EXECUTABLE_URL_ATTRID',
'CMTP_UUID', 'CORDLESS_TELEPHONY_CLASS',
'CORDLESS_TELEPHONY_PROFILE', 'DIALUP_NET_CLASS',
'DIALUP_NET_PROFILE', 'DIRECT_PRINTING_CLASS',
'DIRECT_PRINTING_PROFILE', 'DIRECT_PRT_REFOBJS_CLASS',
'DIRECT_PRT_REFOBJS_PROFILE', 'DOCUMENTATION_URL_ATTRID',
'DeviceDiscoverer', 'FAX_CLASS', 'FAX_PROFILE', 'FTP_UUID',
'GENERIC_AUDIO_CLASS', 'GENERIC_AUDIO_PROFILE',
'GENERIC_FILETRANS_CLASS', 'GENERIC_FILETRANS_PROFILE',
'GENERIC_NETWORKING_CLASS', 'GENERIC_NETWORKING_PROFILE',
'GENERIC_TELEPHONY_CLASS', 'GENERIC_TELEPHONY_PROFILE',
'GN_CLASS', 'GN_PROFILE', 'HANDSFREE_AGW_CLASS',
'HANDSFREE_AGW_PROFILE', 'HANDSFREE_CLASS', 'HANDSFREE_PROFILE',
'HCI', 'HCRP_CTRL_UUID', 'HCRP_DATA_UUID', 'HCRP_NOTE_UUID',
'HCR_CLASS', 'HCR_PRINT_CLASS', 'HCR_PRINT_PROFILE',
'HCR_PROFILE', 'HCR_SCAN_CLASS', 'HCR_SCAN_PROFILE',
'HEADSET_AGW_CLASS', 'HEADSET_AGW_PROFILE', 'HEADSET_CLASS',
'HEADSET_PROFILE', 'HIDP_UUID', 'HID_CLASS', 'HID_PROFILE',
'HTTP_UUID', 'ICON_URL_ATTRID', 'IMAGING_ARCHIVE_CLASS',
'IMAGING_ARCHIVE_PROFILE', 'IMAGING_CLASS', 'IMAGING_PROFILE',
'IMAGING_REFOBJS_CLASS', 'IMAGING_REFOBJS_PROFILE',
'IMAGING_RESPONDER_CLASS', 'IMAGING_RESPONDER_PROFILE',
'INTERCOM_CLASS', 'INTERCOM_PROFILE', 'IP_UUID',
'IRMC_SYNC_CLASS', 'IRMC_SYNC_CMD_CLASS',
'IRMC_SYNC_CMD_PROFILE', 'IRMC_SYNC_PROFILE', 'L2CAP',
'L2CAP_OPTIONS', 'L2CAP_UUID',
'LANGUAGE_BASE_ATTRID_LIST_ATTRID', 'LAN_ACCESS_CLASS',
'LAN_ACCESS_PROFILE', 'NAP_CLASS', 'NAP_PROFILE',
'OBEX_FILETRANS_CLASS', 'OBEX_FILETRANS_PROFILE',
'OBEX_OBJPUSH_CLASS', 'OBEX_OBJPUSH_PROFILE', 'OBEX_UUID',
'PANU_CLASS', 'PANU_PROFILE', 'PNP_INFO_CLASS',
'PNP_INFO_PROFILE', 'PORT_ANY', 'PRINTING_STATUS_CLASS',
'PRINTING_STATUS_PROFILE', 'PROTOCOL_DESCRIPTOR_LIST_ATTRID',
'PROVIDER_NAME_ATTRID', 'PUBLIC_BROWSE_GROUP',
'REFERENCE_PRINTING_CLASS', 'REFERENCE_PRINTING_PROFILE',
'REFLECTED_UI_CLASS', 'REFLECTED_UI_PROFILE', 'RFCOMM',
'RFCOMM_UUID', 'SAP_CLASS', 'SAP_PROFILE', 'SCO',
'SDP_SERVER_CLASS', 'SDP_SERVER_PROFILE', 'SDP_UUID',
'SERIAL_PORT_CLASS', 'SERIAL_PORT_PROFILE',
'SERVICE_AVAILABILITY_ATTRID', 'SERVICE_CLASS_ID_LIST_ATTRID',
'SERVICE_DESCRIPTION_ATTRID', 'SERVICE_ID_ATTRID',
'SERVICE_INFO_TIME_TO_LIVE_ATTRID', 'SERVICE_NAME_ATTRID',
'SERVICE_RECORD_HANDLE_ATTRID', 'SERVICE_RECORD_STATE_ATTRID',
'SOL_L2CAP', 'SOL_RFCOMM', 'TCP_UUID', 'TCS_AT_UUID',
'TCS_BIN_UUID', 'UDI_MT_CLASS', 'UDI_MT_PROFILE',
'UDI_TA_CLASS', 'UDI_TA_PROFILE', 'UDI_UUID', 'UDP_UUID',
'UPNP_CLASS', 'UPNP_IP_CLASS', 'UPNP_IP_PROFILE',
'UPNP_L2CAP_CLASS', 'UPNP_L2CAP_PROFILE', 'UPNP_LAP_CLASS',
'UPNP_LAP_PROFILE', 'UPNP_PAN_CLASS', 'UPNP_PAN_PROFILE',
'UPNP_PROFILE', 'UPNP_UUID', 'VIDEO_CONF_CLASS',
'VIDEO_CONF_GW_CLASS', 'VIDEO_CONF_GW_PROFILE',
'VIDEO_CONF_PROFILE', 'VIDEO_SINK_CLASS', 'VIDEO_SINK_PROFILE',
'VIDEO_SOURCE_CLASS', 'VIDEO_SOURCE_PROFILE', 'WAP_CLASS',
'WAP_CLIENT_CLASS', 'WAP_CLIENT_PROFILE', 'WAP_PROFILE',
'WSP_UUID', '__builtins__', '__doc__', '__file__', '__name__',
'__path__', '_bluetooth', '_dbg', 'advertise_service', 'array',
'binascii', 'bluez', 'btcommon', 'discover_devices', 'fcntl',
'find_service', 'is_valid_address', 'is_valid_uuid',
'lookup_name', 'os', 'sdp_make_data_element',
'sdp_parse_data_element', 'sdp_parse_data_elementSequence',
'sdp_parse_int', 'sdp_parse_raw_record', 'sdp_parse_size_desc',
'sdp_parse_uuid', 'set_l2cap_mtu', 'set_packet_timeout',
'stop_advertising', 'struct', 'sys', 'to_full_uuid']

Post by Isaac
yes, I have confirmed that the maker's ID # is encoded into the BD_ADDR,
however the model # seems to be a guessing game. I was hoping it is always
there, but you feel it is at the whim of the maker's discression. What do
you base this conclusion on?

Just my interpretation of some reference you turned up a few
replies ago.

Post by Isaac
Do you think that their manufacturer block is only in this 16 bit (4 Hex
digit) NAP portion of the BD_ADDR or can they extend there make/model codes
into the lower/upper parts (LAP or UAP)?

I'm just holding that possibility open. I'm not working on any
Bluetooth projects at the moment. Otherwise I'd be more active
in chasing down some of this new stuff.

Post by Isaac
this makes good sense. do you have any feel for what happens most of the
time?

I think most devices will behave in the way you hope.

John

[Isaac]

Post by John Henderson

Post by Isaac
http://en.wikipedia.org/wiki/Bluetooth#Bluetooth_2.1_.2B_EDR
"Extended inquiry response (EIR)
Provides more information during the inquiry procedure to allow better
filtering of devices before connection. This information may include the
name of the device, a list of services the device supports, the transmission
power level used for inquiry responses, and manufacturer defined data."
It would be very interesting to see what device info is in that hole.
Can
you get into that? It could be very fruitful.

Yes, I wasn't aware of that extension, so it's outside my

not quite sure what that is a dump of. Seems like BT programming
function/device spec tags/switches. Can you clarify? Are they available
without pairing? I scanned quickly through them, and this one caught my eye
'WAP_CLIENT_PROFILE'. I wonder if the model number could be buried in that
b/c mini browsers provide model numbers to a WAP server.

Post by John Henderson
Python 2.5.2 (r252:60911, Sep 30 2008, 15:41:38)
[GCC 4.3.2 20080917 (Red Hat 4.3.2-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.

Post by Isaac

import bluetooth
dir(bluetooth)

['ADVANCED_AUDIO_CLASS', 'ADVANCED_AUDIO_PROFILE', 'AUDIO_SINK_CLASS',
'AUDIO_SINK_PROFILE', 'AUDIO_SOURCE_CLASS',
'AUDIO_SOURCE_PROFILE', 'AVCTP_UUID', 'AVDTP_UUID', 'AV_CLASS',
'AV_PROFILE', 'AV_REMOTE_CLASS', 'AV_REMOTE_PROFILE',
'AV_REMOTE_TARGET_CLASS', 'AV_REMOTE_TARGET_PROFILE',
'BASIC_PRINTING_CLASS', 'BASIC_PRINTING_PROFILE',
'BLUETOOTH_PROFILE_DESCRIPTOR_LIST_ATTRID', 'BNEP_UUID',
'BROWSE_GROUP_LIST_ATTRID', 'BROWSE_GRP_DESC_CLASS',
'BROWSE_GRP_DESC_PROFILE', 'BluetoothError', 'BluetoothSocket',
'CIP_CLASS', 'CIP_PROFILE', 'CLIENT_EXECUTABLE_URL_ATTRID',
'CMTP_UUID', 'CORDLESS_TELEPHONY_CLASS',
'CORDLESS_TELEPHONY_PROFILE', 'DIALUP_NET_CLASS',
'DIALUP_NET_PROFILE', 'DIRECT_PRINTING_CLASS',
'DIRECT_PRINTING_PROFILE', 'DIRECT_PRT_REFOBJS_CLASS',
'DIRECT_PRT_REFOBJS_PROFILE', 'DOCUMENTATION_URL_ATTRID',
'DeviceDiscoverer', 'FAX_CLASS', 'FAX_PROFILE', 'FTP_UUID',
'GENERIC_AUDIO_CLASS', 'GENERIC_AUDIO_PROFILE',
'GENERIC_FILETRANS_CLASS', 'GENERIC_FILETRANS_PROFILE',
'GENERIC_NETWORKING_CLASS', 'GENERIC_NETWORKING_PROFILE',
'GENERIC_TELEPHONY_CLASS', 'GENERIC_TELEPHONY_PROFILE',
'GN_CLASS', 'GN_PROFILE', 'HANDSFREE_AGW_CLASS',
'HANDSFREE_AGW_PROFILE', 'HANDSFREE_CLASS', 'HANDSFREE_PROFILE',
'HCI', 'HCRP_CTRL_UUID', 'HCRP_DATA_UUID', 'HCRP_NOTE_UUID',
'HCR_CLASS', 'HCR_PRINT_CLASS', 'HCR_PRINT_PROFILE',
'HCR_PROFILE', 'HCR_SCAN_CLASS', 'HCR_SCAN_PROFILE',
'HEADSET_AGW_CLASS', 'HEADSET_AGW_PROFILE', 'HEADSET_CLASS',
'HEADSET_PROFILE', 'HIDP_UUID', 'HID_CLASS', 'HID_PROFILE',
'HTTP_UUID', 'ICON_URL_ATTRID', 'IMAGING_ARCHIVE_CLASS',
'IMAGING_ARCHIVE_PROFILE', 'IMAGING_CLASS', 'IMAGING_PROFILE',
'IMAGING_REFOBJS_CLASS', 'IMAGING_REFOBJS_PROFILE',
'IMAGING_RESPONDER_CLASS', 'IMAGING_RESPONDER_PROFILE',
'INTERCOM_CLASS', 'INTERCOM_PROFILE', 'IP_UUID',
'IRMC_SYNC_CLASS', 'IRMC_SYNC_CMD_CLASS',
'IRMC_SYNC_CMD_PROFILE', 'IRMC_SYNC_PROFILE', 'L2CAP',
'L2CAP_OPTIONS', 'L2CAP_UUID',
'LANGUAGE_BASE_ATTRID_LIST_ATTRID', 'LAN_ACCESS_CLASS',
'LAN_ACCESS_PROFILE', 'NAP_CLASS', 'NAP_PROFILE',
'OBEX_FILETRANS_CLASS', 'OBEX_FILETRANS_PROFILE',
'OBEX_OBJPUSH_CLASS', 'OBEX_OBJPUSH_PROFILE', 'OBEX_UUID',
'PANU_CLASS', 'PANU_PROFILE', 'PNP_INFO_CLASS',
'PNP_INFO_PROFILE', 'PORT_ANY', 'PRINTING_STATUS_CLASS',
'PRINTING_STATUS_PROFILE', 'PROTOCOL_DESCRIPTOR_LIST_ATTRID',
'PROVIDER_NAME_ATTRID', 'PUBLIC_BROWSE_GROUP',
'REFERENCE_PRINTING_CLASS', 'REFERENCE_PRINTING_PROFILE',
'REFLECTED_UI_CLASS', 'REFLECTED_UI_PROFILE', 'RFCOMM',
'RFCOMM_UUID', 'SAP_CLASS', 'SAP_PROFILE', 'SCO',
'SDP_SERVER_CLASS', 'SDP_SERVER_PROFILE', 'SDP_UUID',
'SERIAL_PORT_CLASS', 'SERIAL_PORT_PROFILE',
'SERVICE_AVAILABILITY_ATTRID', 'SERVICE_CLASS_ID_LIST_ATTRID',
'SERVICE_DESCRIPTION_ATTRID', 'SERVICE_ID_ATTRID',
'SERVICE_INFO_TIME_TO_LIVE_ATTRID', 'SERVICE_NAME_ATTRID',
'SERVICE_RECORD_HANDLE_ATTRID', 'SERVICE_RECORD_STATE_ATTRID',
'SOL_L2CAP', 'SOL_RFCOMM', 'TCP_UUID', 'TCS_AT_UUID',
'TCS_BIN_UUID', 'UDI_MT_CLASS', 'UDI_MT_PROFILE',
'UDI_TA_CLASS', 'UDI_TA_PROFILE', 'UDI_UUID', 'UDP_UUID',
'UPNP_CLASS', 'UPNP_IP_CLASS', 'UPNP_IP_PROFILE',
'UPNP_L2CAP_CLASS', 'UPNP_L2CAP_PROFILE', 'UPNP_LAP_CLASS',
'UPNP_LAP_PROFILE', 'UPNP_PAN_CLASS', 'UPNP_PAN_PROFILE',
'UPNP_PROFILE', 'UPNP_UUID', 'VIDEO_CONF_CLASS',
'VIDEO_CONF_GW_CLASS', 'VIDEO_CONF_GW_PROFILE',
'VIDEO_CONF_PROFILE', 'VIDEO_SINK_CLASS', 'VIDEO_SINK_PROFILE',
'VIDEO_SOURCE_CLASS', 'VIDEO_SOURCE_PROFILE', 'WAP_CLASS',
'WAP_CLIENT_CLASS', 'WAP_CLIENT_PROFILE', 'WAP_PROFILE',
'WSP_UUID', '__builtins__', '__doc__', '__file__', '__name__',
'__path__', '_bluetooth', '_dbg', 'advertise_service', 'array',
'binascii', 'bluez', 'btcommon', 'discover_devices', 'fcntl',
'find_service', 'is_valid_address', 'is_valid_uuid',
'lookup_name', 'os', 'sdp_make_data_element',
'sdp_parse_data_element', 'sdp_parse_data_elementSequence',
'sdp_parse_int', 'sdp_parse_raw_record', 'sdp_parse_size_desc',
'sdp_parse_uuid', 'set_l2cap_mtu', 'set_packet_timeout',
'stop_advertising', 'struct', 'sys', 'to_full_uuid']

Post by Isaac
yes, I have confirmed that the maker's ID # is encoded into the BD_ADDR,
however the model # seems to be a guessing game. I was hoping it is always
there, but you feel it is at the whim of the maker's discression. What do
you base this conclusion on?

Just my interpretation of some reference you turned up a few
replies ago.

confirmed.

Post by John Henderson

Post by Isaac
Do you think that their manufacturer block is only in this 16 bit (4 Hex
digit) NAP portion of the BD_ADDR or can they extend there make/model codes
into the lower/upper parts (LAP or UAP)?

I'm just holding that possibility open. I'm not working on any
Bluetooth projects at the moment. Otherwise I'd be more active
in chasing down some of this new stuff.

Post by Isaac
this makes good sense. do you have any feel for what happens most of the
time?

I think most devices will behave in the way you hope.

confirmed.

Post by John Henderson
John

[John Henderson]

Post by Isaac
not quite sure what that is a dump of. Seems like BT programming
function/device spec tags/switches. Can you clarify?

It's just a list of the Python attributes / "named entities"
available in the PyBluez Bluetooth module. If it doesn't have a
name listed there, it's not available.

Post by Isaac
Are they available without pairing?

Not necessarily.

John

[Isaac]

Ahh, OK. Unfortunately, I did not see anything in the list related to
extended inquiry. I'll keep digging....

thanks,
Isaac

Post by John Henderson

Post by Isaac
not quite sure what that is a dump of. Seems like BT programming
function/device spec tags/switches. Can you clarify?

It's just a list of the Python attributes / "named entities"
available in the PyBluez Bluetooth module. If it doesn't have a
name listed there, it's not available.

Post by Isaac
Are they available without pairing?

Not necessarily.
John

[Isaac]

After reading that info I found more carefully, I realize there is a catch.
That is, there seems to be two conditional words I don't clearly understand
in the following two sections:
1." > Any device may perform an inquiry to find other devices to connect to,
and

any device can be configured to respond to such inquiries. "

Here is says "can be configured". Not sure if that means the user has to
enter a special option/mode setting to enable the "discoverable mode", or if
the "discoverable mode" the default mode when the Bluetooth radio is
enabled. Any idea?

2.>However, if the

device trying to connect knows the *address* of the device, it always
responds
to direct connection requests and transmits the information shown in the
list above if requested. "

Here, I don't know what "address" they are mean in "if the device trying to
connect knows the *address* of the device"? Any idea what address they are
talking about? If it means a certain Bluetooth address, then is that
publicly known or is it secret. However, if it means a MAC address, then
that should be publicly available based on this website Bluetooth public
scanner data:
http://www.bluetoothtracking.org/

From this explaination, if I know what that "address" is I can query the
make/model info. I'm real close now, so any help to nail this near last
step will go a long way towards cracking this nut.

Much appreciated!
Isaac

Hey John,
The address blocks suggestion when over my head, but I think you are
definitely onto something with the Bluetooth name observation. I looked
into that and found out that this is the default case, but as you say can
be
change, which I assume few people do. Even better, though, I searched
this
further and found the below info, which indicates that any Bluetooth
device
will give, among other technical info, the make and model of the phone on
demand as part of a discovery mode inquiry. This is *exactly* what I
need!
It is not clear to me if the AT Commands will work or if it a certain
Bluetooth program script protocol. That is, do you happen to know what is
the method/mode to properly inquire and access this public Bluetooth
device
info during a discovery mode inquiry? Bluejacking or a modern, legit
version is interesting too if it is possible for my App to send the
prospective user a pop-up text message stating something like "Please wait
while we determine if your phone is supported"... then "your phone is
supported, please ....". However, sending text messages w/o pairing would
be icing on the cake, though.
Setting up connections
Any Bluetooth device in discoverable mode will transmit the following
a.. Device name
b.. Device class
c.. List of services
d.. Technical information (for example: device features, manufacturer,
Bluetooth specification used, clock offset)
Any device may perform an inquiry to find other devices to connect to, and
any device can be configured to respond to such inquiries. However, if the
device trying to connect knows the address of the device, it always
responds
to direct connection requests and transmits the information shown in the
list above if requested. Use of a device's services may require pairing or
acceptance by its owner, but the connection itself can be initiated by any
device and held until it goes out of range. Some devices can be connected
to
only one device at a time, and connecting to them prevents them from
connecting to other devices and appearing in inquiries until they
disconnect
from the other device.
Every device has a unique 48-bit address. However, these addresses are
generally not shown in inquiries. Instead, friendly Bluetooth names are
used, which can be set by the user. This name appears when another user
scans for devices and in lists of paired devices.
Most phones have the Bluetooth name set to the manufacturer and model of
the
phone by default. Most phones and laptops show only the Bluetooth names
and
special programs are required to get additional information about remote
devices. This can be confusing as, for example, there could be several
phones in range named T610 (see Bluejacking).

Post by John Henderson

Post by Isaac
Are you aware of any partial access (i.e., "gray") security levels whereby
you don't have to do full pairing but can get authorized for limited
connectivity (like some kind of a "sandbox" mode) to at least do some basic

<snip>

Post by John Henderson
I'm not aware of anything like that.
You might want to research whether or not Bluetooth addresses are
allocated and used in blocks such that individual addresses can
convey some information, perhaps in conjunction with the
protocol.
If you could rely on people not changing the Bluetooth name,
then that often carries model information. If I scan in a busy
200408 Nokia CK-7W
5A0204 SGH-A561
along with lots of customized names, of course.
John

[danny burstein]

Post by Isaac
I see. That is very encouraging.
Do you happen to know if there is a way to use these AT commands without
pairing first? Or, if there is another way to get the model info without
pairing.

You might want to contact the folk at:

http://www.bluetoothtracking.org/

[Isaac]

Hi, thanks for the tip. That is a very interesting project this guys has
done. He seems cool, so maybe he'd be willing to help with a few quick
questions. The website is vintage 2007 so hopefully he is still active.

Thanks again!
Isaac

Post by danny burstein

Post by Isaac
I see. That is very encouraging.
Do you happen to know if there is a way to use these AT commands without
pairing first? Or, if there is another way to get the model info without
pairing.

http://www.bluetoothtracking.org/
--
_____________________________________________________
Knowledge may be power, but communications is the key
[to foil spammers, my address has been double rot-13 encoded]

[Isaac]

I just realized I misread the log dates, and see now that the website is
still active.

thanks,
Isaac

Post by Isaac
Hi, thanks for the tip. That is a very interesting project this guys has
done. He seems cool, so maybe he'd be willing to help with a few quick
questions. The website is vintage 2007 so hopefully he is still active.
Thanks again!
Isaac

Post by danny burstein

Post by Isaac
I see. That is very encouraging.
Do you happen to know if there is a way to use these AT commands without
pairing first? Or, if there is another way to get the model info without
pairing.

http://www.bluetoothtracking.org/
--
_____________________________________________________
Knowledge may be power, but communications is the key
[to foil spammers, my address has been double rot-13 encoded]