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
> 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 .....
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
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
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
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();
On Thu, 2009-11-12 at 15:13 +0100, Susanne Goldammer wrote:
> + "Don't run SDP service (debuggin
> option)" },
Typo there: s/debuggin/debugging/
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();
Hi Susanne,
On Thu, 12 Nov 2009 13:55:25 +0100
Susanne Goldammer <[email protected]> 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."
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,
On Thu, 12 Nov 2009 10:21:58 +0100
Susanne Goldammer <[email protected]> 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 <[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
> --- 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
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.
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 :)
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 <[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
--- 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.
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
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?