pan profile sdp record

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

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

Hi Denis,

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.

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

Hi Frederic,

we need good default values and some extra parameters to change them. I am all for this way.

No. These sdptool commands are only for debugging purpose.

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

Marcel,

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.

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

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

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.

Please separate patches.

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

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,

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

Marcel,

Here is new patch proposal.

Frédéric

? 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
@@ -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;
 	}
 

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

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