Hi folks,
This is the initial patch to support authentication. There are improving
points
that I am planning send soon if everybody agree with my proposal.
The authentication function of this patch is not checking the authentication
complete event status. Clients should not use a blocking send method because
NO reply is being sent if the hci_send_req returns success.
There two possible solutions:
1. Change the security.c file to filter for authentication event and send a
SIGNAL with the bdaddr and the status
1. Change the security.c file to filter for authentication event and send a
METHOD REPLY with the bdaddr and the status. For this case will be required
keep the method_call message received in the service request.
>>>How test it:
- remove the linkkeys file :)
- use hcitool cc AA:BB:CC:DD:EE:FF to establish a connection
- send the D-BUS msg
$ dbus-send --system --dest='org.bluez' --type=method_call
/org/bluez/Manager/default/Controller
org.bluez.Manager.Authenticatestring:"AA:BB:CC:DD:EE:FF"
>>> Next action:
1. Change the reply
2. Change the pin helper to avoid blocking operation. Pipe should be
avoided. Maybe it's
possible add the file descriptor in the main loop instead of wait for data.
3. Support for re-authentication - It will be required add functions to
remove an entry from
the linkkey file.
Regards,
Claudio.
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
Hi Eduardo,
> here is the patch for /org/bluez/Device. It adds the function
> DeviceList that returns the list of registered devices in the machine.
> For each device I'm returning (device name, addr, type, up/down, and
> an array of capability). I've also splitted some functions that was
> used in conjuction with /org/bluez/Manager. I've also included a
> python client for test.
the patch is in the CVS now, but I had to do housekeeping of the coding
style again. Especially the whitespaces. So please use an editor that
visualizes the whitespaces and tabs for you. This really helps to keep
the code clean.
I like the idea with the test program. I think we need a lot more
command line based test programs to verify the D-Bus interface. After
another walk-through the code, I realized that nobody actually bothered
about big endian system. So we need some regression tests.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the patch for /org/bluez/Device. It adds the function
DeviceList that returns the list of registered devices in the machine.
For each device I'm returning (device name, addr, type, up/down, and
an array of capability). I've also splitted some functions that was
used in conjuction with /org/bluez/Manager. I've also included a
python client for test.
BR,
Eduardo.
On 10/27/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > The signal has two arguments now:
> > - String: peer address
> > - Byte: authentication status
>
> the patch is in the CVS now.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> The signal has two arguments now:
> - String: peer address
> - Byte: authentication status
the patch is in the CVS now.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
done!
The signal has two arguments now:
- String: peer address
- Byte: authentication status
Regards,
Claudio.
On 10/27/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > Here are the patches based on the lastest BlueZ CVS. I am sending both
> > approaches.
> > Using signals is more clear in hcid side, however the clients will
> > have to add flags to indicate that there is a authentication pending.
> > Another problem is the error, using signals will not be possible send
> > D-Bus error messages, therefore client will have to translate the
> > status to a success or errors result.
>
> we need the signal anyway, because a second application might be request
> the authentication and if your first application displays different
> icons for authenticated or unauthenticated connection then it should be
> told that this connection is now authenticated. The same applies for the
> encryption.
>
> > PS: This is the message content for both approachs:
> > * Signal approach
> > >>> D-Bus AuthenticationComplete signal
> > - String: peer bt address
> > - Byte: status
> > - Uint16: handle
>
> We don't need the handle and the address. Use the address only, because
> connection handles should be only used in hcid and the kernel.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> Here are the patches based on the lastest BlueZ CVS. I am sending both
> approaches.
> Using signals is more clear in hcid side, however the clients will
> have to add flags to indicate that there is a authentication pending.
> Another problem is the error, using signals will not be possible send
> D-Bus error messages, therefore client will have to translate the
> status to a success or errors result.
we need the signal anyway, because a second application might be request
the authentication and if your first application displays different
icons for authenticated or unauthenticated connection then it should be
told that this connection is now authenticated. The same applies for the
encryption.
> PS: This is the message content for both approachs:
> * Signal approach
> >>> D-Bus AuthenticationComplete signal
> - String: peer bt address
> - Byte: status
> - Uint16: handle
We don't need the handle and the address. Use the address only, because
connection handles should be only used in hcid and the kernel.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
sorry... The attachment was missing :)
On 10/27/05, Claudio Takahasi <[email protected]> wrote:
> Hi Marcel,
>
> Here are the patches based on the lastest BlueZ CVS. I am sending both
> approaches.
> Using signals is more clear in hcid side, however the clients will
> have to add flags to indicate that there is a authentication pending.
> Another problem is the error, using signals will not be possible send
> D-Bus error messages, therefore client will have to translate the
> status to a success or errors result.
>
> I understand that store atributes to create a reply later is not a
> clean solution but I don't see another solution. Using a peer message
> it's possible reply errors properly and it easier develop the python/c
> clients
>
> I think it's better ask py-dbus developers about this. I prefer the
> peer message reply approach.
>
> Regards,
> Claudio
>
> PS: This is the message content for both approachs:
> * Signal approach
> >>> D-Bus AuthenticationComplete signal
> - String: peer bt address
> - Byte: status
> - Uint16: handle
>
> * For method return approach
> >>> D-Bus method return msg
> - String: peer bt address
> - Byte: handle
> >>> D-Bus error msg
> - String: error description
> - uint32: error code
>
> On 10/26/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Claudio,
> >
> > > Here are the patches to send the authentication result, please DON'T
> > > commit it. Probably
> > > it will conflict with the latest Eduardo's patch.
> > >
> > > Which approach do you preffer?
> > > 1. Send a signal
> > > 2. Send a method return (peer message)
> >
> > I think that a signal to inform the applications that a connection is
> > now authenticated (and also encrypted) is a good idea.
> >
> > Eduardos patches are now in the CVS. So you can re-create yours.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by the JBoss Inc.
> > Get Certified Today * Register for a JBoss Training Course
> > Free Certification Exam for All Training Attendees Through End of 2005
> > Visit http://www.jboss.com/services/certification for more information
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Instituto Nokia de Tecnologia - INdT
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Marcel,
Here are the patches based on the lastest BlueZ CVS. I am sending both
approaches.
Using signals is more clear in hcid side, however the clients will
have to add flags to indicate that there is a authentication pending.
Another problem is the error, using signals will not be possible send
D-Bus error messages, therefore client will have to translate the
status to a success or errors result.
I understand that store atributes to create a reply later is not a
clean solution but I don't see another solution. Using a peer message
it's possible reply errors properly and it easier develop the python/c
clients
I think it's better ask py-dbus developers about this. I prefer the
peer message reply approach.
Regards,
Claudio
PS: This is the message content for both approachs:
* Signal approach
>>> D-Bus AuthenticationComplete signal
- String: peer bt address
- Byte: status
- Uint16: handle
* For method return approach
>>> D-Bus method return msg
- String: peer bt address
- Byte: handle
>>> D-Bus error msg
- String: error description
- uint32: error code
On 10/26/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > Here are the patches to send the authentication result, please DON'T
> > commit it. Probably
> > it will conflict with the latest Eduardo's patch.
> >
> > Which approach do you preffer?
> > 1. Send a signal
> > 2. Send a method return (peer message)
>
> I think that a signal to inform the applications that a connection is
> now authenticated (and also encrypted) is a good idea.
>
> Eduardos patches are now in the CVS. So you can re-create yours.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Here are the patches to send the authentication result, please DON'T
> commit it. Probably
> it will conflict with the latest Eduardo's patch.
>
> Which approach do you preffer?
> 1. Send a signal
> 2. Send a method return (peer message)
I think that a signal to inform the applications that a connection is
now authenticated (and also encrypted) is a good idea.
Eduardos patches are now in the CVS. So you can re-create yours.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
Here are the patches to send the authentication result, please DON'T
commit it. Probably
it will conflict with the latest Eduardo's patch.
Which approach do you preffer?
1. Send a signal
2. Send a method return (peer message)
Regards,
Claudio.
On 10/24/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > I will send a cleanup patch before send the authentication
> > improvements patch.
> > Regarding the variable name, It should be better change to "dd"
> > instead of
> > sock or sk. If you see the hcitool code standard you will notice
> > that.
>
> I am fine with dd. My point was to be consistent.
>
> > I noticed that there is a HCI raw socket created in the main.c file
> > that belongs to hcid structure.
> > Can I use it in the functions handle_display_conn_req and
> > handle_get_devices_req instead of create
> > a new one?
>
> Open a new one, because the HCI filter is per descriptor and you don't
> wanna mess with the filter of the HCI socket in main.c.
>
> > I will try apply you other suggestions.
>
> Cool.
>
> > Another point is the reply method for authentication. We need discuss
> > how we should design it.
> > I am not a hcid expert therefore I would like ask you how we should
> > implement the authentication stuff.
> >
> > Currently, the METHOD REPLY of the authentication doesn't consider the
> > authentication complete event.
> > In order to check it and reply after the authentication finishes it is
> > required store some D-Bus message
> > attributes(sender, serial, destination, ...). Another approach is send
> > a SIGNAL. Which approach do you prefer
> > send send a peer message(method reply) or a signal?
>
> In generell everything authentication or encryption related should be
> done inside the kernel. However the infrastructure is not there yet and
> so keep it as simple as possible.
>
> > Regarding the pin helper. Are you planning support the "normal" helper
> > and the dbus helper? I am asking
> > this because the call_pin_helper function is blocking. If you are
> > planning support both, we have to try add
> > the pin helper file descriptor inside the hcid main loop.
>
> My plan is to require D-Bus for bluez-utils, but so far I haven't
> received any comments on it. The main problem is that the distributions
> must move to a decent version of D-Bus and Debian unstable is still on
> D-Bus 0.23. Actually any D-Bus 0.3x will not work very good and so we
> might need to support the "normal" PIN helper for some time. I am open
> for changes, because the PIN helper code in generell is not that good.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc.
> Get Certified Today * Register for a JBoss Training Course
> Free Certification Exam for All Training Attendees Through End of 2005
> Visit http://www.jboss.com/services/certification for more information
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> I will send a cleanup patch before send the authentication
> improvements patch.
> Regarding the variable name, It should be better change to "dd"
> instead of
> sock or sk. If you see the hcitool code standard you will notice
> that.
I am fine with dd. My point was to be consistent.
> I noticed that there is a HCI raw socket created in the main.c file
> that belongs to hcid structure.
> Can I use it in the functions handle_display_conn_req and
> handle_get_devices_req instead of create
> a new one?
Open a new one, because the HCI filter is per descriptor and you don't
wanna mess with the filter of the HCI socket in main.c.
> I will try apply you other suggestions.
Cool.
> Another point is the reply method for authentication. We need discuss
> how we should design it.
> I am not a hcid expert therefore I would like ask you how we should
> implement the authentication stuff.
>
> Currently, the METHOD REPLY of the authentication doesn't consider the
> authentication complete event.
> In order to check it and reply after the authentication finishes it is
> required store some D-Bus message
> attributes(sender, serial, destination, ...). Another approach is send
> a SIGNAL. Which approach do you prefer
> send send a peer message(method reply) or a signal?
In generell everything authentication or encryption related should be
done inside the kernel. However the infrastructure is not there yet and
so keep it as simple as possible.
> Regarding the pin helper. Are you planning support the "normal" helper
> and the dbus helper? I am asking
> this because the call_pin_helper function is blocking. If you are
> planning support both, we have to try add
> the pin helper file descriptor inside the hcid main loop.
My plan is to require D-Bus for bluez-utils, but so far I haven't
received any comments on it. The main problem is that the distributions
must move to a decent version of D-Bus and Debian unstable is still on
D-Bus 0.23. Actually any D-Bus 0.3x will not work very good and so we
might need to support the "normal" PIN helper for some time. I am open
for changes, because the PIN helper code in generell is not that good.
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
I will send a cleanup patch before send the authentication improvements
patch.
Regarding the variable name, It should be better change to "dd" instead of
sock or sk. If you see the hcitool code standard you will notice that.
I noticed that there is a HCI raw socket created in the main.c file that
belongs to hcid structure.
Can I use it in the functions handle_display_conn_req and
handle_get_devices_req instead of create
a new one?
I will try apply you other suggestions.
Another point is the reply method for authentication. We need discuss how we
should design it.
I am not a hcid expert therefore I would like ask you how we should
implement the authentication stuff.
Currently, the METHOD REPLY of the authentication doesn't consider the
authentication complete event.
In order to check it and reply after the authentication finishes it is
required store some D-Bus message
attributes(sender, serial, destination, ...). Another approach is send a
SIGNAL. Which approach do you prefer
send send a peer message(method reply) or a signal?
Regarding the pin helper. Are you planning support the "normal" helper and
the dbus helper? I am asking
this because the call_pin_helper function is blocking. If you are planning
support both, we have to try add
the pin helper file descriptor inside the hcid main loop.
Regards,
Claudio.
On 10/22/05, Marcel Holtmann <[email protected]> wrote:
>
> Hi Claudio,
>
> > This is the initial patch to support authentication. There are
> > improving points
> > that I am planning send soon if everybody agree with my proposal.
>
> I applied the patch, but please do the coding style right. It seems that
> you still copy some parts for your old patches.
>
> if (sock > 0)
> close (sock);
>
> I first prefer to use "sk" instead of "sock", but this hasn't been used
> in full consistency and so I didn't corrected it. However you need to
> check for (sock >= 0) in case of a socket or file descriptor and we
> don't put a space between the function name and its parameters. So it
> must be called "close(sock);" in any case.
>
> It is also better to introduce more error labels than using another if
> statement to check for state of a file descriptor. We now if the file
> descriptor is valid or not.
>
> Regards
>
> Marcel
>
>
>
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
Hi Claudio,
> This is the initial patch to support authentication. There are
> improving points
> that I am planning send soon if everybody agree with my proposal.
I applied the patch, but please do the coding style right. It seems that
you still copy some parts for your old patches.
if (sock > 0)
close (sock);
I first prefer to use "sk" instead of "sock", but this hasn't been used
in full consistency and so I didn't corrected it. However you need to
check for (sock >= 0) in case of a socket or file descriptor and we
don't put a space between the function name and its parameters. So it
must be called "close(sock);" in any case.
It is also better to introduce more error labels than using another if
statement to check for state of a file descriptor. We now if the file
descriptor is valid or not.
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