Hi,
I've been looking at pan profile and saw some mandatory fields in the
sdp records were missing.
The problem is that these fields are user dependent. How to set them?
Security Description, NetAccessType and MaxNetAccessRate.
There are several issues to the problem :
- patching pand is easy but some more options are needed to customize
fields (unless good defaults exists)
- using 'sdptool add' then 'sdptool set attr' is a bit unreadable
- patching sdptool with more arguments?
- using the dbus xml api still requires to patch pand or sdptool.
- Other?
Is there a prefered way to do so?
Regards,
--
Frederic
Without the wind, the grass does not move.
-------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic,
> > for an initial patch, I think we only change sdp.c with appropriate
> > default values to make it specification conform.
> >
> Here is new patch proposal.
the patch has been committed to the CVS. Thanks.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic,
> >> What about this patch then?
> >>
> >
> > looks good, but ...
> >
> > Why do we need add_lang_attr(). This is actually not mandatory as far as I remember.
> >
> > Do we have to make name and description configurable. Do you need it?
> >
> > The security_desc should be automatically determined from the actually -E, -A or -S parameters.
> >
> > The network access type and rate make sense to me. However I prefer if we simply hand them over via parameters instead of creating another struct.
> >
> >
> lang, name, description are all mandatory attributes. I'm not sure if
> their actually must have a language in the list.
> I have no specific requirement according to their values yet.
> Using a struct allows to make name and desc configurable without adding
> new parameters and forwarding from function to function.
>
> So two choices remains :
> - keeping only the sdp.c part is enough to conform the spec.
> - Doing everything and making all values configurable is quick (but the
> option letters will be strange ;) ).
for an initial patch, I think we only change sdp.c with appropriate
default values to make it specification conform. The configurable has to
wait and maybe we only do that in the new network service. In general
the daemon should autodetect these values from the interface or the
bridge (not that I know how at the moment).
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
>>>> There are several issues to the problem :
>>>> - patching pand is easy but some more options are needed to customize
>>>> fields (unless good defaults exists)
>>>>
>>>>
>>> we need good default values and some extra parameters to change them. I
>>> am all for this way.
>>>
>>>
>> What about this patch then?
>>
>
> looks good, but ...
>
> Why do we need add_lang_attr(). This is actually not mandatory as far as I remember.
>
> Do we have to make name and description configurable. Do you need it?
>
> The security_desc should be automatically determined from the actually -E, -A or -S parameters.
>
> The network access type and rate make sense to me. However I prefer if we simply hand them over via parameters instead of creating another struct.
>
>
lang, name, description are all mandatory attributes. I'm not sure if
their actually must have a language in the list.
I have no specific requirement according to their values yet.
Using a struct allows to make name and desc configurable without adding
new parameters and forwarding from function to function.
So two choices remains :
- keeping only the sdp.c part is enough to conform the spec.
- Doing everything and making all values configurable is quick (but the
option letters will be strange ;) ).
-------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic,
> >> There are several issues to the problem :
> >> - patching pand is easy but some more options are needed to customize
> >> fields (unless good defaults exists)
> >>
> >
> > we need good default values and some extra parameters to change them. I
> > am all for this way.
> >
>
> What about this patch then?
looks good, but ...
Why do we need add_lang_attr(). This is actually not mandatory as far as I remember.
Do we have to make name and description configurable. Do you need it?
The security_desc should be automatically determined from the actually -E, -A or -S parameters.
The network access type and rate make sense to me. However I prefer if we simply hand them over via parameters instead of creating another struct.
> I still have a modified rfcomm man page, so I put it together...
Please separate patches.
> Also, Olivier from access once submitted a dev-down patch. As the patch
> has not been adopted I was wondering if something could be mde better or
> if it was just missed ?
I was actually sure that I didn't miss any patches, but that can
happens. Simply re-send it.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Frederic,
> I've been looking at pan profile and saw some mandatory fields in the
> sdp records were missing.
> The problem is that these fields are user dependent. How to set them?
>
> Security Description, NetAccessType and MaxNetAccessRate.
>
> There are several issues to the problem :
> - patching pand is easy but some more options are needed to customize
> fields (unless good defaults exists)
we need good default values and some extra parameters to change them. I
am all for this way.
> - using 'sdptool add' then 'sdptool set attr' is a bit unreadable
> - patching sdptool with more arguments?
No. These sdptool commands are only for debugging purpose.
> - using the dbus xml api still requires to patch pand or sdptool.
Won't really help. It only moves the problem to another tool.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> I noticed in 3.9 the service API start/stop relies on the hcid to exec
> application that provides the service. For external services, the start/stop
> functionality is essentially gone.
>
> This makes it hard to support such daemons as pand, dund, or anything that
> takes command line options, etc. It also makes it difficult to support inetd
> style daemons which handle multiple services at once (this is a fairly
> typical use-case in the embedded world)
>
> Would it be useful to have such use-cases available? For instance, KDE has
> its own inetd style framework for services. So if starting/stopping service
> behavior is not uniform, it might lead to fragmentation.
the ServiceAgent abstraction that I came up with was flexible, but it
ended up to be a little bit too complex. It also had the problem that we
couldn't have service information unless the daemon was running. So the
approach was to re-work this while keeping org.bluez.Service mostly
unchanged. So org.bluez.Service is meant for the UI to show information
about the current installed/running services. It only focus is the UI
and it should not be used by the services itself.
The starting and stopping of services is actually done by executing the
service binary or killing it. This is a more Unix like approach and it
keeps the service a lot more simpler since you don't have to worry about
additional callbacks. So in general you only start a service once and
then it will be running forever. The starting normally happens if the
autostart parameter is set to true or if ActivateService() is called by
a client application. The additional Start() and Stop() methods from the
org.bluez.Service interface are only for the UI and in general not
needed at all. It has been designed this way to give hcid full control
on what is currently running on the system and have a generic way of
providing this information.
For debugging purpose we added the external service definition. Mainly
we did this so we can easily run services through gdb or valgrind. It
might also useful for other cases, but this was not the main intention.
And in case of external services the start/stop functionality doesn't
work and this is done on purpose.
When migrating all the daemons to services, the command line parameters
have to be removed. Initially we had command line parameters in the
service description file, but in the end we removed them along with the
path name of the binary. Keep in mind that these are no longer daemons,
they are services. All command line options these services might have a
purely for debugging purpose. So for all other options they have to be
read from a configuration file or even better made accessible via D-Bus.
For embedded use cases, I think the current approach gives you all
freedom you need. Services can be started automatically or on-demand
when they are needed. You can also start them manually or even make them
external and take full control of them by yourself. With the separation
of service registration and SDP records, you can even have a service
that has no strings attached with hcid.
In the long term even the Unix socket used by sdpd will be removed since
the SDP server can now made part of hcid and SDP record registration is
possible over D-Bus. This will remove another daemon and another IPC
mechanism.
The inetd style approach makes only sense for RFCOMM based services. And
actually only for Serial Port Profile based services. For stuff like
Headset Profile or File Transfer we wanna have highly integrated general
services that provide a nice D-Bus API. So for the Serial Port Profile
the current plan is to create a serial service that provides this kind
of functionality, but then is fully controlled via D-Bus.
> Another point I'd like to bring up is the setting of encryption /
> authentication options. This seems like it should be part of the service
> framework API instead of being a command line option to each individual
> daemon.
The thing that has been left as experimental in the last release is the
authorization framework. This actually highly depends on the service
framework and so we had to stabilize that one first. The advantage of
having all servers (also externals) registered via hcid, we can have a
unique authorization callback and an AuthorizationAgent in userspace for
the UI. Both doesn't have to know any details about the service itself
and thus we can make this fully generic.
For the encryption and authentication, we might better rely on the
socket options and extend them. The kernel knows best in most cases how
to handle this within the protocol integration. I am also not willing to
commit to any API regarding this until the Bluetooth 2.1 specification
and Simple Pairing has been finally released.
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
I noticed in 3.9 the service API start/stop relies on the hcid to exec
application that provides the service. For external services, the start/stop
functionality is essentially gone.
This makes it hard to support such daemons as pand, dund, or anything that
takes command line options, etc. It also makes it difficult to support inetd
style daemons which handle multiple services at once (this is a fairly
typical use-case in the embedded world)
Would it be useful to have such use-cases available? For instance, KDE has
its own inetd style framework for services. So if starting/stopping service
behavior is not uniform, it might lead to fragmentation.
Another point I'd like to bring up is the setting of encryption /
authentication options. This seems like it should be part of the service
framework API instead of being a command line option to each individual
daemon.
What are your thoughts?
-Denis
-------------------------------------------------------------------------
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-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel