Hi Folks,
currently the link keys are stored in a binary format and they are
stored under the "/etc/bluetooth/" directory. Both things are not very
handy and we should start doing something to change this.
So first the new place for runtime things like link keys, names etc. I
decided to use "/var/cache/bluetooth/<bdaddr>/" as the base directory
and then use the file "linkkeys" for the actual link keys. And we will
use "names" for the device name cache. The "bdaddr" is the address of
the local adapter.
And second, The format of the link key file will be very simple:
<bdaddr> <hex-linkkey> <type>
All the framework around these stuff is already committed to the BlueZ
utils CVS and we need only to fill in the functions for writing and
reading the link keys from the files. Both can be found as some kind of
prototypes in hcid/storage.c and I would be very happy if someone fills
these function with actual code, because I am quite busy with some other
stuff.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > > > So first the new place for runtime things like link keys, names etc. I
> > > > decided to use "/var/cache/bluetooth/<bdaddr>/" as the base directory
> > > > and then use the file "linkkeys" for the actual link keys. And we will
> > > > use "names" for the device name cache. The "bdaddr" is the address of
> > > > the local adapter.
> > >
> > > According to the file hierarchy standard, /var/cache is for files which
> > > "can be deleted without data loss". For cached device names it's probably
> > > fine. They can't be recomputed if a device isn't in reach, but if it is,
> > > the device name can be fetched again automatically. But I'm not if this
> > > should include link keys. They can't be regenerated automatically without
> > > bothering the user. Deleting them might even break at setup, where the peer
> > > device isn't reachable easiliy after initial setup. Maybe /var/lib..? I'm
> > > not really an expert in this area.
> >
> > After thinking about it a little longer, I would even put the device name
> > cache under /var/lib/bluetooth. /var/cache is intended for files with the
> > purpose to reduce the load on any kind of resource, be it cpu, memory or
> > network. But that's not why bluez is caching device names. It's because we
> > want a reliable offline lookup capability. Caches should be completely
> > transparent, but this wouldn't be the case here. If the cache is gone, then
> > applications could not display a user friendly name, no matter how hard they
> > try. It's the same difference as the difference between a browser cache and a
> > proxy for offline browsing.
>
> I am fine with it to put it under the /var/lib/bluetooth/ directory. The
> code in the CVS has been changed now.
actually I have everything working like it should be. The code for
dealing with the ASCII files is not the best, but it seems to work fine
for this case. So does everybody agree to store all Bluetooth related
files under /var/lib/bluetooth/ or should we put them somewhere else. It
would be great if people comment on this and test the code, because I
wanna release it as bluez-libs-2.16 and bluez-utils-2.16.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Guylhem,
> > I just wrote some code do deal with the link key storage and to support
> > the device name cache. I don't fully like it and I think it contains
> > some bugs, but it is better than nothing. So feel free to send me
> > patches to improve it. And btw using the hcitool with name cache support
> > is very great in my environment.
>
> Some general thoughts:
> - regarding keys, an ascii version to ease manipulation would be
> great. I hate it when I have to rm all the keys because one device
> has a problem.
this is now working with the new code in the CVS and it is really nice.
I should have done this a long time ago.
> Even worse - some device can only pair with 1 other
> device. If I was able to share keys between my desktop, my laptop and
> my handheld that would be great(but maybe the bt device will use the
> bt address too and refuse that)
The link key is bound to the BD_ADDR and so this is not possible unless
you set the BD_ADDR of all your devices to the same.
> - regarding names : would it be possible to replace bt address by
> nicknames? My devices send back a FQDN on scan because that's the
> way I set them up, but it would be much better if I could address
> them with that FQDN too.
I will not add support for this in the next release, but I am open for
such a feature.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Sunday, 17 April 2005 at 1:16:16 (+0200), Marcel Holtmann wrote:
> I just wrote some code do deal with the link key storage and to support
> the device name cache. I don't fully like it and I think it contains
> some bugs, but it is better than nothing. So feel free to send me
> patches to improve it. And btw using the hcitool with name cache suppor=
t
> is very great in my environment.
Some general thoughts:
- regarding keys, an ascii version to ease manipulation would be
great. I hate it when I have to rm all the keys because one device
has a problem. Even worse - some device can only pair with 1 other
device. If I was able to share keys between my desktop, my laptop and
my handheld that would be great(but maybe the bt device will use the
bt address too and refuse that)
- regarding names : would it be possible to replace bt address by
nicknames? My devices send back a FQDN on scan because that's the
way I set them up, but it would be much better if I could address
them with that FQDN too.
The current ascii key approach is interesting, but entries in
/etc/hosts where bt address would be bound to names, which names would
then be used by l2ping, obexftp etc would be even better !
Guylhem
--=20
Bien =E0 vous - Best regards,
Guylhem P. Aznar
--=20
*@externe.net http://externe.n=
et
P=E9rim=E9/Deprecated: @oeil.qc.ca, @metalab.unc.edu, @ibiblio.org, @7=
un.org
GPG: 92EB37C1 DD11C9C9 20519D01 E8FA1B11 42975AF7 http://externe.net/pubk=
ey
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi again,
> All the framework around these stuff is already committed to the BlueZ
> utils CVS and we need only to fill in the functions for writing and
> reading the link keys from the files. Both can be found as some kind of
> prototypes in hcid/storage.c and I would be very happy if someone fills
> these function with actual code, because I am quite busy with some other
> stuff.
I just wrote some code do deal with the link key storage and to support
the device name cache. I don't fully like it and I think it contains
some bugs, but it is better than nothing. So feel free to send me
patches to improve it. And btw using the hcitool with name cache support
is very great in my environment.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > > > And second, The format of the link key file will be very simple:
> > > >
> > > > <bdaddr> <hex-linkkey> <type>
> > >
> > > This means that we will still be unable to list the devices for which a
> > > link key exists without root privileges, is this correct? If yes, is this
> > > intentional?
> >
> > there is no other way, because we must store the link keys as secure as
> > possible.
>
> Sure, but my question wasn't about the link keys themselves. Why not allow
> regular users to find out if there is a link key for a given device at all,
> without being able to see the link key itself? I don't know if knowing about
> the existance of a link key might be sensitive information, too. But at the
> moment I don't see any problem with it. Bluez could create one file per
> device for instance, with the bdaddr as its name and the rest in it contents.
>
> This would still leave the type and time .. oh.. it's gone.. ok, it would
> leave only the type unreadable for unprivileged users. But everybody could
> take a look into the /var/lib/bluetooth/<local-bdaddr>/ dir to find out if
> bluez might be paired with a given device or not.
> But again, I don't really need this feature. I'm just throwing some thoughts
> in the ring.
I don't like the idea of creating so much files. One file for each link
key doesn't looks reasonable to me.
However in the long term I plan to merge hcid and sdpd and create a nice
Unix socket based API for tasks like managing link keys etc. And then I
can enforce different privileges.
> > > Anyway, I for myself don't care much about where the data goes, as long
> > > as the location and the file formats stay stable, because the link key
> > > manager of kdebluetooth has to be changed each time.
> >
> > In the long term I like to make the place totally configurable, but for
> > now I think going with /var/lib/bluetooth and ASCII based files is a
> > good think.
>
> Make the paths configurable? In hcid.conf? Why would someone want *that*?
> Isn't it a good thing that we can depend on the bluez files staying at a well
> known place? If a weird distribution chooses to place the files in a
> completely different directory, then some build time options should be
> sufficient for them. Ah, ok, maybe that's just what you meant.
This is not for the desktop world. It is for people that are using BlueZ
in embedded devices. They will need things like this.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Saturday, 16. April 2005 21:04, Marcel Holtmann wrote:
> > > And second, The format of the link key file will be very simple:
> > >
> > > <bdaddr> <hex-linkkey> <type>
> >
> > This means that we will still be unable to list the devices for which a
> > link key exists without root privileges, is this correct? If yes, is this
> > intentional?
>
> there is no other way, because we must store the link keys as secure as
> possible.
Sure, but my question wasn't about the link keys themselves. Why not allow
regular users to find out if there is a link key for a given device at all,
without being able to see the link key itself? I don't know if knowing about
the existance of a link key might be sensitive information, too. But at the
moment I don't see any problem with it. Bluez could create one file per
device for instance, with the bdaddr as its name and the rest in it contents.
This would still leave the type and time .. oh.. it's gone.. ok, it would
leave only the type unreadable for unprivileged users. But everybody could
take a look into the /var/lib/bluetooth/<local-bdaddr>/ dir to find out if
bluez might be paired with a given device or not.
But again, I don't really need this feature. I'm just throwing some thoughts
in the ring.
> > Anyway, I for myself don't care much about where the data goes, as long
> > as the location and the file formats stay stable, because the link key
> > manager of kdebluetooth has to be changed each time.
>
> In the long term I like to make the place totally configurable, but for
> now I think going with /var/lib/bluetooth and ASCII based files is a
> good think.
Make the paths configurable? In hcid.conf? Why would someone want *that*?
Isn't it a good thing that we can depend on the bluez files staying at a well
known place? If a weird distribution chooses to place the files in a
completely different directory, then some build time options should be
sufficient for them. Ah, ok, maybe that's just what you meant.
Fred
--
Fred Schaettgen
[email protected]
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > And second, The format of the link key file will be very simple:
> >
> > <bdaddr> <hex-linkkey> <type>
>
> This means that we will still be unable to list the devices for which a link
> key exists without root privileges, is this correct? If yes, is this
> intentional?
there is no other way, because we must store the link keys as secure as
possible.
> Anyway, I for myself don't care much about where the data goes, as long as the
> location and the file formats stay stable, because the link key manager of
> kdebluetooth has to be changed each time.
In the long term I like to make the place totally configurable, but for
now I think going with /var/lib/bluetooth and ASCII based files is a
good think.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Fred,
> > > So first the new place for runtime things like link keys, names etc. I
> > > decided to use "/var/cache/bluetooth/<bdaddr>/" as the base directory
> > > and then use the file "linkkeys" for the actual link keys. And we will
> > > use "names" for the device name cache. The "bdaddr" is the address of
> > > the local adapter.
> >
> > According to the file hierarchy standard, /var/cache is for files which
> > "can be deleted without data loss". For cached device names it's probably
> > fine. They can't be recomputed if a device isn't in reach, but if it is,
> > the device name can be fetched again automatically. But I'm not if this
> > should include link keys. They can't be regenerated automatically without
> > bothering the user. Deleting them might even break at setup, where the peer
> > device isn't reachable easiliy after initial setup. Maybe /var/lib..? I'm
> > not really an expert in this area.
>
> After thinking about it a little longer, I would even put the device name
> cache under /var/lib/bluetooth. /var/cache is intended for files with the
> purpose to reduce the load on any kind of resource, be it cpu, memory or
> network. But that's not why bluez is caching device names. It's because we
> want a reliable offline lookup capability. Caches should be completely
> transparent, but this wouldn't be the case here. If the cache is gone, then
> applications could not display a user friendly name, no matter how hard they
> try. It's the same difference as the difference between a browser cache and a
> proxy for offline browsing.
I am fine with it to put it under the /var/lib/bluetooth/ directory. The
code in the CVS has been changed now.
Regards
Marcel
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Saturday, 16. April 2005 19:32, you wrote:
> On Saturday, 16. April 2005 18:23, Marcel Holtmann wrote:
...
> > So first the new place for runtime things like link keys, names etc. I
> > decided to use "/var/cache/bluetooth/<bdaddr>/" as the base directory
> > and then use the file "linkkeys" for the actual link keys. And we will
> > use "names" for the device name cache. The "bdaddr" is the address of
> > the local adapter.
>
> According to the file hierarchy standard, /var/cache is for files which
> "can be deleted without data loss". For cached device names it's probably
> fine. They can't be recomputed if a device isn't in reach, but if it is,
> the device name can be fetched again automatically. But I'm not if this
> should include link keys. They can't be regenerated automatically without
> bothering the user. Deleting them might even break at setup, where the peer
> device isn't reachable easiliy after initial setup. Maybe /var/lib..? I'm
> not really an expert in this area.
After thinking about it a little longer, I would even put the device name
cache under /var/lib/bluetooth. /var/cache is intended for files with the
purpose to reduce the load on any kind of resource, be it cpu, memory or
network. But that's not why bluez is caching device names. It's because we
want a reliable offline lookup capability. Caches should be completely
transparent, but this wouldn't be the case here. If the cache is gone, then
applications could not display a user friendly name, no matter how hard they
try. It's the same difference as the difference between a browser cache and a
proxy for offline browsing.
Fred
--
Fred Schaettgen
[email protected]
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Saturday, 16. April 2005 18:23, Marcel Holtmann wrote:
> Hi Folks,
>
> currently the link keys are stored in a binary format and they are
> stored under the "/etc/bluetooth/" directory. Both things are not very
> handy and we should start doing something to change this.
>
> So first the new place for runtime things like link keys, names etc. I
> decided to use "/var/cache/bluetooth/<bdaddr>/" as the base directory
> and then use the file "linkkeys" for the actual link keys. And we will
> use "names" for the device name cache. The "bdaddr" is the address of
> the local adapter.
According to the file hierarchy standard, /var/cache is for files which "can
be deleted without data loss". For cached device names it's probably fine.
They can't be recomputed if a device isn't in reach, but if it is, the device
name can be fetched again automatically. But I'm not if this should include
link keys. They can't be regenerated automatically without bothering the
user. Deleting them might even break at setup, where the peer device isn't
reachable easiliy after initial setup. Maybe /var/lib..? I'm not really an
expert in this area.
> And second, The format of the link key file will be very simple:
>
> <bdaddr> <hex-linkkey> <type>
This means that we will still be unable to list the devices for which a link
key exists without root privileges, is this correct? If yes, is this
intentional?
Anyway, I for myself don't care much about where the data goes, as long as the
location and the file formats stay stable, because the link key manager of
kdebluetooth has to be changed each time.
regards
Fred
--
Fred Schaettgen
[email protected]
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel