[Bluez-devel] pan profile sdp record

[Bluez-devel] pan profile sdp record

[Frédéric DALLEAU]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] Service API

[Denis KENZIOR]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Service API

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Frédéric DALLEAU]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

Marcel,

>> 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?
I still have a modified rfcomm man page, so I put it together...

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 ?

Frédéric.


[-- Attachment #2: pand-rfcomm.patch --]
[-- Type: text/x-patch, Size: 9083 bytes --]

? Doxyfile
? Makefile
? Makefile.in
? aclocal.m4
? autom4te.cache
? bluezutils.kdevelop
? bluezutils.kdevelop.pcs
? bluezutils.kdevses
? config.guess
? config.h
? config.h.in
? config.log
? config.status
? config.sub
? configure
? debug
? depcomp
? install-sh
? libtool
? ltmain.sh
? missing
? stamp-h.in
? stamp-h1
? alsa/Makefile.in
? audio/.deps
? audio/.libs
? audio/Makefile
? audio/Makefile.in
? audio/bluetoothd-service-audio
? audio/bluetoothd-service-headset
? common/.deps
? common/.libs
? common/Makefile
? common/Makefile.in
? common/test_textfile
? cups/.deps
? cups/.libs
? cups/Makefile
? cups/Makefile.in
? cups/bluetooth
? daemon/.deps
? daemon/.libs
? daemon/Makefile
? daemon/Makefile.in
? daemon/auth-agent
? daemon/bluetoothd
? daemon/bt.echod
? daemon/passkey-agent
? daemon/service-agent-glue.h
? dund/.deps
? dund/.libs
? dund/Makefile
? dund/Makefile.in
? dund/dund
? eglib/.deps
? eglib/.libs
? eglib/Makefile
? eglib/Makefile.in
? eglib/gmain.lo
? eglib/libeglib.la
? fuse/Makefile.in
? hcid/.deps
? hcid/.libs
? hcid/Makefile
? hcid/Makefile.in
? hcid/hcid
? hcid/lexer.c
? hcid/parser.c
? hcid/parser.h
? hidd/.deps
? hidd/.libs
? hidd/Makefile
? hidd/Makefile.in
? hidd/hidd
? input/.deps
? input/Makefile
? input/Makefile.in
? network/.deps
? network/.libs
? network/Makefile
? network/Makefile.in
? network/bluetoothd-service-network
? pand/.deps
? pand/.libs
? pand/Makefile
? pand/Makefile.in
? pand/pand
? print/Makefile
? print/Makefile.in
? rfcomm/.deps
? rfcomm/.libs
? rfcomm/Makefile
? rfcomm/Makefile.in
? rfcomm/cvs
? rfcomm/lexer.c
? rfcomm/main.c.modified
? rfcomm/main.patch
? rfcomm/parser.c
? rfcomm/parser.h
? rfcomm/rfcomm
? sbc/.deps
? sbc/.libs
? sbc/Makefile
? sbc/Makefile.in
? sbc/libsbc.la
? sbc/sbc.lo
? scripts/Makefile
? scripts/Makefile.in
? sdpd/.deps
? sdpd/.libs
? sdpd/Makefile
? sdpd/Makefile.in
? sdpd/sdpd
? serial/Makefile
? serial/Makefile.in
? sync/.deps
? sync/Makefile
? sync/Makefile.in
? test/.deps
? test/Makefile
? test/Makefile.in
? tools/.deps
? tools/.libs
? tools/Makefile
? tools/Makefile.in
? tools/ciptool
? tools/hciattach
? tools/hciconfig
? tools/hcisecfilter
? tools/hcitool
? tools/l2ping
? tools/ppporc
? tools/sdptool
? transfer/.deps
? transfer/Makefile
? transfer/Makefile.in
Index: pand/main.c
===================================================================
RCS file: /cvsroot/bluez/utils/pand/main.c,v
retrieving revision 1.27
diff -u -r1.27 main.c
--- pand/main.c	13 Jan 2007 17:48:25 -0000	1.27
+++ pand/main.c	21 Feb 2007 15:25:07 -0000
@@ -56,6 +56,14 @@
 static uint16_t role    = BNEP_SVC_PANU;	/* Local role (ie service) */
 static uint16_t service = BNEP_SVC_NAP;		/* Remote service */
 
+static	struct bnep_sdp_infos infos = {
+	.security_desc = 0,
+	.net_access_type = 0xFFFE,
+	.max_net_access_rate = 0,
+	.name = "Bluez PAN",
+	.desc = "Bluez PAN Network Service"
+};
+
 static int detach = 1;
 static int persist;
 static int use_sdp = 1;
@@ -132,7 +140,7 @@
 	int sk, lm;
 
 	if (use_sdp)
-		bnep_sdp_register(&src_addr, role);
+		bnep_sdp_register(&src_addr, role, &infos);
 
 	/* Create L2CAP socket and bind it to PSM BNEP */
 	sk = socket(AF_BLUETOOTH, SOCK_SEQPACKET, BTPROTO_L2CAP);
@@ -514,6 +522,9 @@
 	{ "ethernet", 1, 0, 'e' },
 	{ "device",   1, 0, 'i' },
 	{ "nosdp",    0, 0, 'D' },
+	{ "security", 0, 0, 'y' },
+	{ "access",   0, 0, 'a' },
+	{ "maxrate",  0, 0, 'm' },
 	{ "list",     0, 0, 'l' },
 	{ "show",     0, 0, 'l' },
 	{ "nodetach", 0, 0, 'n' },
@@ -529,7 +540,7 @@
 	{ 0, 0, 0, 0 }
 };
 
-static char main_sopts[] = "hsc:k:Kr:d:e:i:lnp::DQ::AESMC::P:u:z";
+static char main_sopts[] = "hsc:k:Kr:d:e:i:lnp::Dy:a:m:Q::AESMC::P:u:z";
 
 static char main_help[] = 
 	"Bluetooth PAN daemon version " VERSION " \n"
@@ -548,6 +559,9 @@
 	"\t--ethernet -e <name>      Network interface name\n"
 	"\t--device -i <bdaddr>      Source bdaddr\n"
 	"\t--nosdp -D                Disable SDP\n"
+	"\t--security -y             SDP Security Description attribute\n"
+	"\t--access -a               SDP Net Access Type attribute\n"
+	"\t--maxrate -m              SDP Max Access Rate attribute\n"
 	"\t--auth -A                 Enable authentication\n"
 	"\t--encrypt -E              Enable encryption\n"
 	"\t--secure -S               Secure connection\n"
@@ -614,6 +628,18 @@
 			use_sdp = 0;
 			break;
 
+		case 'y':
+			infos.security_desc = atoi(optarg);
+			break;
+
+		case 'a':
+			infos.net_access_type = atoi(optarg);
+			break;
+
+		case 'm':
+			infos.max_net_access_rate = atoi(optarg);
+			break;
+
 		case 'A':
 			link_mode |= L2CAP_LM_AUTH;
 			break;
Index: pand/pand.1
===================================================================
RCS file: /cvsroot/bluez/utils/pand/pand.1,v
retrieving revision 1.6
diff -u -r1.6 pand.1
--- pand/pand.1	4 Jun 2006 13:05:36 -0000	1.6
+++ pand/pand.1	21 Feb 2007 15:25:07 -0000
@@ -42,6 +42,15 @@
 \fB\-\-nosdp\fR \fB\-D\fR
 Disable SDP
 .TP
+\fB\-\-security\fR \fB\-y\fR
+SDP Security Description attribute
+.TP
+\fB\-\-access\fR \fB\-a\fR
+SDP Net Access Type attribute
+.TP
+\fB\-\-maxrate\fR \fB\-m\fR
+SDP Max Access Rate attribute
+.TP
 \fB\-\-encrypt\fR \fB\-E\fR
 Enable encryption
 .TP
Index: pand/pand.h
===================================================================
RCS file: /cvsroot/bluez/utils/pand/pand.h,v
retrieving revision 1.7
diff -u -r1.7 pand.h
--- pand/pand.h	13 Jan 2007 17:48:25 -0000	1.7
+++ pand/pand.h	21 Feb 2007 15:25:07 -0000
@@ -36,7 +36,16 @@
 int bnep_accept_connection(int sk, uint16_t role, char *dev);
 int bnep_create_connection(int sk, uint16_t role, uint16_t svc, char *dev);
 
+/* SDP structs */
+struct bnep_sdp_infos {
+	uint16_t security_desc;
+	uint16_t net_access_type;
+	uint32_t max_net_access_rate;
+	char *name;
+	char *desc;
+};
+
 /* SDP functions */
-int  bnep_sdp_register(bdaddr_t *device, uint16_t role);
+int  bnep_sdp_register(bdaddr_t *device, uint16_t role, struct bnep_sdp_infos *infos);
 void bnep_sdp_unregister(void);
 int  bnep_sdp_search(bdaddr_t *src, bdaddr_t *dst, uint16_t service);
Index: pand/sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/pand/sdp.c,v
retrieving revision 1.8
diff -u -r1.8 sdp.c
--- pand/sdp.c	13 Jan 2007 17:48:25 -0000	1.8
+++ pand/sdp.c	21 Feb 2007 15:25:07 -0000
@@ -53,7 +53,21 @@
 	sdp_close(session);
 }
 
-int bnep_sdp_register(bdaddr_t *device, uint16_t role)
+static void add_lang_attr(sdp_record_t *r)
+{
+	sdp_lang_attr_t base_lang;
+	sdp_list_t *langs = 0;
+
+	/* UTF-8 MIBenum (http://www.iana.org/assignments/character-sets) */
+	base_lang.code_ISO639 = (0x65 << 8) | 0x6e;
+	base_lang.encoding = 106;
+	base_lang.base_offset = SDP_PRIMARY_LANG_BASE;
+	langs = sdp_list_append(0, &base_lang);
+	sdp_set_lang_attr(r, langs);
+	sdp_list_free(langs, 0);
+}
+
+int bnep_sdp_register(bdaddr_t *device, uint16_t role, struct bnep_sdp_infos *infos)
 {
 	sdp_list_t *svclass, *pfseq, *apseq, *root, *aproto;
 	uuid_t root_uuid, pan, l2cap, bnep;
@@ -118,12 +132,16 @@
 	
 	aproto   = sdp_list_append(NULL, apseq);
 	sdp_set_access_protos(record, aproto);
+
+	add_lang_attr(record);
+
 	sdp_list_free(proto[0], NULL);
 	sdp_list_free(proto[1], NULL);
 	sdp_list_free(apseq, NULL);
 	sdp_list_free(aproto, NULL);
 	sdp_data_free(p);
 	sdp_data_free(v);
+	sdp_attr_add_new(record, SDP_ATTR_SECURITY_DESC, SDP_UINT16, &infos->security_desc);
 
 	switch (role) {
 	case BNEP_SVC_NAP:
@@ -136,7 +154,10 @@
 		pfseq = sdp_list_append(NULL, &profile[0]);
 		sdp_set_profile_descs(record, pfseq);
 
-		sdp_set_info_attr(record, "Network Access Point", NULL, NULL);
+		sdp_set_info_attr(record, "Network Access Point", infos->name, infos->desc);
+
+		sdp_attr_add_new(record, SDP_ATTR_NET_ACCESS_TYPE, SDP_UINT16, &infos->net_access_type);
+		sdp_attr_add_new(record, SDP_ATTR_MAX_NET_ACCESSRATE, SDP_UINT32, &infos->max_net_access_rate);
 		break;
 
 	case BNEP_SVC_GN:
@@ -149,9 +170,10 @@
 		pfseq = sdp_list_append(NULL, &profile[0]);
 		sdp_set_profile_descs(record, pfseq);
 		
-		sdp_set_info_attr(record, "Group Network Service", NULL, NULL);
+		sdp_set_info_attr(record, "Group Network Service", infos->name, infos->desc);
 		break;
 
+
 	case BNEP_SVC_PANU:
 		sdp_uuid16_create(&pan, PANU_SVCLASS_ID);
 		svclass = sdp_list_append(NULL, &pan);
@@ -164,7 +186,7 @@
 		sdp_set_profile_descs(record, pfseq);
 		sdp_list_free(pfseq, 0);
 
-		sdp_set_info_attr(record, "PAN User", NULL, NULL);
+		sdp_set_info_attr(record, "PAN User", infos->name, infos->desc);
 		break;
 	}
 
Index: rfcomm/rfcomm.1
===================================================================
RCS file: /cvsroot/bluez/utils/rfcomm/rfcomm.1,v
retrieving revision 1.6
diff -u -r1.6 rfcomm.1
--- rfcomm/rfcomm.1	24 Dec 2006 13:49:04 -0000	1.6
+++ rfcomm/rfcomm.1	21 Feb 2007 15:25:07 -0000
@@ -53,6 +53,14 @@
 .TP
 .BI -i " <hciX> | <bdaddr>"
 The command is applied to device
+.BI -A
+Enable authentification
+.BI -E
+Enable encryption
+.BI -S
+Secure connection
+.BI -M
+Become the master of a piconet
 .I
 hciX
 , which must be the name or the address of an installed Bluetooth

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Frédéric DALLEAU]

>>>> 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Frédéric DALLEAU]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

Marcel,
> 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.

Frédéric

