* Re: HDP proposed api (ver 0.2)
From: José Antonio Santos Cadenas @ 2010-05-10 8:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Elvis Pfützenreuter, João Paulo Rechi Vita,
linux-bluetooth
In-Reply-To: <AANLkTimz7yYXB2gV0EyRROItnIP6hILvC8Tz4Hbd0iyx@mail.gmail.com>
Hi all,
El Sunday 09 May 2010 17:14:39 Luiz Augusto von Dentz escribió:
> Hi,
>
> On Sat, May 8, 2010 at 12:08 AM, Elvis Pfützenreuter <epx@signove.com>
wrote:
> >> Device objects exists for each paired device. If the pairing is
> >> removed the object is also removed and a new pairing is needed before
> >> connecting to it (as imposed by the whole bluetooth stack logic
> >> anyway).
> >
> > AFAIK the HDP source and sink must be paired before any session can be
> > established, so the relevant device objects will always be there, so the
> > path can be (re)used.
>
> Exactly, I tried to explain this before that device objects is a
> better way to expose any relevant API since that would be created
> anyway. It also has integration with the sdp record cache and are
> reloaded during the initialization and I hardly see us doing anything
> to revert this, since pretty much every plugin depend on this to work.
We agree that the best way to expose a remote device is using the path
already created by bluez. We are thinking, as Elvis suggested, in changing
some functions to that path for discovering remove services.
The main problem here is that sessions exist in HDP even if bluez is not
concerned about them. Imagine that we perform an implementation without
session management, this not implies that other implementations do the same so
a remote device could expose multiple HDP session (each one of them could
expose a SDP record). Now if you are not concern of the sessions and you try
to connect to a remote device that holds more than one session, you can't
decide which one of that sessions connect. A simple example of this situation
is described in the HDP implementation whitepaper (page 18, figure 2.4).
>
> So, with this in mind, IMHO, the whole concept of exposure the
> sessions won't fit nicely in BlueZ API, first because it uses the
> adapter path to create session passing a device path, which btw
> already is associated with adapter anyway,
We think that the main problem here is that we don't choose a good path name.
But we are open to suggestion for a better one.
> second because any client
> seems to be able to create those sessions even if they are unable to
> control them because they don't hold an agent,
We think that this is not a good reason, the same could happend with other
profiles. Any client could connect to an Audio or Serial device even if they
are unable to use them or the don't know how to do it.
> and third I don't think
> we should be exposing protocol internals in a D-Bus API,
We don't understand this. What do you mean with protocol internal? Nothing
exposed in D-Bus in internal we just propose to concert the client about the
remote session (remote hdp instance) because it need to decide with one to
connect, as it decides the device that it will connect with a Serial
connection. Probably we need a better name than "session id".
> this id's
> make as much sense as the bdaddr in the ui (read _none_), it is as
> usable as we starting exposing local and remote seid (Stream Endpoint
> id, surprisingly similar to endpoint here) to pulseaudio to carry on
> with all avdtp protocol details, this will only fragment the logic
> around those bits and certainly won't make it work better.
Ok, we shouldn't expose mdepid. But we still need to expose the remote hdp
session or instances. Note that in Audio profile the psm is fixed, so there is
just one listening on each device, but HDP is different because the psm are not
fixed and multiple instances can exist in the same device.
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: José Antonio Santos Cadenas @ 2010-05-10 7:53 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: João Paulo Rechi Vita, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org
In-Reply-To: <536E0C33-0FB5-4A71-AE8A-5C96F2ABEA0F@signove.com>
El Monday 10 May 2010 04:31:22 Elvis Pfützenreuter escribió:
> >
> > Automatic reconnection should happen only in the case HDP has
> > disconnected the transport for power-saving, because the data layer is
> > idle, doesn't it? So will (b) ever happen? In the case the connection
> > is dropped (loss of signal etc) the data layer should always be
> > notified IMO (case c).
>
> MCAP spec says that
>
> "Because the Source and Sink assign a unique MDL ID when a new MDL is formed, using this same ID later allows a reconnection to the same context after they are intentionally
closed or unintentionally broken (possibly from interference or temporarily moving out of range)." (Page 27)
>
> HDP spec always talks mentions "reconnection" and "power saving" near each other, but I guess it is in a broader context (not having to renegotiate every data channel after an
involuntary break-up also saves power).--
Completely agree with this, reconnections should be performed until the
data channel is deleted (this mdlid is no valid anymore for reconnections)
or until one of the sessions is closed, the remote or the local.
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: José Antonio Santos Cadenas @ 2010-05-10 7:47 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Gustavo F. Padovan, linux-bluetooth@vger.kernel.org
In-Reply-To: <k2taa32413d1005071125ob7ce6505q8bb2cc57a77f1c8f@mail.gmail.com>
El Friday 07 May 2010 20:25:17 João Paulo Rechi Vita escribió:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
>
> >> Data transmission options:
> >>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
That's exactly what I tried to expose. If you do fd-passing with the l2cap socket, it
is possible that the client writes data in a closed socket. If HDP fd-pass a pipe socket,
the client will write on the pipe, this way the client perceives just one file descriptor
which is exactly what we wanted if reconnections are implicit.
>
> >>
> >> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> >> chanel socket. The problem with this is that we need 2 pipes for each data
> >> channel, but no data will be lost because HDP controls the data flow with the
> >> sockets and resend data not correctly sent.
> >>
> >> We think that the easier way for implicit reconnections is option 2.
> >> Because the application can always write on the socket it have (the pipe).
> >> Once written, the HDP layer tries to write it in the l2cap socket, if it
> >> fails, perform a reconnection operation over the data channel.
> >>
>
> Considering the drawbacks of the other alternatives and taking into
> account that implicit reconnection is the right approach, this seems
> the better option. I can't see any problems on having 2 pipes per data
> channel, but I personally have never worked with splice directly so I
> can't address much issues of this approach.
That's the best option for us too. As I said above, this way the client perceives
the same socket during the whole live of the connection, perfect for
implicit reconnections.
>
> >> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> >> d-bus, because of the overload of the system bus.
> >
> > Pretty bad ;)
> >
>
> As Gustavo said, transmitting data over d-bus would be very bad. On
> some embedded platforms d-bus can be really slow and even for the
> desktop case this is unnecessary overhead.
>
> >>
> >> Option 4: Other IPC alternatives (more alternative here?)
> >>
>
>
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Elvis Pfützenreuter @ 2010-05-10 2:31 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: Gustavo F. Padovan, José Antonio Santos Cadenas,
linux-bluetooth@vger.kernel.org
In-Reply-To: <u2paa32413d1005091808n54065c98o26ac89de1dde8770@mail.gmail.com>
>
> Automatic reconnection should happen only in the case HDP has
> disconnected the transport for power-saving, because the data layer is
> idle, doesn't it? So will (b) ever happen? In the case the connection
> is dropped (loss of signal etc) the data layer should always be
> notified IMO (case c).
MCAP spec says that
"Because the Source and Sink assign a unique MDL ID when a new MDL is formed, using this same ID later allows a reconnection to the same context after they are intentionally closed or unintentionally broken (possibly from interference or temporarily moving out of range)." (Page 27)
HDP spec always talks mentions "reconnection" and "power saving" near each other, but I guess it is in a broader context (not having to renegotiate every data channel after an involuntary break-up also saves power).
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: João Paulo Rechi Vita @ 2010-05-10 1:08 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: Gustavo F. Padovan, José Antonio Santos Cadenas,
linux-bluetooth@vger.kernel.org
In-Reply-To: <8D8F1AA1-A7C1-4636-BB75-1EF1A2E1A556@signove.com>
On Fri, May 7, 2010 at 18:18, Elvis Pfützenreuter <epx@signove.com> wrote:
>
>>> I guess the problem Jose tried to address here is the case that HDP
>>> had temporarily disconnected the data channel and then the application
>>> try to write to the FD (which will be closed). Some data may be lost
>>> by the application on this process.
>>
>> If you are using Streming Mode you really don't care, if ERTM an error
>> will be reported and the application will get notified. ;)
>
> Ok, I think we have a conclusion, the Libresoft guys were right all along.
>
> Since the IEEE protocol over the data channel is a request-indication guy, one of these possible scenarios will happen:
>
> a) send request, receive indication
> b) send request, socket closes
> c) send request, socket closes, MCAP connection dropped feedback
>
> Our problem is the (b) case. We don't know if the request arrived at the other end. So the application must be able to replay the request upon receving the new socket for the same data channel. The reconnection itself does not need to be notified (though fd replacement is a clear sign that it happened.). And best of all, we can pass the L2CAP socket itself, not a pipe.
>
> The only thing that must be crystal clear in API is: the fd socket may get invalid anytime, and the application must be able to replay the pending requests. The reconnection is "transparent" pero no mucho :)
>
Automatic reconnection should happen only in the case HDP has
disconnected the transport for power-saving, because the data layer is
idle, doesn't it? So will (b) ever happen? In the case the connection
is dropped (loss of signal etc) the data layer should always be
notified IMO (case c).
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* RE: [PATCH] Dial-up Networking profile API
From: Zhang, Zhenhua @ 2010-05-10 0:41 UTC (permalink / raw)
To: Gustavo F. Padovan, linux-bluetooth@vger.kernel.org
In-Reply-To: <1273371107-31813-1-git-send-email-gustavo@padovan.org>
Hi Padovan,
linux-bluetooth-owner@vger.kernel.org wrote:
> It is exactly the same API of Handsfree profile. The idea is
> to use the same Agent logic.
> ---
> doc/dun-api.txt | 82
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 82 insertions(+), 0 deletions(-) create
> mode 100644 doc/dun-api.txt
>
> diff --git a/doc/dun-api.txt b/doc/dun-api.txt new file mode 100644
> index 0000000..af1c507 --- /dev/null
> +++ b/doc/dun-api.txt
> @@ -0,0 +1,82 @@
> +DUNGateway hierarchy
> +========================
> +
> +Service org.bluez
> +Interface org.bluez.DUNGateway
> +Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX +
> +This interface is available for remote devices which can function in
> +the Gateway role of the DUN profile. It is intended to be used with
> +external handlers of the DUN Protocol.
> +
> +Methods void Connect()
> +
> + Connect to the GW service on the remote device. +
> + void Disconnect()
> +
> + Disconnect from the GW service on the
> remote device
> +
> + dict GetProperties()
> +
> + Returns all properties for the
> interface. See the
> + properties section for available properties.
> +
> + void RegisterAgent(object path)
> +
> + The object path defines the path the of
> the agent
> + that will be called when a new DUN connection
> + is established.
> +
> + If an application disconnects from the
> bus all of its
> + registered agents will be removed.
> +
> + void UnregisterAgent(object path)
> +
> + This unregisters the agent that has
> been previously
> + registered. The object path parameter
> must match the
> + same value that has been used on registration.
> +
> + Possible Errors: org.bluez.Error.Failed
> +
> org.bluez.Error.InvalidArguments
> +
> +
> +Signals PropertyChanged(string name, variant value) +
> + This signal indicates a changed value
> of the given
> + property.
> +
> +Properties string State [readonly]
> +
> + Indicates the state of the connection. Possible + values are:
> + "disconnected"
> + "connecting"
> + "connected"
> +
> +DUNAgent hierarchy
> +===============
> +
> +Service unique name
> +Interface org.bluez.DUNAgent
> +Object path freely definable
> +
> +Methods void NewConnection(filedescriptor fd)
> +
> + This method gets called whenever a new DUN
> + connection has been established. The objectpath
> + contains the object path of the remote
> device. This
> + method assumes that DBus daemon with
> file descriptor
> + passing capability is being used.
> +
> + The agent should only return
> successfully once the
> + establishment of the data call has been fineshed
A typo 'fineshed' should be 'finished'.
> + without problems.
> +
> + Possible Errors:
> org.bluez.Error.InvalidArguments
> + org.bluez.Error.Failed
> +
> + void Release()
> +
> + This method gets called whenever the service daemon
> + unregisters the agent.
Compared with hfp-api.txt, I think we should also add the sentence like "or whenever the Adapter where the DUNAgent registers itself is removed".
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe
> linux-bluetooth" in the body of a message to
> majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
Regards,
Zhenhua
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: Luiz Augusto von Dentz @ 2010-05-09 15:14 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: João Paulo Rechi Vita, jcaden, linux-bluetooth
In-Reply-To: <32F45991-49B0-4B46-84C0-789A3B1D8766@signove.com>
Hi,
On Sat, May 8, 2010 at 12:08 AM, Elvis Pfützenreuter <epx@signove.com> wrote:
>>
>> Device objects exists for each paired device. If the pairing is
>> removed the object is also removed and a new pairing is needed before
>> connecting to it (as imposed by the whole bluetooth stack logic
>> anyway).
>
> AFAIK the HDP source and sink must be paired before any session can be established, so the relevant device objects will always be there, so the path can be (re)used.
Exactly, I tried to explain this before that device objects is a
better way to expose any relevant API since that would be created
anyway. It also has integration with the sdp record cache and are
reloaded during the initialization and I hardly see us doing anything
to revert this, since pretty much every plugin depend on this to work.
So, with this in mind, IMHO, the whole concept of exposure the
sessions won't fit nicely in BlueZ API, first because it uses the
adapter path to create session passing a device path, which btw
already is associated with adapter anyway, second because any client
seems to be able to create those sessions even if they are unable to
control them because they don't hold an agent, and third I don't think
we should be exposing protocol internals in a D-Bus API, this id's
make as much sense as the bdaddr in the ui (read _none_), it is as
usable as we starting exposing local and remote seid (Stream Endpoint
id, surprisingly similar to endpoint here) to pulseaudio to carry on
with all avdtp protocol details, this will only fragment the logic
around those bits and certainly won't make it work better.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Add dynamic debug feature
From: Gustavo F. Padovan @ 2010-05-09 3:05 UTC (permalink / raw)
To: linux-bluetooth; +Cc: gustavo
It is still needed a sed work in the sources to changes debug() to DBG()
Thanks, to Vinicius Gomes that helped me sort out a linking issue with
this patch.
---
src/logging.c | 64 +++++++++++++++++++++++++++++++++++++++++---------------
src/logging.h | 28 +++++++++++++++++++++++-
src/main.c | 24 +++++----------------
tracer/main.c | 24 +++++----------------
4 files changed, 85 insertions(+), 55 deletions(-)
diff --git a/src/logging.c b/src/logging.c
index 704f848..a9956be 100644
--- a/src/logging.c
+++ b/src/logging.c
@@ -29,9 +29,9 @@
#include <stdarg.h>
#include <syslog.h>
-#include "logging.h"
+#include <glib.h>
-static volatile int debug_enabled = 0;
+#include "logging.h"
static inline void vinfo(const char *format, va_list ap)
{
@@ -64,9 +64,6 @@ void debug(const char *format, ...)
{
va_list ap;
- if (!debug_enabled)
- return;
-
va_start(ap, format);
vsyslog(LOG_DEBUG, format, ap);
@@ -74,26 +71,57 @@ void debug(const char *format, ...)
va_end(ap);
}
-void toggle_debug(void)
-{
- debug_enabled = (debug_enabled + 1) % 2;
-}
+extern struct bluez_debug_desc __start___debug[];
+extern struct bluez_debug_desc __stop___debug[];
-void enable_debug(void)
-{
- debug_enabled = 1;
-}
+static gchar **enabled = NULL;
-void disable_debug(void)
+static gboolean is_enabled(struct bluez_debug_desc *desc)
{
- debug_enabled = 0;
+ int i;
+
+ if (enabled == NULL)
+ return 0;
+
+ for (i = 0; enabled[i] != NULL; i++) {
+ if (desc->name != NULL && g_pattern_match_simple(enabled[i],
+ desc->name) == TRUE)
+ return 1;
+ if (desc->file != NULL && g_pattern_match_simple(enabled[i],
+ desc->file) == TRUE)
+ return 1;
+ }
+
+ return 0;
}
-void start_logging(const char *ident, const char *message, ...)
+void start_logging(const char *debug, int detach, const char *ident, const char *message, ...)
{
+ int option = LOG_NDELAY | LOG_PID;
+ struct bluez_debug_desc *desc;
+ const char *name = NULL, *file = NULL;
va_list ap;
- openlog(ident, LOG_PID | LOG_NDELAY | LOG_PERROR, LOG_DAEMON);
+ if (debug != NULL)
+ enabled = g_strsplit_set(debug, ":, ", 0);
+
+ for (desc = __start___debug; desc < __stop___debug; desc++) {
+ if (file != NULL || name != NULL) {
+ if (g_strcmp0(desc->file, file) == 0) {
+ if (desc->name == NULL)
+ desc->name = name;
+ } else
+ file = NULL;
+ }
+
+ if (is_enabled(desc))
+ desc->flags |= BLUEZ_DEBUG_FLAG_PRINT;
+ }
+
+ if (!detach)
+ option |= LOG_PERROR;
+
+ openlog(ident, option, LOG_DAEMON);
va_start(ap, message);
@@ -105,4 +133,6 @@ void start_logging(const char *ident, const char *message, ...)
void stop_logging(void)
{
closelog();
+
+ g_strfreev(enabled);
}
diff --git a/src/logging.h b/src/logging.h
index 2e9d564..b1a58a8 100644
--- a/src/logging.h
+++ b/src/logging.h
@@ -30,9 +30,33 @@ void debug(const char *format, ...) __attribute__((format(printf, 1, 2)));
void toggle_debug(void);
void enable_debug(void);
void disable_debug(void);
-void start_logging(const char *ident, const char *message, ...);
+void start_logging(const char *debug, int detach, const char *ident, const char *message, ...);
void stop_logging(void);
-#define DBG(fmt, arg...) debug("%s: " fmt "\n" , __FUNCTION__ , ## arg)
+struct bluez_debug_desc {
+ const char *name;
+ const char *file;
+#define BLUEZ_DEBUG_FLAG_DEFAULT (0)
+#define BLUEZ_DEBUG_FLAG_PRINT (1 << 0)
+ unsigned int flags;
+} __attribute__((aligned(8)));
+
+/**
+ * DBG:
+ * @fmt: format string
+ * @arg...: list of arguments
+ *
+ * Simple macro around debug() which also include the function
+ * name it is called in.
+ */
+#define DBG(fmt, arg...) do { \
+ static struct bluez_debug_desc __bluez_debug_desc \
+ __attribute__((used, section("__debug"), aligned(8))) = { \
+ .file = __FILE__, .flags = BLUEZ_DEBUG_FLAG_DEFAULT, \
+ }; \
+ if (__bluez_debug_desc.flags & BLUEZ_DEBUG_FLAG_PRINT) \
+ debug("%s:%s() " fmt, \
+ __FILE__, __FUNCTION__ , ## arg); \
+} while (0)
#endif /* __LOGGING_H */
diff --git a/src/main.c b/src/main.c
index 014d8b6..be7c1d4 100644
--- a/src/main.c
+++ b/src/main.c
@@ -288,13 +288,8 @@ static void sig_term(int sig)
g_main_loop_quit(event_loop);
}
-static void sig_debug(int sig)
-{
- toggle_debug();
-}
-
+static gchar *option_debug = NULL;
static gboolean option_detach = TRUE;
-static gboolean option_debug = FALSE;
static gboolean option_udev = FALSE;
static guint last_adapter_timeout = 0;
@@ -331,8 +326,8 @@ static GOptionEntry options[] = {
{ "nodaemon", 'n', G_OPTION_FLAG_REVERSE,
G_OPTION_ARG_NONE, &option_detach,
"Don't run as daemon in background" },
- { "debug", 'd', 0, G_OPTION_ARG_NONE, &option_debug,
- "Enable debug information output" },
+ { "debug", 'd', 0, G_OPTION_ARG_STRING, &option_debug,
+ "Enable debug information output", "DEBUG" },
{ "udev", 'u', 0, G_OPTION_ARG_NONE, &option_udev,
"Run from udev mode of operation" },
{ NULL },
@@ -392,7 +387,8 @@ int main(int argc, char *argv[])
umask(0077);
- start_logging("bluetoothd", "Bluetooth daemon %s", VERSION);
+ start_logging(option_debug, option_detach,
+ "bluetoothd", "Bluetooth daemon %s", VERSION);
memset(&sa, 0, sizeof(sa));
sa.sa_flags = SA_NOCLDSTOP;
@@ -400,17 +396,9 @@ int main(int argc, char *argv[])
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
- sa.sa_handler = sig_debug;
- sigaction(SIGUSR2, &sa, NULL);
-
sa.sa_handler = SIG_IGN;
sigaction(SIGPIPE, &sa, NULL);
- if (option_debug == TRUE) {
- info("Enabling debug information");
- enable_debug();
- }
-
config = load_config(CONFIGDIR "/main.conf");
parse_config(config);
@@ -446,7 +434,7 @@ int main(int argc, char *argv[])
rfkill_init();
- debug("Entering main loop");
+ DBG("Entering main loop");
g_main_loop_run(event_loop);
diff --git a/tracer/main.c b/tracer/main.c
index 5ec5ff2..0257e00 100644
--- a/tracer/main.c
+++ b/tracer/main.c
@@ -48,20 +48,15 @@ static void sig_term(int sig)
g_main_loop_quit(event_loop);
}
-static void sig_debug(int sig)
-{
- toggle_debug();
-}
-
static gboolean option_detach = TRUE;
-static gboolean option_debug = FALSE;
+static gchar *option_debug = NULL;
static GOptionEntry options[] = {
{ "nodaemon", 'n', G_OPTION_FLAG_REVERSE,
G_OPTION_ARG_NONE, &option_detach,
"Don't run as daemon in background" },
- { "debug", 'd', 0, G_OPTION_ARG_NONE, &option_debug,
- "Enable debug information output" },
+ { "debug", 'd', 0, G_OPTION_ARG_STRING, &option_debug,
+ "Enable debug information output", "DEBUG" },
{ NULL },
};
@@ -103,7 +98,8 @@ int main(int argc, char *argv[])
umask(0077);
- start_logging("hcitrace", "HCI trace daemon %s", VERSION);
+ start_logging(option_debug, option_detach,
+ "hcitrace", "HCI trace daemon %s", VERSION);
memset(&sa, 0, sizeof(sa));
sa.sa_flags = SA_NOCLDSTOP;
@@ -111,20 +107,12 @@ int main(int argc, char *argv[])
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
- sa.sa_handler = sig_debug;
- sigaction(SIGUSR2, &sa, NULL);
-
sa.sa_handler = SIG_IGN;
sigaction(SIGPIPE, &sa, NULL);
- if (option_debug == TRUE) {
- info("Enabling debug information");
- enable_debug();
- }
-
event_loop = g_main_loop_new(NULL, FALSE);
- debug("Entering main loop");
+ DBG("Entering main loop");
g_main_loop_run(event_loop);
--
1.7.1
^ permalink raw reply related
* [PATCH] Dial-up Networking profile API
From: Gustavo F. Padovan @ 2010-05-09 2:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: gustavo
It is exactly the same API of Handsfree profile. The idea is to use the
same Agent logic.
---
doc/dun-api.txt | 82 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
create mode 100644 doc/dun-api.txt
diff --git a/doc/dun-api.txt b/doc/dun-api.txt
new file mode 100644
index 0000000..af1c507
--- /dev/null
+++ b/doc/dun-api.txt
@@ -0,0 +1,82 @@
+DUNGateway hierarchy
+========================
+
+Service org.bluez
+Interface org.bluez.DUNGateway
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+This interface is available for remote devices which can function in the
+Gateway role of the DUN profile. It is intended to be used with external
+ handlers of the DUN Protocol.
+
+Methods void Connect()
+
+ Connect to the GW service on the remote device.
+
+ void Disconnect()
+
+ Disconnect from the GW service on the remote device
+
+ dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ void RegisterAgent(object path)
+
+ The object path defines the path the of the agent
+ that will be called when a new DUN connection
+ is established.
+
+ If an application disconnects from the bus all of its
+ registered agents will be removed.
+
+ void UnregisterAgent(object path)
+
+ This unregisters the agent that has been previously
+ registered. The object path parameter must match the
+ same value that has been used on registration.
+
+ Possible Errors: org.bluez.Error.Failed
+ org.bluez.Error.InvalidArguments
+
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string State [readonly]
+
+ Indicates the state of the connection. Possible
+ values are:
+ "disconnected"
+ "connecting"
+ "connected"
+
+DUNAgent hierarchy
+===============
+
+Service unique name
+Interface org.bluez.DUNAgent
+Object path freely definable
+
+Methods void NewConnection(filedescriptor fd)
+
+ This method gets called whenever a new DUN
+ connection has been established. The objectpath
+ contains the object path of the remote device. This
+ method assumes that DBus daemon with file descriptor
+ passing capability is being used.
+
+ The agent should only return successfully once the
+ establishment of the data call has been fineshed
+ without problems.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Release()
+
+ This method gets called whenever the service daemon
+ unregisters the agent.
--
1.7.1
^ permalink raw reply related
* Re: HDP proposed api (ver 0.2)
From: Elvis Pfützenreuter @ 2010-05-07 21:08 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: jcaden, linux-bluetooth
In-Reply-To: <n2haa32413d1005071351qb6db6039u7caab57a5e893884@mail.gmail.com>
>
> Device objects exists for each paired device. If the pairing is
> removed the object is also removed and a new pairing is needed before
> connecting to it (as imposed by the whole bluetooth stack logic
> anyway).
AFAIK the HDP source and sink must be paired before any session can be established, so the relevant device objects will always be there, so the path can be (re)used.
> Re-using the device path and adding sessions as sub-paths seems
> reasonable, but I would wait on comments from Johan / Luiz / Marcel if
> this is desirable or might have any side-implication before defining
> this topic as closed.
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: João Paulo Rechi Vita @ 2010-05-07 20:51 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: jcaden, linux-bluetooth
In-Reply-To: <2541510E-4912-4AEB-AEFB-83F4339EC3FA@signove.com>
On Fri, May 7, 2010 at 10:46, Elvis Pfützenreuter <epx@signove.com> wrote:
>>> "Forcing" a source to specify the MDEP IDs here, even if not publishing the
>>> record, makes checks easier further.
>>
>> Not sure about that. Note that when you don't publish a SDP record, nobody
>> could connect to you, so you won't receive data channel connections request,
>> so you don't need to check if the mdeps are in use or not.
>
> Indeed, you are right; from spec point of view I am not forced to define MDEP IDs beforehand (my old habits of TCP/IP, having ports both sides, sometimes overwhelm me :)
>
> The actual argument is higher level: whether should we *force* the application to specify the MDEP IDs / data types beforehand (as I "voted", with "my" API) or not (as you "voted").
>
> This is the point we need more opinions, from people in the list :)
>
>
>>> Perhaps you tried to accomodate the notion that a data channel ID
>>> "survives" even if the device disappearrs for a short moment?
>>
>> Also this, remember that MCAP allow temporal disconnections to reestablish
>> them in future connections to save state.
>
> Ok, I need to see whether BlueZ keeps the device objects in D-BUS tree after disconnection of if it removees it immediately. If it keeps the object, the sessions should be there as sub-paths (to be consistent with HdpSession being a part of adapter path.). If it doesn't, indeed they need to go somewhere else.
Device objects exists for each paired device. If the pairing is
removed the object is also removed and a new pairing is needed before
connecting to it (as imposed by the whole bluetooth stack logic
anyway).
Re-using the device path and adding sessions as sub-paths seems
reasonable, but I would wait on comments from Johan / Luiz / Marcel if
this is desirable or might have any side-implication before defining
this topic as closed.
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Gustavo F. Padovan @ 2010-05-07 20:17 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: José Antonio Santos Cadenas, linux-bluetooth@vger.kernel.org
In-Reply-To: <BC6ABF7A-4847-4DDE-B3D6-584BEF215D65@signove.com>
* Elvis Pfützenreuter <epx@signove.com> [2010-05-07 16:55:13 -0300]:
> >
> > Also I still have to check the case when the remote side requests a
> > disconnect. I'm adding these stuff to my todo list an I'll work on it
> > soon.
>
> I imagined the case when send(msg) returns, the msg is still in output buffer and then the connection drops due e.g. to faint signal (not voluntary close). (I understand ERTM guarantees atomic delivery of message, but I don't think it blocks send() until the message is safely at the other side.)
The sock stays connected, if such error happen it will be disconnected
and error will be reported. Also blocking on sending doesn't guarantee
if you data will be delivered.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Gustavo F. Padovan @ 2010-05-07 19:57 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: José Antonio Santos Cadenas, linux-bluetooth@vger.kernel.org
In-Reply-To: <k2taa32413d1005071125ob7ce6505q8bb2cc57a77f1c8f@mail.gmail.com>
Hi all,
* João Paulo Rechi Vita <jprvita@gmail.com> [2010-05-07 15:25:17 -0300]:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
>
> >> Data transmission options:
> >>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
If you are using Streming Mode you really don't care, if ERTM an error
will be reported and the application will get notified. ;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Elvis Pfützenreuter @ 2010-05-07 19:55 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: José Antonio Santos Cadenas, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100507194919.GA4857@vigoh>
>
> Also I still have to check the case when the remote side requests a
> disconnect. I'm adding these stuff to my todo list an I'll work on it
> soon.
I imagined the case when send(msg) returns, the msg is still in output buffer and then the connection drops due e.g. to faint signal (not voluntary close). (I understand ERTM guarantees atomic delivery of message, but I don't think it blocks send() until the message is safely at the other side.)
^ permalink raw reply
* Re: Software caused connection abort (103 )
From: Gustavo F. Padovan @ 2010-05-07 19:53 UTC (permalink / raw)
To: john michelle; +Cc: linux-bluetooth
In-Reply-To: <s2oa6ca4e821005071249tdfd2e197i2595b57ae2ccb705@mail.gmail.com>
* john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05 -0400]:
> Hi Bluetooth hackers,
>
> i am having this consistent problem with bluez , from time to time i
> get the error Software caused connection abort (103 )
> And the bluetooth stick seems to disconnect and reconnects. this
> happens during an sco connection and it occurs even
> More when i am having the voice stream comming through the internet
> rather than the lan.i don't know what exact
> Details you need to solve this problem please tell me and i will give
> you an immediate reply . i have linux kernel 2.6.33 and bluez 4.62
I get the same problem sometimes when testing ERTM with l2test. So the
problem is on l2cap too. I didn't have time to debug this yet. Now that
someone else have confirmed it too, I'll to take a look at the problem.
>
> John
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Gustavo F. Padovan @ 2010-05-07 19:49 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: José Antonio Santos Cadenas, linux-bluetooth@vger.kernel.org
In-Reply-To: <82D1897F-4DEE-47F9-BD00-57087F182C3D@signove.com>
Hi Elvis,
* Elvis Pfützenreuter <epx@signove.com> [2010-05-07 10:20:59 -0300]:
>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
>
> Actually the worry is not whether D-BUS can lose the data midway (it can't indeed), but if the L2CAP connection closes and the application is not sure about the last message having been sent.
If the close is requested by the local side I guarantee on ERTM that
close will return only after receive the ack of the last packet sent
or some error happens and the channel get closed anyway -- I have to
check if I report a error in this case. ERTM has to guarantee the case
you are talking about, since it is reliable.
Also I still have to check the case when the remote side requests a
disconnect. I'm adding these stuff to my todo list an I'll work on it
soon.
It's nice that we are going to have real users to my ERTM code. ;-)
Regards,
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Software caused connection abort (103 )
From: john michelle @ 2010-05-07 19:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <w2ra6ca4e821005071241w9d7d982ezb78ad0ba4480e73d@mail.gmail.com>
Hi Bluetooth hackers,
i am having this consistent problem with bluez , from time to time i
get the error Software caused connection abort (103 )
And the bluetooth stick seems to disconnect and reconnects. this
happens during an sco connection and it occurs even
More when i am having the voice stream comming through the internet
rather than the lan.i don't know what exact
Details you need to solve this problem please tell me and i will give
you an immediate reply . i have linux kernel 2.6.33 and bluez 4.62
John
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: João Paulo Rechi Vita @ 2010-05-07 18:49 UTC (permalink / raw)
To: Santiago Carot-Nemesio
Cc: José Antonio Santos Cadenas, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org
In-Reply-To: <1273257547.1912.10.camel@mosquito>
Hello Santiago!
2010/5/7 Santiago Carot-Nemesio <scarot@libresoft.es>:
> Hi João Paul,
>
> El vie, 07-05-2010 a las 15:25 -0300, João Paulo Rechi Vita escribió:
>> Hello Jose!
>>
>> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>> > Hi José,
>> >
>> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
>> >
>> >> Hi all,
>> >>
>> >> I start this thread to discuss the alternatives to move the data from the
>> >> application to the l2cap socket in HDP. Till now we have the following
>> >> alternatives (please, add more if we missed something)
>> >>
>> >> Reconnections options:
>> >>
>> >> Option 1: Implicit reconnections: The application is not concern about the
>> >> disconnections or reconnections of the data channel until it is deleted.
>> >>
>> >> We prefer this option because fixes more with a manager philosophy. A
>> >> 20601 manager sould not perceive temporal disconnections because this way can
>> >> hold it state if it perceives a disconnection, next time it reconnects it will
>> >> need to exchange again apdus for association.
>> >>
>> >> Option 2: Reconnections by the application. The applications are notified when
>> >> a data channel is disconnected and should perform a reconnection before using
>> >> it again.
>> >>
>>
>> The HDP Implementation Guidance Whitepaper clearly states that
>> transport (HDP) disconnection / reconnection should be transparent for
>> the data layer (IEEE 11073-20601), so I guess option 2 here would
>> break the spec.
>
> You're rigth, we consider that option 1 is the best approach. But it's
> better try get consensus ;)
> In addition, option 2 pass MCAP logic to application layer
> (connection-reconnection), and 11073-20601 should be independent of such
> transport specific characteristics.
>
My main concern here is not about which one is the best approach, but
about specification-compliance. Sometimes we may want to deviate a bit
from the spec if this provides a big performance gain or so, but it
has to be evaluated with much caution, since it can compromise
qualification with the Bluetooth SIG (on some cases for the whole
stack). I may have misread the spec and it might have left this
approach 2 as an option, so please correct me in this case. But if
not, I guess approach should not be considered.
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Santiago Carot-Nemesio @ 2010-05-07 18:39 UTC (permalink / raw)
To: João Paulo Rechi Vita
Cc: José Antonio Santos Cadenas, Gustavo F. Padovan,
linux-bluetooth@vger.kernel.org
In-Reply-To: <k2taa32413d1005071125ob7ce6505q8bb2cc57a77f1c8f@mail.gmail.com>
Hi João Paul,
El vie, 07-05-2010 a las 15:25 -0300, João Paulo Rechi Vita escribió:
> Hello Jose!
>
> On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> > Hi José,
> >
> > * José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
> >
> >> Hi all,
> >>
> >> I start this thread to discuss the alternatives to move the data from the
> >> application to the l2cap socket in HDP. Till now we have the following
> >> alternatives (please, add more if we missed something)
> >>
> >> Reconnections options:
> >>
> >> Option 1: Implicit reconnections: The application is not concern about the
> >> disconnections or reconnections of the data channel until it is deleted.
> >>
> >> We prefer this option because fixes more with a manager philosophy. A
> >> 20601 manager sould not perceive temporal disconnections because this way can
> >> hold it state if it perceives a disconnection, next time it reconnects it will
> >> need to exchange again apdus for association.
> >>
> >> Option 2: Reconnections by the application. The applications are notified when
> >> a data channel is disconnected and should perform a reconnection before using
> >> it again.
> >>
>
> The HDP Implementation Guidance Whitepaper clearly states that
> transport (HDP) disconnection / reconnection should be transparent for
> the data layer (IEEE 11073-20601), so I guess option 2 here would
> break the spec.
You're rigth, we consider that option 1 is the best approach. But it's
better try get consensus ;)
In addition, option 2 pass MCAP logic to application layer
(connection-reconnection), and 11073-20601 should be independent of such
transport specific characteristics.
>
> >> Data transmission options:
> >>
> >> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> >> problem with this is that some data can be lost by d-bus if the channel is
> >> disconnected. (We have to check how fd-passing works).
> >
> > DBus just pass the fd and then don't touch the fd anymore, data can't be
> > lost by DBus.
> >
>
> I guess the problem Jose tried to address here is the case that HDP
> had temporarily disconnected the data channel and then the application
> try to write to the FD (which will be closed). Some data may be lost
> by the application on this process.
>
> >>
> >> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> >> chanel socket. The problem with this is that we need 2 pipes for each data
> >> channel, but no data will be lost because HDP controls the data flow with the
> >> sockets and resend data not correctly sent.
> >>
> >> We think that the easier way for implicit reconnections is option 2.
> >> Because the application can always write on the socket it have (the pipe).
> >> Once written, the HDP layer tries to write it in the l2cap socket, if it
> >> fails, perform a reconnection operation over the data channel.
> >>
>
> Considering the drawbacks of the other alternatives and taking into
> account that implicit reconnection is the right approach, this seems
> the better option. I can't see any problems on having 2 pipes per data
> channel, but I personally have never worked with splice directly so I
> can't address much issues of this approach.
We are considering this approach depending of comments got from this
thread, it isn't a final design yet... but may be, we need study more
alternatives.
>
> >> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> >> d-bus, because of the overload of the system bus.
> >
> > Pretty bad ;)
> >
>
> As Gustavo said, transmitting data over d-bus would be very bad. On
> some embedded platforms d-bus can be really slow and even for the
> desktop case this is unnecessary overhead.
We descarted this option from first time, but it appeared in other
e-mail so we should search consensus here too.
Thank a lot for your comments.
Best regards.
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: João Paulo Rechi Vita @ 2010-05-07 18:25 UTC (permalink / raw)
To: José Antonio Santos Cadenas
Cc: Gustavo F. Padovan, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100507120859.GD12461@vigoh>
Hello Jose!
On Fri, May 7, 2010 at 09:08, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi José,
>
> * José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
>
>> Hi all,
>>
>> I start this thread to discuss the alternatives to move the data from the
>> application to the l2cap socket in HDP. Till now we have the following
>> alternatives (please, add more if we missed something)
>>
>> Reconnections options:
>>
>> Option 1: Implicit reconnections: The application is not concern about the
>> disconnections or reconnections of the data channel until it is deleted.
>>
>> We prefer this option because fixes more with a manager philosophy. A
>> 20601 manager sould not perceive temporal disconnections because this way can
>> hold it state if it perceives a disconnection, next time it reconnects it will
>> need to exchange again apdus for association.
>>
>> Option 2: Reconnections by the application. The applications are notified when
>> a data channel is disconnected and should perform a reconnection before using
>> it again.
>>
The HDP Implementation Guidance Whitepaper clearly states that
transport (HDP) disconnection / reconnection should be transparent for
the data layer (IEEE 11073-20601), so I guess option 2 here would
break the spec.
>> Data transmission options:
>>
>> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
>> problem with this is that some data can be lost by d-bus if the channel is
>> disconnected. (We have to check how fd-passing works).
>
> DBus just pass the fd and then don't touch the fd anymore, data can't be
> lost by DBus.
>
I guess the problem Jose tried to address here is the case that HDP
had temporarily disconnected the data channel and then the application
try to write to the FD (which will be closed). Some data may be lost
by the application on this process.
>>
>> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
>> chanel socket. The problem with this is that we need 2 pipes for each data
>> channel, but no data will be lost because HDP controls the data flow with the
>> sockets and resend data not correctly sent.
>>
>> We think that the easier way for implicit reconnections is option 2.
>> Because the application can always write on the socket it have (the pipe).
>> Once written, the HDP layer tries to write it in the l2cap socket, if it
>> fails, perform a reconnection operation over the data channel.
>>
Considering the drawbacks of the other alternatives and taking into
account that implicit reconnection is the right approach, this seems
the better option. I can't see any problems on having 2 pipes per data
channel, but I personally have never worked with splice directly so I
can't address much issues of this approach.
>> Option 3: Transmiting the data by d-bus. We think that this option is bad for
>> d-bus, because of the overload of the system bus.
>
> Pretty bad ;)
>
As Gustavo said, transmitting data over d-bus would be very bad. On
some embedded platforms d-bus can be really slow and even for the
desktop case this is unnecessary overhead.
>>
>> Option 4: Other IPC alternatives (more alternative here?)
>>
--
João Paulo Rechi Vita
http://jprvita.wordpress.com/
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: Elvis Pfützenreuter @ 2010-05-07 13:52 UTC (permalink / raw)
To: jcaden; +Cc: linux-bluetooth
In-Reply-To: <201005071324.01531.jcaden@libresoft.es>
On 07/05/2010, at 08:24, José Antonio Santos Cadenas wrote:
> I cleaned up the API with the changes suggested in the thread. There are still
> some parts that are being discussed.
It felt a whole lot better for me now, and HdpRemoteSession has been clarified in last e-mail, so now the pieces fit together. The remaining discussion points (forcing early list of MDEP IDs, remote session path etc.) have been mentioned at other e-mails.
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: Elvis Pfützenreuter @ 2010-05-07 13:46 UTC (permalink / raw)
To: jcaden; +Cc: linux-bluetooth
In-Reply-To: <201005071203.23882.jcaden@libresoft.es>
>> "Forcing" a source to specify the MDEP IDs here, even if not publishing the
>> record, makes checks easier further.
>
> Not sure about that. Note that when you don't publish a SDP record, nobody
> could connect to you, so you won't receive data channel connections request,
> so you don't need to check if the mdeps are in use or not.
Indeed, you are right; from spec point of view I am not forced to define MDEP IDs beforehand (my old habits of TCP/IP, having ports both sides, sometimes overwhelm me :)
The actual argument is higher level: whether should we *force* the application to specify the MDEP IDs / data types beforehand (as I "voted", with "my" API) or not (as you "voted").
This is the point we need more opinions, from people in the list :)
>> Perhaps you tried to accomodate the notion that a data channel ID
>> "survives" even if the device disappearrs for a short moment?
>
> Also this, remember that MCAP allow temporal disconnections to reestablish
> them in future connections to save state.
Ok, I need to see whether BlueZ keeps the device objects in D-BUS tree after disconnection of if it removees it immediately. If it keeps the object, the sessions should be there as sub-paths (to be consistent with HdpSession being a part of adapter path.). If it doesn't, indeed they need to go somewhere else.
^ permalink raw reply
* Re: Data transmission and reconnections in HDP
From: Gustavo F. Padovan @ 2010-05-07 12:08 UTC (permalink / raw)
To: José Antonio Santos Cadenas; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <201005071302.36198.jcaden@libresoft.es>
Hi José,
* José Antonio Santos Cadenas <jcaden@libresoft.es> [2010-05-07 13:02:36 +0200]:
> Hi all,
>
> I start this thread to discuss the alternatives to move the data from the
> application to the l2cap socket in HDP. Till now we have the following
> alternatives (please, add more if we missed something)
>
> Reconnections options:
>
> Option 1: Implicit reconnections: The application is not concern about the
> disconnections or reconnections of the data channel until it is deleted.
>
> We prefer this option because fixes more with a manager philosophy. A
> 20601 manager sould not perceive temporal disconnections because this way can
> hold it state if it perceives a disconnection, next time it reconnects it will
> need to exchange again apdus for association.
>
> Option 2: Reconnections by the application. The applications are notified when
> a data channel is disconnected and should perform a reconnection before using
> it again.
>
> Data transmission options:
>
> Option 1: Fd_passing the l2cap socket of the data channel to the client. The
> problem with this is that some data can be lost by d-bus if the channel is
> disconnected. (We have to check how fd-passing works).
DBus just pass the fd and then don't touch the fd anymore, data can't be
lost by DBus.
>
> Option 2: Fd_passing a pipe and HDP will write the data in the l2cap data
> chanel socket. The problem with this is that we need 2 pipes for each data
> channel, but no data will be lost because HDP controls the data flow with the
> sockets and resend data not correctly sent.
>
> We think that the easier way for implicit reconnections is option 2.
> Because the application can always write on the socket it have (the pipe).
> Once written, the HDP layer tries to write it in the l2cap socket, if it
> fails, perform a reconnection operation over the data channel.
>
> Option 3: Transmiting the data by d-bus. We think that this option is bad for
> d-bus, because of the overload of the system bus.
Pretty bad ;)
>
> Option 4: Other IPC alternatives (more alternative here?)
>
> Regards.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* MAC ADDRESS CHANGE
From: Ahmed Ragab @ 2010-05-07 11:59 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I bought 4 bluetooth dongles and all off them have the same mac
address.hciconfig -a show
hci0: Type: USB
BD Address: 00:15:83:15:A3:10 ACL MTU: 672:4 SCO MTU: 48:1
UP RUNNING PSCAN
RX bytes:5637 acl:26 sco:0 events:221 errors:0
TX bytes:2362 acl:25 sco:0 commands:179 errors:0
Features: 0xff 0x3e 0x85 0x38 0x18 0x18 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: ''
Class: 0x000104
Service Classes: Unspecified
Device Class: Computer, Desktop workstation
HCI Ver: 2.0 (0x3) HCI Rev: 0xc5c LMP Ver: 2.0 (0x3) LMP Subver: 0xc5c
Manufacturer: Cambridge Silicon Radio (10)
I tried ./bdaddr -i hci0 00:09:DA:50:29:30 , ./bdaddr -i hci0 -r
00:09:DA:50:29:30
,bccmd -d 0 psset -s 0 bdaddr 0×44 0×00 0×66 0×55 0×33 0×00 0×22 0×11
None of them seems to work. i have kernel 2.6.31 and bluez 4.60. i
only need to change
The mac address to avoid chaos when i proceed with my application
Thanks
Ahmed
^ permalink raw reply
* Re: HDP proposed api (ver 0.2)
From: José Antonio Santos Cadenas @ 2010-05-07 11:26 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <201005071324.01531.jcaden@libresoft.es>
El Friday 07 May 2010 13:24:01 José Antonio Santos Cadenas escribió:
> I cleaned up the API with the changes suggested in the thread. There are still
> some parts that are being discussed.
>
>
> BlueZ D-Bus HDP API description
> ***********************************
>
> Authors:
>
> Santiago Carot-Nemesio <sancane@gmail.com>
> José Antonio Santos-Cadenas <santoscadenas@gmail.com>
> Elvis Pfützenreuter <epx@signove.com>
>
> Health Device Profile hierarchy
> ===============================
>
> Service org.bluez
> Interface org.bluez.Hdp
> Object path [variable prefix]/{hci0,hci1,...}
>
> Methods object CreateSession(object path, dict config)
>
> Returns the object path for the new HDP session.
> The path parameter is the path of the remote object
> with the callbacks to notify events (see
> org.bluez.HdpAgent at the end of this document)
> This petition starts an mcap session and also register
> in the SDP is needed
> Dict is defined as bellow:
> { "data_spec" : The data_spec is the data exchange
> specficication (see section 5.2.10 of
> the specification document)
> possible values:
> 0x00 = reserved,
> 0x01 [IEEE 11073-20601],
> 0x02..0xff reserved,
> (optional)
> "end_points" : [{ (optional)
> "mdepid" : uint8, (optional)
> "role" : ("source" or "sink"), (mandatory)
> "specs" :[{ (mandatory)
> "data_type" : uint16, (mandatory)
> "description" : string, (optional)
> }]
> }]
> }
>
> if "data_spec" is not set, no SDP record will be
> registered, so all the other data in the dictionary
> will be ignored
>
> Session will be closed by the call or implicitly when
> the programs leaves the bus.
>
> Possible errors: org.bluez.Error.InvalidArguments
>
> void DeleteSession(object path)
>
> Delete the HDP session identified by the object path.
> Also session will be closed if the process that started
> it is removed from the D-Bus.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
>
> array remote_session_properties GetRemoteSessions()
still being discussed
>
> Returns an array with the remote session_properties
> of all the visible devices.
> remote_session_properties is a dictionary like:
> [{"session_id": a_session_identification (int or string,
> probably the SDP handler + btaddr)
> "data_spec" : the remote data spec,
> "end_points":
> ["mdepid": uint8,
> "role" : uint8,
> "specs" : [{
> "dtype" : uint16,
> "description" : string, (optional)
> }]
> ]
> }]
>
> Note that only remotes with a SDP record will be
> notified by this function.
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.HdpSession
> Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}
>
> object Connect(remote_session_id)
>
> Connects with the remote session and returns its object
> path.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.HdpError
>
> void Disconnect(object device, boolean delete)
>
> Disconnect from the remote device. If delete is true, any
> status will also be deleted. Otherwise, the status will
> be kept for allowing future reconnections.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> --------------------------------------------------------------------------------
>
> Service org.bluez
> Interface org.bluez.HdpRemoteSession
> Object path [variable prefix]/{hci0,hci1,...}/{hdp0,hdp1,...}/rem_session_id
>
> boolean Echo(array{byte})
>
> Sends an echo petition to the remote session. Return True
> if response matches with the buffer sent. If some error
> is detected False value is returned and the associated
> MCL is closed.
>
> uint16 OpenDataChannel(byte mdepid, byte config)
>
> Creates a new data channel with the indicated config
> to the remote MCAP Data End Point (MDEP).
> The configuration should indicate the channel quality of
> service.
> Returns the data channel id.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.HdpError
>
> file_descriptor GetDcFd(uint16 mdlid)
Wait till transport/fd-passing discussion is solved
>
> Gets a file descriptor where data can be read or
> written for receive or sent by the data channel.
> Returns the file descriptor
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> void DeleteDataChannel(uint16 mdlid)
>
> Deletes a data channel so it will not be available for
> use.
>
> Possible errors: org.bluez.Error.InvalidArguments
> org.bluez.Error.NotFound
> org.bluez.Error.HdpError
>
> void DeleteAllDataChannels()
still in discussion
>
> Deletes all data channels so it will not be available
> for use. Typically this function is called when the
> connection with the remote device will be closed
> permanently
>
> Possible errors: org.bluez.Error.HdpError
>
> dict GetDataChannelStatus()
>
> Return a dictionary with all the data channels that
> can be used to send data right now. The dictionary
> is formed like follows:
> {
> "reliable": [id1, ..., idz],
> "best_effort" : [idx, ..., idy]
> }
>
> The fist reliable data channel will always be the first
> data channel in reliable array.
>
> HDPAgent hierarchy
> ==================
>
> (this object is implemented by the HDP client an receives notifications)
>
> Service unique name
> Interface org.bluez.HdpAgent
> Object path freely definable
>
> void DeviceConnected(object path)
>
> This method is called whenever a new device connection
> has been established over the control channel of the
> current HDP session. The object path contains the object
> path of the remote device.
>
> void DeviceDisconnected(object path)
>
> This method is called when a remote device is
> disconnected definitively. Any future reconnections
> will fail. Also all data channels associated to this
> device will be closed.
>
> void CreatedDataChannel(object path, uint16 mdlid,
> filedescriptor fd)
>
> This method is called when a new data channel is created
> The path contains the object path of the device whith
> the new connection is created, the mdlid the data
> channel identificator and the fd is the file descriptor
> where the data can be readed or writed.
>
> void DeletedDataChannel(object path, uint16 mdlid)
>
> This method is called when a data channel is closed.
> After this call the data channel will not be valid and
> can be reused for future created data channels.
>
> void DataReady(object path, uint16 mdlid, filedescriptor fd)
probably it will disappear, depends on transport/fd-passing discussion
>
> This method is called when there is new data that can be
> read in a data channel
>
> void RemoteSession(dict remote_session_properties)
>
> This method is called when a new session is discorevered
> in a remote device. See Hdp.GetRemotes to know how the
> dictionary is formed.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox