Make bluetoothd start w/o SDP Server

Hi all,

i was worrying about the missing cmdline option of bluetoothd which would allow the new daemon to start without its internal sdp server. Such an option was available for the old hcid.

So i created a patch for me to fix this in bluez-4.51 source, which works fine here but might not be the best implementation. Now I would like to know if anyone is interested in this patch at all and might want to make it a bit more professional :-)

Or is there already another way to suppress the internal sdp server starting, so the changes are not needed anymore????

Thanks for responses in advance !

Best regards
Susanne

Why would you want to do that?

Hi,

just for testing purposes. I have an own little sdp server written in perl and want this running instead of the one implemented in bluez. This was possible with older bluez versions when bluetoothd was named hcid. There was such a cmdline option.

I just would like to have an equivalent for this. Is that a problem?

Best regards
Susanne

Hi all,

I would like to explain in more detail why I use this option to start bluetoothd without its own SDP-Server.

The goal is to test the SDP implementation of bluetooth-capable Daimler headunits. For this i need my own SDP-Server implementation running, cause this SDP Server answers with predefined and invalid SDP Responses to special Requests from headunit.

The scenario is as follows:
1. Restart bluetoothd without its SDP Server and start my own SDP Server.
2. Wait for SDP Request of headunit to be able to inject the invalid SDP Response.
3. Restart bluetoothd with its own SDP Server and wait for headunit to connect successfully to our handsfree profile.

We need to perfom these kind of tests for robustness. This already worked fine with the old versions of bluez running hcid instead of bluetoothd. But with my patch I am able to run it again.

For my opinion this is not a use case for Daimler only, but for all producers of Bluetooth-devices ( mobile phones etc. ) which need to handle SDP Requests correctly and want to use Linux and bluez for testing purposes. For me this is the best and easiest way for testing Bluetooth-stuff like SDP implementation.

Below I provide the patch I am using. I would be happy if you (maybe modify and ) add it, so i don't need to fix the bluez-source each time a new release is available. But its up to you. :)

p.s.: As discussed with my project leader, Marcel Holtmann has been in the Daimler lab in Sindelfingen already. I think he has a good idea of what we are doing here. ( Just for the case my explanation of why i appreciate such a fix was bad :))

Just let me know what decision you made.
Thanks a lot in any case.
_______________________________

diff -r -u bluez-4.51/debian/changelog bluez-4.51_patched/debian/changelog

+0100
@@ -1,3 +1,11 @@
+bluez (4.51-0ubuntu2-1) karmic; urgency=low
+
+ * patch orig source with 4.51.diff.gz provided by ubuntu
+ * patch bluetoothd so we are able to start without sdp server +
+ -- Susanne Goldammer <[email protected]> Tue, 10 Nov 2009 10:00:24 +0200
+
+
bluez (4.51-0ubuntu2) karmic; urgency=low

* debian/patches/01_lower_sink_ranking.patch:
Nur in bluez-4.51/scripts: bluetooth.rules.

diff -r -u bluez-4.51/src/main.c bluez-4.51_patched/src/main.c
@@ -292,6 +292,8 @@
 static gboolean option_detach = TRUE;
 static gboolean option_debug = FALSE;
 static gboolean option_udev = FALSE;
+static gboolean option_runsdp = TRUE;
+
 
 static guint last_adapter_timeout = 0;
 

@@ -331,6 +333,9 @@
                 "Enable debug information output" },
     { "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
                 "Run from udev mode of operation" },
+        { "nosdp", 'S', G_OPTION_FLAG_REVERSE,
+                        G_OPTION_ARG_NONE, &option_runsdp,
+                        "Don't run SDP service (debuggin option)" },
     { NULL },
 };
 

@@ -416,7 +421,14 @@
         }
     }
 
-    start_sdp_server(mtu, main_opts.deviceid, SDP_SERVER_COMPAT);
+        if (option_runsdp != 0) {
+               start_sdp_server(mtu, main_opts.deviceid,

SDP_SERVER_COMPAT);
+ }
+ else {

+               /* see scp-server.c: start_sdp_server() -> init_server() */
+               register_public_browse_group();
+               register_server_service();

+ }

/* Loading plugins has to be done after D-Bus has been setup since
* the plugins might wanna expose some paths on the bus. However the
@@ -445,7 +457,13 @@

     plugin_cleanup();

- stop_sdp_server();
+ if (option_runsdp != 0) {
+ stop_sdp_server();
+ }
+ else {
+ /* see scp-server.c: stop_sdp_server() */
+ sdp_svcdb_reset();
+ }

     agent_exit();

Nur in bluez-4.51/tools: lexer.c.
Nur in bluez-4.51/tools: parser.c.
Nur in bluez-4.51/tools: parser.h.

I guess that a "Daimler headunit" is something to do with the Daimler car, is that some kind of builtin radio with integrated handsfree capability?

I would be interested to find out why you need to use proprietary SDP requests? They would only be accessible from a proprietary device and as there are no vendor-specific PDU IDs defined in the SDP specification there is a chance of conflict with future extensions. (I admit its unlikely, but the ID is only 8-bit).

The Bluetooth specifications allow numerous ways to provide proprietary services, and IMO the proper way to advertise such is to create your own UUID describing the service class, your own UUID describing the protocol (if any), search for that in the standard way and connect to the service in the same way as you would any other. The attribute values are defined by the service class so you can provide as much information as you want in this way, no secret handshakes required at all.

regards,
iain

(please note, I don't even run BlueZ/Linux and thus can't object to this specific implementation in any meaningful way. I'm just interested :)

Hi Iain,

thanks for you reply!

I think you missunderstood a bit.

First, yes it is a handsfree kit.

But: We don't want to provide our own proprietary SDP Stuff. This makes no sense cause we want to be compatible to other BT-devices supporting interesting BT-profiles like HFP etc. And also I was talking about the SDP-Server side means i want to sent responses.

What we want to do is robustness testing, means our test SDP Server listens for a SDP request (which can come from headunit but also from any other sdp capable mobile phone or whatsoever to request the services provided by the communication partner). We have some predefined correct answers for some of the SDP requests, but before sending the one fitting for the received request we fuzz the answer, means we make it invalid regarding length etc. pp.

Then we send this answer to the bt device under test and look if it becomes instable cause e.g. of missing checks in SDP implementation.

There are thousands of tools like scapy doing such things for tcp/ip stack. We are doing similar tests for Bluetooth communication ( L2CAP, Obex and finally SDP, too). Here a correct and primarily robust implementation needs to be ensured through testing. The best way to do so is to confront the DuT with such invalid packets.

I hope this help to understand a bit better.

Hi Susanne,

Thanks for the explanation, now I understand the purpose of the patch (debug option for regression tests) and, given that it is pretty low overhead, I think it is a good Idea.

I'm commenting on the patch inline.

scp-server.c?

I don't know the internals, so maybe explaining shortly why this is needed even when no SDP service was running is a good idea (but maybe this is elaborated in great detail in sdpd-server.c comments already, then the comment above may be fine.

Have fun :-)

seife

Stefan Seyfried

"You sure you software suspend guys haven't been hanging out with the
 IDE maintainers?"                                     -- Rob Landley

Hi seife ;)

thanks a lot for your comments. I will change and provide the patch for 4.57 without the debian extensions, soon.

FYI: I made the patch with 4.51 cause i had errors with bluetooth usb devices which where no longer initialized correctly when plugged in. This happened after upgrading to ubuntu karmic and bluez 4.57.

With bluez 4.51 everything works fine.

Hi Susanne,

I guess that Marcel actually prefers patches against latest git if possible, even though not much has changed since 4.57 _yet_ (and not in the area you are touching).

That would warrant a bug report, separate from this issue ;)

Have fun,

seife

Stefan Seyfried

"Any ideas, John?"
"Well, surrounding them's out."

Hi all,

as discussed with seife :) here is a new patch made with bluez-4.57, without debian extensions and no curly braces due to the mentioned coding style.
I added it as attachment cause my mail program seems to change the tabs. Let me know if it is still damaged. In my vi everything is ok with the tabs.

Here my short xplanation:
With the patch i wanted to change as few code as possible. So i replaced the start_sdp_server() with the code executed before the l2cap socket is created and server starts listening ( see init_server() in sdpd-server.c). The same idea when stopping: Just omit the code responsible for the socket creation and release.

Of course I am not sure if this is the best way cause i am not aware of the thoughts, decisions and discussions which made the code becoming what it is today. So i would really appreciate any explanation of why someone would do it in another way.

Please let me know if it gets integrated into further bluez releases or if any additional information is needed.

Thanks...

diff -r -u bluez-4.57/src/main.c bluez-4.57_no_sdp_option/src/main.c
@@ -296,6 +296,8 @@
 static gboolean option_detach = TRUE;
 static gboolean option_debug = FALSE;
 static gboolean option_udev = FALSE;
+static gboolean option_runsdp = TRUE;
+
 
 static guint last_adapter_timeout = 0;
 

@@ -335,6 +337,9 @@
 				"Enable debug information output" },
 	{ "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
 				"Run from udev mode of operation" },
+	{ "nosdp", 'S', G_OPTION_FLAG_REVERSE,
+				G_OPTION_ARG_NONE, &option_runsdp,
+				"Don't run SDP service (debuggin option)" },
 	{ NULL },
 };
 

@@ -429,7 +434,13 @@
 		}
 	}
 
-	start_sdp_server(mtu, main_opts.deviceid, SDP_SERVER_COMPAT);
+	if (option_runsdp == TRUE)
+		start_sdp_server(mtu, main_opts.deviceid, SDP_SERVER_COMPAT);
+	else {
+		/* see sdpd-server.c: start_sdp_server() -> init_server() */
+		register_public_browse_group();
+		register_server_service();
+	}
 
 	/* Loading plugins has to be done after D-Bus has been setup since
 	 * the plugins might wanna expose some paths on the bus. However the

@@ -458,7 +469,11 @@
 
 	plugin_cleanup();
 
-	stop_sdp_server();
+	if (option_runsdp == TRUE) 
+		stop_sdp_server();
+	else
+		/* see sdpd-server.c: stop_sdp_server() */
+		sdp_svcdb_reset();
 
 	agent_exit();
 

Typo there: s/debuggin/debugging/

Fixed. New patch attached.

diff -r -u bluez-4.57/src/main.c bluez-4.57_no_sdp_option/src/main.c
@@ -296,6 +296,8 @@
 static gboolean option_detach = TRUE;
 static gboolean option_debug = FALSE;
 static gboolean option_udev = FALSE;
+static gboolean option_runsdp = TRUE;
+
 
 static guint last_adapter_timeout = 0;
 

@@ -335,6 +337,9 @@
 				"Enable debug information output" },
 	{ "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
 				"Run from udev mode of operation" },
+	{ "nosdp", 'S', G_OPTION_FLAG_REVERSE,
+				G_OPTION_ARG_NONE, &option_runsdp,
+				"Don't run SDP service (debugging option)" },
 	{ NULL },
 };
 

@@ -429,7 +434,13 @@
 		}
 	}
 
-	start_sdp_server(mtu, main_opts.deviceid, SDP_SERVER_COMPAT);
+	if (option_runsdp == TRUE)
+		start_sdp_server(mtu, main_opts.deviceid, SDP_SERVER_COMPAT);
+	else {
+		/* see sdpd-server.c: start_sdp_server() -> init_server() */
+		register_public_browse_group();
+		register_server_service();
+	}
 
 	/* Loading plugins has to be done after D-Bus has been setup since
 	 * the plugins might wanna expose some paths on the bus. However the

@@ -458,7 +469,11 @@
 
 	plugin_cleanup();
 
-	stop_sdp_server();
+	if (option_runsdp == TRUE) 
+		stop_sdp_server();
+	else
+		/* see sdpd-server.c: stop_sdp_server() */
+		sdp_svcdb_reset();
 
 	agent_exit();
 

Hi Susanne,

The patch looks good except for two more white-space issues:

No need to add another extra line here (in general there shouldn't be a need to have two consequtive empty lines almost anywhere in the source).

Hi Johan,

hold your horses.

Don't we create the SDP server with BDADDR_ANY. So if you wanna start your own one on top of it, you just can bind() it to the local adapter address and the kernel will use that one for that interface.

Regards

Marcel

Hi Marcel,

I just checked src/sdpd-server.c and you're right. So if it can indeed be overriden like that it would certainly be a simpler solution.

Btw, what about making the SDP server a bluetoothd plugin in the future so it could also be replaced by simply having a different plugin loaded instead?

Johan

Hi Marcel,

i tried it and it works fine. Cool. :) That behaviour was new to me. So that's the solution i guess. No further patches needed.

I hope that this behaviour is not changed in the future.
As i know this behaviour is not the same for tcp/ip sockets, right? Or is that a new and common kernel feature since 2.6.xxx ?

Thanks to all .....