Make bluetoothd start w/o SDP Server

Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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

Re: Make bluetoothd start w/o SDP Server

[Bastien Nocera]

On Tue, 2009-11-10 at 15:00 +0100, Susanne Goldammer wrote:
> 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 !

Why would you want to do that?

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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
--- bluez-4.51/debian/changelog    2009-11-10 09:57:06.000000000 +0100
+++ bluez-4.51_patched/debian/changelog    2009-11-10 09:55:43.000000000
+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 <susanne.goldammer@gmx.de>  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
--- bluez-4.51/src/main.c    2009-08-01 21:47:07.000000000 +0200
+++ bluez-4.51_patched/src/main.c    2009-11-10 09:47:29.000000000 +0100
@@ -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.

Re: Make bluetoothd start w/o SDP Server

[Iain Hibbert]

On Thu, 12 Nov 2009, Susanne Goldammer wrote:

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

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

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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.

Re: Make bluetoothd start w/o SDP Server

[Stefan Seyfried]

Hi Susanne,

On Thu, 12 Nov 2009 10:21:58 +0100
Susanne Goldammer <susanne.goldammer@gmx.de> wrote:

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

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.

> diff -r -u bluez-4.51/debian/changelog
> bluez-4.51_patched/debian/changelog 
> --- bluez-4.51/debian/changelog    2009-11-10 09:57:06.000000000 +0100
> +++ bluez-4.51_patched/debian/changelog    2009-11-10 09:55:43.000000000 +0100

a) The bluez source does not contain a debian directory and thus no
debian/changelog file.

b) bluez is now at version 4.57. Please provide a patch againt current
git.

> @@ -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 <susanne.goldammer@gmx.de>  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
> --- bluez-4.51/src/main.c    2009-08-01 21:47:07.000000000 +0200
> +++ bluez-4.51_patched/src/main.c    2009-11-10 09:47:29.000000000
> +0100 @@ -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)" },

Your patch is whitespace-damaged (bluez source uses tabs for
indentation, not spaces) and thus does not apply at all.
In case your mailer mangles the patch and everything else fails, then
send it as an attachment (plain text, still).

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

Coding style: no curly braces around single line conditionals.

> +        stop_sdp_server();
> +    }
> +    else {

again, no curly braces

> +        /* see scp-server.c: stop_sdp_server() */

scp-server.c?

> +        sdp_svcdb_reset();

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

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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.

Re: Make bluetoothd start w/o SDP Server

[Stefan Seyfried]

Hi Susanne,

On Thu, 12 Nov 2009 13:55:25 +0100
Susanne Goldammer <susanne.goldammer@gmx.de> wrote:

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

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

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

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

Have fun,

	seife
-- 
Stefan Seyfried

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

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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

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


[-- Attachment #2: no_sdp_server_option.patch --]
[-- Type: text/plain, Size: 1421 bytes --]

diff -r -u bluez-4.57/src/main.c bluez-4.57_no_sdp_option/src/main.c
--- bluez-4.57/src/main.c	2009-10-04 05:56:37.000000000 +0200
+++ bluez-4.57_no_sdp_option/src/main.c	2009-11-12 14:38:16.000000000 +0100
@@ -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();
 

Re: Make bluetoothd start w/o SDP Server

[Bastien Nocera]

On Thu, 2009-11-12 at 15:13 +0100, Susanne Goldammer wrote:
> +                               "Don't run SDP service (debuggin
> option)" },

Typo there: s/debuggin/debugging/

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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

Bastien Nocera schrieb:
> On Thu, 2009-11-12 at 15:13 +0100, Susanne Goldammer wrote:
>   
>> +                               "Don't run SDP service (debuggin
>> option)" },
>>     
>
> Typo there: s/debuggin/debugging/
>
>   
Fixed. New patch attached.

[-- Attachment #2: no_sdp_server_option.patch --]
[-- Type: text/plain, Size: 1422 bytes --]

diff -r -u bluez-4.57/src/main.c bluez-4.57_no_sdp_option/src/main.c
--- bluez-4.57/src/main.c	2009-10-04 05:56:37.000000000 +0200
+++ bluez-4.57_no_sdp_option/src/main.c	2009-11-12 16:09:32.000000000 +0100
@@ -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();
 

Re: Make bluetoothd start w/o SDP Server

[Johan Hedberg]

Hi Susanne,

On Thu, Nov 12, 2009, Susanne Goldammer wrote:
> Fixed. New patch attached.

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

> +static gboolean option_runsdp = TRUE;
> +
>  
> static guint last_adapter_timeout = 0;

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

> +	if (option_runsdp == TRUE) 

It looks like this has an extra space at the end before the newline
character.

Additionally, could you please create a patch using git format-patch so
that it can be applied using git am and you get proper credit for it
(through the author field). Thanks.

Johan

Re: Make bluetoothd start w/o SDP Server

[Marcel Holtmann]

Hi Johan,

> > Fixed. New patch attached.
> 
> The patch looks good except for two more white-space issues:

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

Re: Make bluetoothd start w/o SDP Server

[Johan Hedberg]

Hi Marcel,

On Fri, Nov 13, 2009, Marcel Holtmann wrote:
> > > Fixed. New patch attached.
> > 
> > The patch looks good except for two more white-space issues:
> 
> 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.

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

Re: Make bluetoothd start w/o SDP Server

[Susanne Goldammer]

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