[-- Attachment #2: pand-sdp.patch --]
[-- Type: text/x-patch, Size: 3303 bytes --]

? Doxyfile
? Makefile.in
? aclocal.m4
? autom4te.cache
? bluezutils.kdevelop
? bluezutils.kdevelop.pcs
? bluezutils.kdevses
? config.guess
? config.h.in
? config.sub
? configure
? debug
? depcomp
? install-sh
? ltmain.sh
? missing
? stamp-h.in
? alsa/Makefile.in
? audio/Makefile.in
? common/Makefile.in
? cups/Makefile.in
? daemon/Makefile.in
? daemon/bt.echod
? daemon/service-agent-glue.h
? dund/Makefile.in
? eglib/Makefile.in
? fuse/Makefile.in
? hcid/Makefile.in
? hidd/Makefile.in
? input/Makefile.in
? network/Makefile.in
? pand/Makefile.in
? print/Makefile.in
? rfcomm/Makefile.in
? rfcomm/cvs
? sbc/Makefile.in
? scripts/Makefile.in
? sdpd/Makefile.in
? serial/Makefile.in
? sync/Makefile.in
? test/Makefile.in
? tools/Makefile.in
? transfer/Makefile.in
Index: pand/sdp.c
===================================================================
RCS file: /cvsroot/bluez/utils/pand/sdp.c,v
retrieving revision 1.8
diff -u -r1.8 sdp.c
--- pand/sdp.c	13 Jan 2007 17:48:25 -0000	1.8
+++ pand/sdp.c	22 Feb 2007 09:39:44 -0000
@@ -53,6 +53,20 @@
 	sdp_close(session);
 }
 
+static void add_lang_attr(sdp_record_t *r)
+{
+	sdp_lang_attr_t base_lang;
+	sdp_list_t *langs = 0;
+
+	/* UTF-8 MIBenum (http://www.iana.org/assignments/character-sets) */
+	base_lang.code_ISO639 = (0x65 << 8) | 0x6e;
+	base_lang.encoding = 106;
+	base_lang.base_offset = SDP_PRIMARY_LANG_BASE;
+	langs = sdp_list_append(0, &base_lang);
+	sdp_set_lang_attr(r, langs);
+	sdp_list_free(langs, 0);
+}
+
 int bnep_sdp_register(bdaddr_t *device, uint16_t role)
 {
 	sdp_list_t *svclass, *pfseq, *apseq, *root, *aproto;
@@ -61,6 +75,11 @@
 	sdp_list_t *proto[2];
 	sdp_data_t *v, *p;
 	uint16_t psm = 15, version = 0x0100;
+	uint16_t security_desc = 0;
+	uint16_t net_access_type = 0xFFFE;
+	uint32_t max_net_access_rate = 0;
+	char *name = "BlueZ PAN";
+	char *desc = "BlueZ PAN Service";
 	int status;
 
 	session = sdp_connect(BDADDR_ANY, BDADDR_LOCAL, 0);
@@ -118,12 +137,16 @@
 	
 	aproto   = sdp_list_append(NULL, apseq);
 	sdp_set_access_protos(record, aproto);
+
+	add_lang_attr(record);
+
 	sdp_list_free(proto[0], NULL);
 	sdp_list_free(proto[1], NULL);
 	sdp_list_free(apseq, NULL);
 	sdp_list_free(aproto, NULL);
 	sdp_data_free(p);
 	sdp_data_free(v);
+	sdp_attr_add_new(record, SDP_ATTR_SECURITY_DESC, SDP_UINT16, &security_desc);
 
 	switch (role) {
 	case BNEP_SVC_NAP:
@@ -136,7 +159,10 @@
 		pfseq = sdp_list_append(NULL, &profile[0]);
 		sdp_set_profile_descs(record, pfseq);
 
-		sdp_set_info_attr(record, "Network Access Point", NULL, NULL);
+		sdp_set_info_attr(record, "Network Access Point", name, desc);
+
+		sdp_attr_add_new(record, SDP_ATTR_NET_ACCESS_TYPE, SDP_UINT16, &net_access_type);
+		sdp_attr_add_new(record, SDP_ATTR_MAX_NET_ACCESSRATE, SDP_UINT32, &max_net_access_rate);
 		break;
 
 	case BNEP_SVC_GN:
@@ -149,7 +175,7 @@
 		pfseq = sdp_list_append(NULL, &profile[0]);
 		sdp_set_profile_descs(record, pfseq);
 		
-		sdp_set_info_attr(record, "Group Network Service", NULL, NULL);
+		sdp_set_info_attr(record, "Group Network Service", name, desc);
 		break;
 
 	case BNEP_SVC_PANU:
@@ -164,7 +190,7 @@
 		sdp_set_profile_descs(record, pfseq);
 		sdp_list_free(pfseq, 0);
 
-		sdp_set_info_attr(record, "PAN User", NULL, NULL);
+		sdp_set_info_attr(record, "PAN User", name, desc);
 		break;
 	}
 

[-- Attachment #3: Type: text/plain, Size: 345 bytes --]

-------------------------------------------------------------------------
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

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] pan profile sdp record

[Marcel Holtmann]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel