Sorry for double-posting. I sent this email already but it seems it never
reached the list...
Hello
I've two rfcomm service running on different channels.
I wish to have one channel authenticated/encrypted, the other
unathenticated(unencrypted).
As much as I know, that means that security mode 3 won't work, security
mode 2 has to be used and I've to program this myself.
Does this mean that I've to request authentication/encryption on incoming
connections? How can I do that using bluez?
Will this provide less security/encryption than using security mode 3?
regards
Marco
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
great, thank you.
just contact me when it's done...
regards
Marco
Marcel Holtmann wrote:
> Hi Marco,
>
>
>>what's the state? interested in doing that?
>
>
> I am away until the weekend, but I am taking my patches with me and put
> them together when I have some idle time.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marco,
> what's the state? interested in doing that?
I am away until the weekend, but I am taking my patches with me and put
them together when I have some idle time.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hello Marcel
what's the state? interested in doing that?
regards
Marco
Marco Trudel wrote:
> Marcel Holtmann wrote:
>
>> Hi Marco,
>>
>>
>>>>>> the 2.6.7 will fail. The needed security hooks are introduced with
>>>>>> 2.6.10 and the RFCOMM service level security with 2.6.11 according
>>>>>> to my
>>>>>> patch logs.
>>>>>>
>>>>>>
>>>>>>> If not, which part of the kernel has to be fixed? Is it a part of
>>>>>>> bluez?
>>>>>>
>>>>>>
>>>>>> It is inside the BlueZ core and the RFCOMM layer.
>>>>>
>>>>>
>>>>> How long would you have to backport that to kernel 2.6.7?
>>>>> Maybe we can arrainge something with a donation...
>>>>
>>>>
>>>> tell me what interfaces are you going to use. Is it always USB? What
>>>> kernel layers are involved? RFCOMM, BNEP, CMTP, HIDP?
>>>
>>>
>>> always USB. RFCOMM services.
>>>
>>> authentication/encryption enabled as suggested on the list:
>>> int opt = RFCOMM_LM_AUTH|RFCOMM_LM_ENCRYPT;
>>> setsockopt(sock, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
>>
>>
>>
>> this means HCI, L2CAP, RFCOMM and hci_usb driver updates up to
>> 2.6.12-rc2 should be included.
>
>
> sounds reasonable...
>
>>>> You will need more than this two patches for a 2.6.7 based kernel,
>>>> because there are some serious problems, too.
>>>
>>>
>>> actually I never run into problems with the 2.4 kernel. But I think
>>> it would definitely make sense to have this things fixed too...
>>
>>
>>
>> Some of them were hard to trigger and there is still one RFCOMM thing
>> that is unresolved. Btw do you need a SMP or HT kernel?
>
>
> No. I don't think so.
> I work with an arm SBC with one processor and a very minimal redhat. not
> much fancy stuff...
>
> regards
> Marco
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Tell us your software development plans!
> Take this survey and enter to win a one-year sub to SourceForge.net
> Plus IDC's 2005 look-ahead and a copy of this survey
> Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
> _______________________________________________
> Bluez-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
> Hi Marco,
>
>
>>>>>the 2.6.7 will fail. The needed security hooks are introduced with
>>>>>2.6.10 and the RFCOMM service level security with 2.6.11 according to my
>>>>>patch logs.
>>>>>
>>>>>
>>>>>>If not, which part of the kernel has to be fixed? Is it a part of bluez?
>>>>>
>>>>>It is inside the BlueZ core and the RFCOMM layer.
>>>>
>>>>How long would you have to backport that to kernel 2.6.7?
>>>>Maybe we can arrainge something with a donation...
>>>
>>>tell me what interfaces are you going to use. Is it always USB? What
>>>kernel layers are involved? RFCOMM, BNEP, CMTP, HIDP?
>>
>>always USB. RFCOMM services.
>>
>>authentication/encryption enabled as suggested on the list:
>> int opt = RFCOMM_LM_AUTH|RFCOMM_LM_ENCRYPT;
>> setsockopt(sock, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
>
>
> this means HCI, L2CAP, RFCOMM and hci_usb driver updates up to
> 2.6.12-rc2 should be included.
sounds reasonable...
>>>You will need more than this two patches for a 2.6.7 based kernel,
>>>because there are some serious problems, too.
>>
>>actually I never run into problems with the 2.4 kernel. But I think it
>>would definitely make sense to have this things fixed too...
>
>
> Some of them were hard to trigger and there is still one RFCOMM thing
> that is unresolved. Btw do you need a SMP or HT kernel?
No. I don't think so.
I work with an arm SBC with one processor and a very minimal redhat. not
much fancy stuff...
regards
Marco
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marco,
> >>>the 2.6.7 will fail. The needed security hooks are introduced with
> >>>2.6.10 and the RFCOMM service level security with 2.6.11 according to my
> >>>patch logs.
> >>>
> >>>>If not, which part of the kernel has to be fixed? Is it a part of bluez?
> >>>
> >>>It is inside the BlueZ core and the RFCOMM layer.
> >>
> >>How long would you have to backport that to kernel 2.6.7?
> >>Maybe we can arrainge something with a donation...
> >
> > tell me what interfaces are you going to use. Is it always USB? What
> > kernel layers are involved? RFCOMM, BNEP, CMTP, HIDP?
>
> always USB. RFCOMM services.
>
> authentication/encryption enabled as suggested on the list:
> int opt = RFCOMM_LM_AUTH|RFCOMM_LM_ENCRYPT;
> setsockopt(sock, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
this means HCI, L2CAP, RFCOMM and hci_usb driver updates up to
2.6.12-rc2 should be included.
> > You will need more than this two patches for a 2.6.7 based kernel,
> > because there are some serious problems, too.
>
> actually I never run into problems with the 2.4 kernel. But I think it
> would definitely make sense to have this things fixed too...
Some of them were hard to trigger and there is still one RFCOMM thing
that is unresolved. Btw do you need a SMP or HT kernel?
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
> Hi Marco,
>
>
>>>>this works great with a 2.6.11 kernel.
>>>>Unfortunately I'm bound to kernel 2.4.26 or 2.6.7.
>>>>2.4.26 doesn't work. It just let's remote devices connect...
>>>>Do you know if 2.6.7 will?
>>>
>>>
>>>the 2.6.7 will fail. The needed security hooks are introduced with
>>>2.6.10 and the RFCOMM service level security with 2.6.11 according to my
>>>patch logs.
>>>
>>>
>>>>If not, which part of the kernel has to be fixed? Is it a part of bluez?
>>>
>>>
>>>It is inside the BlueZ core and the RFCOMM layer.
>>
>>How long would you have to backport that to kernel 2.6.7?
>>Maybe we can arrainge something with a donation...
>
>
> tell me what interfaces are you going to use. Is it always USB? What
> kernel layers are involved? RFCOMM, BNEP, CMTP, HIDP?
always USB. RFCOMM services.
authentication/encryption enabled as suggested on the list:
int opt = RFCOMM_LM_AUTH|RFCOMM_LM_ENCRYPT;
setsockopt(sock, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
> You will need more than this two patches for a 2.6.7 based kernel,
> because there are some serious problems, too.
actually I never run into problems with the 2.4 kernel. But I think it
would definitely make sense to have this things fixed too...
>>I assume it's easier to backport it to 2.6.7, if 2.4.26 is easier, please
>>let me know.
>
>
> The 2.6.7 backport will be end up in selecting patches and fixes small
> things, while for 2.4.26 you need to rewrite most of the patches.
ok, so it's 2.6.7...
regards
Marco
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marco,
> >>this works great with a 2.6.11 kernel.
> >>Unfortunately I'm bound to kernel 2.4.26 or 2.6.7.
> >>2.4.26 doesn't work. It just let's remote devices connect...
> >>Do you know if 2.6.7 will?
> >
> > the 2.6.7 will fail. The needed security hooks are introduced with
> > 2.6.10 and the RFCOMM service level security with 2.6.11 according to my
> > patch logs.
> >
> >>If not, which part of the kernel has to be fixed? Is it a part of bluez?
> >
> > It is inside the BlueZ core and the RFCOMM layer.
>
> How long would you have to backport that to kernel 2.6.7?
> Maybe we can arrainge something with a donation...
tell me what interfaces are you going to use. Is it always USB? What
kernel layers are involved? RFCOMM, BNEP, CMTP, HIDP?
You will need more than this two patches for a 2.6.7 based kernel,
because there are some serious problems, too.
> I assume it's easier to backport it to 2.6.7, if 2.4.26 is easier, please
> let me know.
The 2.6.7 backport will be end up in selecting patches and fixes small
things, while for 2.4.26 you need to rewrite most of the patches.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hello Marcel
Marcel Holtmann wrote:
> Hi Marco,
>
>
>>this works great with a 2.6.11 kernel.
>>Unfortunately I'm bound to kernel 2.4.26 or 2.6.7.
>>2.4.26 doesn't work. It just let's remote devices connect...
>>Do you know if 2.6.7 will?
>
>
> the 2.6.7 will fail. The needed security hooks are introduced with
> 2.6.10 and the RFCOMM service level security with 2.6.11 according to my
> patch logs.
>
>
>>If not, which part of the kernel has to be fixed? Is it a part of bluez?
>
>
> It is inside the BlueZ core and the RFCOMM layer.
How long would you have to backport that to kernel 2.6.7?
Maybe we can arrainge something with a donation...
I assume it's easier to backport it to 2.6.7, if 2.4.26 is easier, please
let me know.
>>Can this encryption be reached in another way?
>
>
> In general yes. You must call the HCI functions, but it is impossible to
> call them at the correct time (after the SABM).
ok. so backporting would be the best option.
>>Where are the link keys saved? I'm unable to find them.
>
>
> Starting with bluez-utils-2.16 under /var/lib/bluetooth/*/linkkeys.
found them, thank you.
>>Is there something that has to be paid attention to if I do encryption like
>>this? Does the password/Dongle/... influence the encryption strength?
>
>
> The encryption key size is the only thing that may vary. For CSR chips
> it can be between 56 bits and 128 bits depending on the firmware.
ok. thank you.
regards
Marco
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Marco,
> this works great with a 2.6.11 kernel.
> Unfortunately I'm bound to kernel 2.4.26 or 2.6.7.
> 2.4.26 doesn't work. It just let's remote devices connect...
> Do you know if 2.6.7 will?
the 2.6.7 will fail. The needed security hooks are introduced with
2.6.10 and the RFCOMM service level security with 2.6.11 according to my
patch logs.
> If not, which part of the kernel has to be fixed? Is it a part of bluez?
It is inside the BlueZ core and the RFCOMM layer.
> Can this encryption be reached in another way?
In general yes. You must call the HCI functions, but it is impossible to
call them at the correct time (after the SABM).
> Where are the link keys saved? I'm unable to find them.
Starting with bluez-utils-2.16 under /var/lib/bluetooth/*/linkkeys.
> Is there something that has to be paid attention to if I do encryption like
> this? Does the password/Dongle/... influence the encryption strength?
The encryption key size is the only thing that may vary. For CSR chips
it can be between 56 bits and 128 bits depending on the firmware.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Thank you, this works great with a 2.6.11 kernel.
Unfortunately I'm bound to kernel 2.4.26 or 2.6.7.
2.4.26 doesn't work. It just let's remote devices connect...
Do you know if 2.6.7 will?
If not, which part of the kernel has to be fixed? Is it a part of bluez?
Can this encryption be reached in another way?
Where are the link keys saved? I'm unable to find them.
Is there something that has to be paid attention to if I do encryption like
this? Does the password/Dongle/... influence the encryption strength?
regards
Marco
Fred Schaettgen wrote:
> On Tuesday, 26. April 2005 11:39, Marco Trudel wrote:
>
>>I've two rfcomm service running on different channels.
>>I wish to have one channel authenticated/encrypted, the other
>>unathenticated(unencrypted).
>>
>>As much as I know, that means that security mode 3 won't work, security
>>mode 2 has to be used and I've to program this myself.
>>
>>Does this mean that I've to request authentication/encryption on incoming
>>connections?
>
>
> Yes.
>
>
>>How can I do that using bluez?
>
>
> int opt = RFCOMM_LM_AUTH | RFCOMM_LM_ENCRYPT;
> setsockopt(s, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
>
>
>>Will this provide less security/encryption than using security mode 3?
>
>
> No, but you will need a recent kernel. For older kernels it will simply not
> work, and IIRC the call even failed silently without reporting an error in
> one kernel version. Can't remember which one it was though. 2.6.8 or 9 maybe?
>
> Fred
>
-------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Tuesday, 26. April 2005 11:39, Marco Trudel wrote:
> I've two rfcomm service running on different channels.
> I wish to have one channel authenticated/encrypted, the other
> unathenticated(unencrypted).
>
> As much as I know, that means that security mode 3 won't work, security
> mode 2 has to be used and I've to program this myself.
>
> Does this mean that I've to request authentication/encryption on incoming
> connections?
Yes.
> How can I do that using bluez?
int opt = RFCOMM_LM_AUTH | RFCOMM_LM_ENCRYPT;
setsockopt(s, SOL_RFCOMM, RFCOMM_LM, &opt, sizeof(opt));
> Will this provide less security/encryption than using security mode 3?
No, but you will need a recent kernel. For older kernels it will simply not
work, and IIRC the call even failed silently without reporting an error in
one kernel version. Can't remember which one it was though. 2.6.8 or 9 maybe?
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users