Hi Marcel/folks,
There is a new patch available.
What was the final decision about the path name?
I read the e-mails exchanged in the D-Bus mailing list. Due the
instability/side-effects of the support '-' for path
names, I think is not a good idea support it. I will keep the "hci" device
name in the path until we find a good solution.
Do you have any suggestions or changes before integrate this code?
Regards,
Claudio.
>>>>Main Features
1. Fixed fallback, the Manager is now returning BLUEZ_EDBUS_UNKNOWN_PATH
when the device was detached.
2. Code style changed
3. Removed memory leak
>>>>Next Action
1. Move the functions to to suitable file names( eg: dbus-mgr.c and
dbus-dev.c)
2. Define the device based path name.
3. Implement /org/bluez/Devices services
On 10/4/05, Claudio Takahasi <[email protected]> wrote:
>
> Hi folks/Johan,
>
> Sorry, I forgot remove it.
> I fixed it in this new patch.
>
> Regards,
> Claudio
>
> On 10/4/05, Johan Hedberg <[email protected]> wrote:
> >
> > Hi Claudio,
> >
> > I see that you have removed "Req" from the end of method call names.
> > However, you still have "Sig" appended to the signal names. Is that
> > intentional or have you just forgotten to remove that?
> >
> > Johan
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
> > discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Nokia's Institute of Technology - INdT
> [email protected]
>
>
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
Hello Marcel,
Well today I got hands on Level-1 MDU-0025USB, it is BlueCore04-external
and comes with Toshiba Windows stack, it has only 56bit encryption, even
though package says 128bit, :( The german homepage is http://www.level-one.de
Here are the hciconfig outputs:
-- revision:
hci0: Type: USB
BD Address: 00:09:DD:50:01:C8 ACL MTU: 384:8 SCO MTU: 64:8
HCI 19.2
Chip version: BlueCore4-External
Max key size: 56 bit
SCO mapping: HCI
-- hciconfig -a:
hci0: Type: USB
BD Address: 00:09:DD:50:01:C8 ACL MTU: 384:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN AUTH ENCRYPT
RX bytes:1525 acl:0 sco:0 events:51 errors:0
TX bytes:950 acl:0 sco:0 commands:50 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'Raindrop-3B'
Class: 0x000100
Service Classes: Unspecified
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x77b LMP Ver: 2.0 (0x3) LMP Subver: 0x77b
Manufacturer: Cambridge Silicon Radio (10)
-- features:
hci0: Type: USB
BD Address: 00:09:DD:50:01:C8 ACL MTU: 384:8 SCO MTU: 64:8
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80
<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> <paging scheme>
<power control> <transparent SCO> <broadcast encrypt>
<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>
<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>
And here is the little table of 2.0 dongles I found:
MANUF MODEL CHIP WINSTCK HOMEPAGE
Tecom BT3034EDR (EDR) Broadcom Widcomm http://www.tecomproduct.com/BT3034.htm
Cellink BTA-6030 (EDR) CSR BlueCore04 ??? http://www.cellink.com.tw/pro-bta-6030.htm
Planex BT-01UDE (EDR) CSR BlueCore04 Toshiba http://www.planex.net/product/bluetooth/bt-01ude.htm
Level1 MDU-0025USB (EDR) CSR BlueCore04 Toshiba http://www.levelone.si/products3.php?sklop=24&id=590025
Planex one I've never seen either, one of my friends is an exchenge
student in Malmo Sweden, and he saw this one in shop there, maybe I can
persuade him to get me one for christmas. For Tecom dongle I am harassing .si
distributor to order them for about 2 monoths now, and they keep saying the
can not get it. And .si Cellink distrubitor only sells headsets. :(
Where can you buy them in Germany I would not know, I found cellink one on
blueunplugged and tecom on ebay.
Best regards,
Mitja
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> Thanks for the enlightening description of pointer-integer typecast
> dangers Steven! I'll provide a patch which adds the struct that Marcel
> suggested after Claudio's latest patch has been commited to CVS.
Please do so.
The anonymous CVS is always a little bit behind. Blame the Sourceforge
guys for this, but it should now be in sync.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mitja,
> Has anyone experience with Level 1 MDU-0025USB? It is fairly cheap and
> homepage promises nice profile support in win stack. Does anyone know if
> it is BlueCore4 based and which win stack is supplied with it.
>
> Or if someone can suggest me the best one from this list:
> MANUF MODEL CHIP WINSTCK
> Tecom BT3034EDR (EDR) ??? Widcomm
> Cellink BTA-6030 (EDR) CSR BlueCore04 ???
> Planex BT-01UDE (EDR) CSR BlueCore04 Toshiba
> Level1 MDU-0025USB (EDR) ??? ???
>
> Last one is the only one I can get in Slovenia, all others I would need to
> order online and I would mostly like to avoid this situation.
I have no idea. The Cellink is for real, but you need to use pskey to
tweak some settings. The Planex is new to me. Where can I get one of
these? For the rest I don't know, but if you tell me a shop where I can
buy them in Germany, I will do so and let you know.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Has anyone experience with Level 1 MDU-0025USB? It is fairly cheap and
homepage promises nice profile support in win stack. Does anyone know if
it is BlueCore4 based and which win stack is supplied with it.
Or if someone can suggest me the best one from this list:
MANUF MODEL CHIP WINSTCK
Tecom BT3034EDR (EDR) ??? Widcomm
Cellink BTA-6030 (EDR) CSR BlueCore04 ???
Planex BT-01UDE (EDR) CSR BlueCore04 Toshiba
Level1 MDU-0025USB (EDR) ??? ???
Last one is the only one I can get in Slovenia, all others I would need to
order online and I would mostly like to avoid this situation.
Thanks in advance,
Mitja
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Thanks for the enlightening description of pointer-integer typecast
dangers Steven! I'll provide a patch which adds the struct that Marcel
suggested after Claudio's latest patch has been commited to CVS.
Johan
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Johan Hedberg wrote:
>> Yeah, I suspected that could cause problems since
>> sizeof(int) != sizeof(void *) on those machines. I don't think those
>> compiler warnings are dangerous though, since they are probably meant to
>> warn about possible loss of data which shouldn't happen to us since our
>> values always fit within 2 bytes.
Compiler warning are always dangerous.
At the very least, they can obscure the warnings you care about.
>> I don't have a 64bit machine so I
>> can't verify this fix, but I think that sizeof(long) should be the same
>> as sizeof(void *) on both 32 and 64 bit machines. If that isn't the
>> case, the last resort could be to make some automake makro to check the
>> actual size of pointer types and add #defines to the code acordingly.
If you, really, really, really want to stuff integers into pointers then
you should be using the type uintptr_t defined in <inttypes.h>, but even
this isn't safe.
uintptr_t is guaranteed only to be an integer type large enough to hold
all object pointer types (this excludes function pointers). However,
it's not guaranteed that a void * can hold all uintptr_t values or even
that it will hold any consecutive subset. That is, your assertion that
you're safe because all your values fit in 2 bytes is not strictly true
(although it may be true on many architectures).
There's another problem in that even referring to a pointer value that
points to freed memory leads you into undefined behaviour even if you
don't dereference the pointer. This means that code like this:
free(p);
if (q != p)
free(q);
isn't safe. See:
http://mail-index.netbsd.org/current-users/2005/07/30/0005.html
This makes it safe for a compiler author targetting an architecture
with separate address and data registers to load pointer values into
an address register even if the act of loading an invalid pointer into
a register causes an address exception without the address being
dereferenced.
(If you think about it, this would be quite handy for authors of
debug tools like electric fence - they could generate an exception
as soon as you though about using an invalid pointer rather than
several days later when you finally get round to dereferencing it).
So, if one of the integers you've cast into a void * happens to
match memory that's been freed then you're in trouble.
Basically, this:
void *p;
uintptr_t tmp; /* or any suitable integer type such as long */
/* ... */
tmp = (uintptr_t) p;
/* ... */
p = (void *) tmp;
is safe, but:
void *tmp;
uintptr_t *i; /* or any suitable integer type such as long */
/* ... */
tmp = (void *) i;
/* ... */
i = (uintptr_t) tmp;
Takes you into a world of undefined behaviour.
>> Anyway, the attached patch uses long for the pointer<->integer
>> typecasts. Let me know if it doesn't work.
>
> I applied your patch and the compiler on my 64-bit machine is much
> happier now, but I think that we need to allocate a structure and pass
> the pointer to it around instead of some casting tricks. Would you mind
> fixing it?
This is the right solution.
Speaking from experience, saying "I only need to store an integer so I
can save myself a malloc and, instead, cast it to a pointer" is a false
economy. Next week you'll suddenly find the implementation gets easier
if you can store two integers, then the week after, an integer and a
char * and so on.
On a resource constrained embedded system where the cost of the extra
allocation may be excessive, the only solution is to redesign the
library from the ground up replacing the void * with a union of a
void * and a long.
- Steven
--
This message has been scanned for viruses by BlackSpider MailControl - http://www.blackspider.com
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > I applied your patch and the compiler on my 64-bit machine is much
> > happier now, but I think that we need to allocate a structure and pass
> > the pointer to it around instead of some casting tricks. Would you mind
> > fixing it?
>
> I'm not really sure what you mean. Is there some other information
> besides the device id that needs to be passed around (i.e. what should
> go into this struct)? If we start using allocated structs it means that
> a lot of the memory handling stuff that my first patch removed needs to
> go back.
I know, but this is the only clean way. The casts are a little bit too
ugly. However since hcid is only a playfield for the the D-Bus support,
I think we can live with it. For bluetoothd this code will be too ugly,
but we might change it anyhow and use or own event loop implementation.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Oct 11, 2005, Marcel Holtmann wrote:
> I applied your patch and the compiler on my 64-bit machine is much
> happier now, but I think that we need to allocate a structure and pass
> the pointer to it around instead of some casting tricks. Would you mind
> fixing it?
I'm not really sure what you mean. Is there some other information
besides the device id that needs to be passed around (i.e. what should
go into this struct)? If we start using allocated structs it means that
a lot of the memory handling stuff that my first patch removed needs to
go back.
Johan
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > I applied the patch, but this can't be the final solution. It will
> > produce weird stuff on 64-bit machines:
>
> Yeah, I suspected that could cause problems since
> sizeof(int) != sizeof(void *) on those machines. I don't think those
> compiler warnings are dangerous though, since they are probably meant to
> warn about possible loss of data which shouldn't happen to us since our
> values always fit within 2 bytes. I don't have a 64bit machine so I
> can't verify this fix, but I think that sizeof(long) should be the same
> as sizeof(void *) on both 32 and 64 bit machines. If that isn't the
> case, the last resort could be to make some automake makro to check the
> actual size of pointer types and add #defines to the code acordingly.
>
> Anyway, the attached patch uses long for the pointer<->integer
> typecasts. Let me know if it doesn't work.
I applied your patch and the compiler on my 64-bit machine is much
happier now, but I think that we need to allocate a structure and pass
the pointer to it around instead of some casting tricks. Would you mind
fixing it?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Mon, Oct 10, 2005, Marcel Holtmann wrote:
> I applied the patch, but this can't be the final solution. It will
> produce weird stuff on 64-bit machines:
Yeah, I suspected that could cause problems since
sizeof(int) != sizeof(void *) on those machines. I don't think those
compiler warnings are dangerous though, since they are probably meant to
warn about possible loss of data which shouldn't happen to us since our
values always fit within 2 bytes. I don't have a 64bit machine so I
can't verify this fix, but I think that sizeof(long) should be the same
as sizeof(void *) on both 32 and 64 bit machines. If that isn't the
case, the last resort could be to make some automake makro to check the
actual size of pointer types and add #defines to the code acordingly.
Anyway, the attached patch uses long for the pointer<->integer
typecasts. Let me know if it doesn't work.
Johan
Hi Johan,
> I took a closer look at the latest D-BUS patch and made a couple of
> fixes. A rather severe bug was that only 1 byte was allocated for the
> data pointer in the object path functions, but a uint16_t value was
> written to it. The attached patch removes the need to allocate this
> memory alltogether by typecasting the integer values directly to the
> void pointer (perhaps not a very "beautiful" solution, but it works and
> simplifies the code quite a lot). The patch also contains some general
> cleanup (removal of unecessary typecasts, etc).
I applied the patch, but this can't be the final solution. It will
produce weird stuff on 64-bit machines:
dbus.c: In function =E2=80=98add_watch=E2=80=99:
dbus.c:525: warning: cast to pointer from integer of different size
dbus.c: In function =E2=80=98remove_watch=E2=80=99:
dbus.c:532: warning: cast from pointer to integer of different size
dbus.c: In function =E2=80=98hci_dbus_reg_obj_path=E2=80=99:
dbus.c:731: warning: cast to pointer from integer of different size
dbus.c: In function =E2=80=98msg_func=E2=80=99:
dbus.c:829: warning: cast from pointer to integer of different size
dbus.c: In function =E2=80=98handle_periodic_inq_req=E2=80=99:
dbus.c:921: warning: cast from pointer to integer of different size
dbus.c: In function =E2=80=98handle_cancel_periodic_inq_req=E2=80=99:
dbus.c:1000: warning: cast from pointer to integer of different size
dbus.c: In function =E2=80=98handle_inq_req=E2=80=99:
dbus.c:1046: warning: cast from pointer to integer of different size
dbus.c: In function =E2=80=98handle_role_switch_req=E2=80=99:
dbus.c:1115: warning: cast from pointer to integer of different size
Patches to fix this are welcome.
> Then, about the signals sent for inquiry result and name request. You
> currently also send the local BT address in the message parameters.
> Isn't that redundant since the local device should be evident from the
> object path that the message originates from? I know that the path isn'=
t
> currently set properly for these signals, but in the future it probably
> should.
Please send in a patch to fix this.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
I took a closer look at the latest D-BUS patch and made a couple of
fixes. A rather severe bug was that only 1 byte was allocated for the
data pointer in the object path functions, but a uint16_t value was
written to it. The attached patch removes the need to allocate this
memory alltogether by typecasting the integer values directly to the
void pointer (perhaps not a very "beautiful" solution, but it works and
simplifies the code quite a lot). The patch also contains some general
cleanup (removal of unecessary typecasts, etc).
Then, about the signals sent for inquiry result and name request. You
currently also send the local BT address in the message parameters.
Isn't that redundant since the local device should be evident from the
object path that the message originates from? I know that the path isn't
currently set properly for these signals, but in the future it probably
should.
Johan
Hi Claudio,
> The basic configuration file is attached. We can define better
> policies after. Check the dbus-daemon man for more policies
> information.
>
> The hcid.conf file have to be copied to /etc/dbus-1/system.d/
this looks like an old version of the file. I committed a new version as
dbus.conf to the CVS.
After some basic cleanups your patch is now in the CVS. I am not fully
happy with parts of it, but we need a starting point now. I like to
invite everybody to help us out with the D-Bus support. The goal for the
next release should be a D-Bus interface for the device discovery.
Can someone write a Python based application that uses the D-Bus
interface of hcid to inquiry devices and present them?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
The basic configuration file is attached. We can define better
policies after. Check the dbus-daemon man for more policies information.
The hcid.conf file have to be copied to /etc/dbus-1/system.d/
Regards,
Claudio.
On 10/8/05, Marcel Holtmann <[email protected]> wrote:
>
> Hi Claudio,
>
> > What was the final decision about the path name?
>
> There is non at the moment.
>
> > I read the e-mails exchanged in the D-Bus mailing list. Due the
> > instability/side-effects of the support '-' for path
> > names, I think is not a good idea support it. I will keep the "hci"
> > device name in the path until we find a good solution.
>
> No problem. We will adjust it later.
>
> > Do you have any suggestions or changes before integrate this code?
>
> I applied this patch to my local tree and now I have to clean it up. You
> should really follow my advises on tabs, whitespaces etc. A good idea is
> to use an editor that will visualize tabs and whitespaces for you.
>
> Can you provide hcid.conf security settings file for the current
> services?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
Hi Claudio,
> What was the final decision about the path name?
There is non at the moment.
> I read the e-mails exchanged in the D-Bus mailing list. Due the
> instability/side-effects of the support '-' for path
> names, I think is not a good idea support it. I will keep the "hci"
> device name in the path until we find a good solution.
No problem. We will adjust it later.
> Do you have any suggestions or changes before integrate this code?
I applied this patch to my local tree and now I have to clean it up. You
should really follow my advises on tabs, whitespaces etc. A good idea is
to use an editor that will visualize tabs and whitespaces for you.
Can you provide hcid.conf security settings file for the current
services?
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel