Hello all!
I'm trying to determine if there's a better way then polling "hcitool scan"
every few seconds to receive notification when a new device is connectable.
The goal is to automatically push a file to each device as it comes within
range without requiring any user intervention (on the server side, of course).
Naturally a certain amount of accounting will need to be done to avoid
duplication and spammage, but I'm primarily curious if there's any event
system or rc.d script system similar to some things I've seen on the FreeBSD
side to enable this behavior.
I'd really like is a way to register or specify a script to be called
whenever a device comes within range. I'd expect the script to be passed the
address of the device, allowing me to interrogate it regarding it's
capabilities, and so forth.
The alternative is, of course, to call "hcitool scan" every few seconds,
compare with a log of the known or seen ID's, and process from there, but as
we were all taught in grammar school CS, polling is bad mm'kay.
Comments? Suggestions?
--B
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thu, 05 Oct 2006 09:22:39 +0200
Marcel Holtmann <[email protected]> wrote:
[...]
> The only sane way of doing this is over the D-Bus API
[...]
> The D-Bus is not as bad everybody tries to tell you. For the hcid for
> example we only need the additional D-Bus library:
Nobody told me, even when I asked (but I was told to be patient
instead of getting an answer). This is my own conclusion after many
weeks of work. Try to install and use dbus in 8 or 16 MB RAM system
with about 300MB permanent storage. This is a small device, not a
desktop.
What is sane about having a function block, doing nothing but waiting,
sending requests back and forth with 3 daemons, and all those message
queues and forked children, when everything can stay in a simple main
loop? Even the use of glib doesn't make any sense here; glib's
interface exists to be portable even with Windows. This is something
you just can't afford on small systems. While all this makes sense in
other contexts, bluetooth is clearly designed for small devices, where
that is neither clean nor sane. Bluez userland is for desktop computers
or higher, and up to v3.4 (I didn't see 3.5 yet) not appropriate when
there is a need to use next to all what bluetooth has to offer,
specially in terms of multitasking.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Wed, 4 Oct 2006 18:20:27 -0700
"Benn" <[email protected]> wrote:
> First of all, as you suggested, BlueZ may not be the right stack. Are the=
re
> logical alternative stacks available, or is it more a matter of using the
> underlying framework rather then the publicly exposed API?
I=B4m not a kernel hacker, so I can't really qualify bluez's stack, but
it seems that hardware support with bluez is quite good. I was talking
about libbluetooth.so; IIRC there was another bluetooth project for
linux, but it seems far less popular and supported less (or
different?) devices, so I didn't follow it. I do use the bluez kernel
stack but neither the library nor the daemons.
> You brought up authentication. If I am OBEX pushing then, as the
> server, if I don't specify any authentication none will be required.
> Correct? Are there other authentication related issues I should be
> aware of?
I've given up any attempt to understand how bluez security model
works, first because if the mentioned library deficiencies and second
because of the heavy shift to dbus in the last versions makes it
virtually impossible even to try to use it. The fact is that,
according to bluetooth specifications, authentication is not required
as long as neither of the peers request authentication.
> Can you point out where this loop actually resides in source, off hand?
Those functions in libbluetooth which require a timeout as an argument
internally call a function `hci_send_req()' in blues-libs/src/hci.c
which will send the command and wait for the answer. Rather than a
select-loop as I said yesterday, it's a poll loop, blocking the return
of the function until an answer arrives or a timeout happens.
> I'm not adverse to using the lower level API's if it truly becomes necess=
ary,
> but since the file transfers are small and fork()'ing seems a reasonable,
> though not ideal, solution, I might stick with that. A central process t=
hat
> is responsible for discovery, forking off separate children to handle the
> actual file dispatches should work, yes?
Open two shells, prepare a commandline obextftp to send a file from
your linux box (only one bluetooth adapter) to two different
cellphones or PDAs in each, and start them more or less at the same
time. All attempts I made ended with one working immediately, the
other either waiting until the first finished or giving some
busy-error. As I believe that obexftp doesn't switch role, the linux
box should become the master of a 3-membered piconet and simultaneous
transmission should work. But bluez defeats that. Actually, up to five
more devices could join the party. But not with libbluetooth.so.
-- =
Cris
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Cris,
> > I'd really like is a way to register or specify a script to be called
> > whenever a device comes within range. I'd expect the script to be passed the
> > address of the device, allowing me to interrogate it regarding it's
> > capabilities, and so forth.
> >
> > The alternative is, of course, to call "hcitool scan" every few seconds,
> > compare with a log of the known or seen ID's, and process from there, but as
> > we were all taught in grammar school CS, polling is bad mm'kay.
>
> The way bluetooth allows to discover nearby devices will not allow to
> avoid some sort of polling: One device needs to be in inquiry scan
> mode, the other needs to do an inquiry; one needs to be trying to
> receive an inquiry signal, the other must send it.
>
> It depends a bit on the volume of traffic you expect here. If you
> don't expect ever more than a few devices per hour and can accept not
> to send the file to more than one device at the same time, you can use
> the 'inq' command to hcitool. At least the last time I checked, the
> 'scan' command to hcitool is misnamed. It's reall only an inquiry with
> a subsequent request for the remote name (more work to do for
> bluetooth and thus more time lost for data traffic); hcitool 'scan'
> has nothing to do with a `scan' in bluetooth terminology, which is the
> listening of the device for inquiry or page attempts. Anyway, unless
> you want to log those `userfriendly' names, it's useless in an
> unattended situation. In this case of very low and limited traffic,
> you could write this using as a script, but you are likely to run into
> problems in the area of authentication (pin codes) for the way bluez
> handles things.
>
> As volume of traffic grows, the bluez becomes inappropriate:
> Bluetooth's basic concepts are event-oriented and designed for small
> and/or embedded devices. Both are defeated by bluez: The library locks
> in a select loop while waiting for the answering event (rather than
> let the application do this, which could handle other things in the
> meanwhile), and the use of dbus is certainly not for small devices
> (just look at the huge amount of libraries pulled in for installing
> dbus). You can get around the lock by forking each command, but then,
> you need to do some IPC which is much more complicated than really
> needed. In the end, a solution for some a bit more serious traffic
> will require you to write this in a language like C. Either you use
> the lower level functions in the bluetooth library, avoiding that
> loop, or you write it all by yourself from scratch (my choice). But in
> this situation, you still might want to consider using two (or more)
> bluetooth radios, using one only in periodic inquiry mode, as you can
> not detect a nearby device while transmitting the file.
the use of two radios for these kind of things is always a good idea and
what you want is periodic inquiry. And to be quite clear. The only sane
way of doing this is over the D-Bus API which has a really clean
interface to the inquiry and periodic inquiry commands. It will take
care of everything if the blocking inquiry() from the library is not
your favorite choice. Writing everything from scratch is a total waste
of time.
The D-Bus is not as bad everybody tries to tell you. For the hcid for
example we only need the additional D-Bus library:
# ldd /usr/sbin/hcid
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00002ae5ac039000)
libbluetooth.so.2 => /usr/lib/libbluetooth.so.2 (0x00002ae5ac16f000)
libc.so.6 => /lib/libc.so.6 (0x00002ae5ac285000)
libnsl.so.1 => /lib/libnsl.so.1 (0x00002ae5ac4c6000)
/lib64/ld-linux-x86-64.so.2 (0x00002ae5abf1c000)
Regards
Marcel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hey Cris,
Thanks for a thorough rundown on the problem, I really appreciate it!
A couple of questions, then, to settle things in my mind:
First of all, as you suggested, BlueZ may not be the right stack. Are there
logical alternative stacks available, or is it more a matter of using the
underlying framework rather then the publicly exposed API?
You brought up authentication. If I am OBEX pushing then, as the server, if I
don't specify any authentication none will be required. Correct? Are there
other authentication related issues I should be aware of?
Can you point out where this loop actually resides in source, off hand?
I'm not adverse to using the lower level API's if it truly becomes necessary,
but since the file transfers are small and fork()'ing seems a reasonable,
though not ideal, solution, I might stick with that. A central process that
is responsible for discovery, forking off separate children to handle the
actual file dispatches should work, yes?
Cheers,
-B
On Wednesday, October 4, 2006, 5:29:55 PM, you wrote:
> On Wed, 4 Oct 2006 14:19:16 -0700
> [email protected] wrote:
>> Hello all!
>>
>> I'd really like is a way to register or specify a script to be called
>> whenever a device comes within range. I'd expect the script to be passed the
>> address of the device, allowing me to interrogate it regarding it's
>> capabilities, and so forth.
>>
>> The alternative is, of course, to call "hcitool scan" every few seconds,
>> compare with a log of the known or seen ID's, and process from there, but as
>> we were all taught in grammar school CS, polling is bad mm'kay.
> The way bluetooth allows to discover nearby devices will not allow to
> avoid some sort of polling: One device needs to be in inquiry scan
> mode, the other needs to do an inquiry; one needs to be trying to
> receive an inquiry signal, the other must send it.
> It depends a bit on the volume of traffic you expect here. If you
> don't expect ever more than a few devices per hour and can accept not
> to send the file to more than one device at the same time, you can use
> the 'inq' command to hcitool. At least the last time I checked, the
> 'scan' command to hcitool is misnamed. It's reall only an inquiry with
> a subsequent request for the remote name (more work to do for
> bluetooth and thus more time lost for data traffic); hcitool 'scan'
> has nothing to do with a `scan' in bluetooth terminology, which is the
> listening of the device for inquiry or page attempts. Anyway, unless
> you want to log those `userfriendly' names, it's useless in an
> unattended situation. In this case of very low and limited traffic,
> you could write this using as a script, but you are likely to run into
> problems in the area of authentication (pin codes) for the way bluez
> handles things.
> As volume of traffic grows, the bluez becomes inappropriate:
> Bluetooth's basic concepts are event-oriented and designed for small
> and/or embedded devices. Both are defeated by bluez: The library locks
> in a select loop while waiting for the answering event (rather than
> let the application do this, which could handle other things in the
> meanwhile), and the use of dbus is certainly not for small devices
> (just look at the huge amount of libraries pulled in for installing
> dbus). You can get around the lock by forking each command, but then,
> you need to do some IPC which is much more complicated than really
> needed. In the end, a solution for some a bit more serious traffic
> will require you to write this in a language like C. Either you use
> the lower level functions in the bluetooth library, avoiding that
> loop, or you write it all by yourself from scratch (my choice). But in
> this situation, you still might want to consider using two (or more)
> bluetooth radios, using one only in periodic inquiry mode, as you can
> not detect a nearby device while transmitting the file.
> HTH
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Wed, 4 Oct 2006 14:19:16 -0700
[email protected] wrote:
> Hello all!
>
> I'd really like is a way to register or specify a script to be called
> whenever a device comes within range. I'd expect the script to be passed the
> address of the device, allowing me to interrogate it regarding it's
> capabilities, and so forth.
>
> The alternative is, of course, to call "hcitool scan" every few seconds,
> compare with a log of the known or seen ID's, and process from there, but as
> we were all taught in grammar school CS, polling is bad mm'kay.
The way bluetooth allows to discover nearby devices will not allow to
avoid some sort of polling: One device needs to be in inquiry scan
mode, the other needs to do an inquiry; one needs to be trying to
receive an inquiry signal, the other must send it.
It depends a bit on the volume of traffic you expect here. If you
don't expect ever more than a few devices per hour and can accept not
to send the file to more than one device at the same time, you can use
the 'inq' command to hcitool. At least the last time I checked, the
'scan' command to hcitool is misnamed. It's reall only an inquiry with
a subsequent request for the remote name (more work to do for
bluetooth and thus more time lost for data traffic); hcitool 'scan'
has nothing to do with a `scan' in bluetooth terminology, which is the
listening of the device for inquiry or page attempts. Anyway, unless
you want to log those `userfriendly' names, it's useless in an
unattended situation. In this case of very low and limited traffic,
you could write this using as a script, but you are likely to run into
problems in the area of authentication (pin codes) for the way bluez
handles things.
As volume of traffic grows, the bluez becomes inappropriate:
Bluetooth's basic concepts are event-oriented and designed for small
and/or embedded devices. Both are defeated by bluez: The library locks
in a select loop while waiting for the answering event (rather than
let the application do this, which could handle other things in the
meanwhile), and the use of dbus is certainly not for small devices
(just look at the huge amount of libraries pulled in for installing
dbus). You can get around the lock by forking each command, but then,
you need to do some IPC which is much more complicated than really
needed. In the end, a solution for some a bit more serious traffic
will require you to write this in a language like C. Either you use
the lower level functions in the bluetooth library, avoiding that
loop, or you write it all by yourself from scratch (my choice). But in
this situation, you still might want to consider using two (or more)
bluetooth radios, using one only in periodic inquiry mode, as you can
not detect a nearby device while transmitting the file.
HTH
--
Cris
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users