max ulidtko | 3 Nov 09:38 2010
Picon

[PATCH] obex_client state transition fixes

As far as I can figure out, an obex_t instance which makes a request
(obex client) should never get into a state with MODE_SRV set. This
breaks proper dispatching of events and so on.

And so I assume that those MODE_SRV assignments in obex_client.c were
some kind of mistake. The patch fixes it.
---
 lib/obex_client.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/obex_client.c b/lib/obex_client.c
index 2ef636e..291cacf 100644
--- a/lib/obex_client.c
+++ b/lib/obex_client.c
 <at>  <at>  -88,7 +88,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
 			 * Jean II */
 			if (self->object->opcode == OBEX_CMD_CONNECT ||
 					obex_object_receive(self, msg) < 0) {
-				self->state = MODE_SRV | STATE_IDLE;
+				self->state = MODE_CLI | STATE_IDLE;
 				obex_deliver_event(self, OBEX_EV_PARSEERR, self->object->opcode, 0, TRUE);
 				return -1;
 			}
 <at>  <at>  -134,7 +134,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
 		if (self->object->opcode == OBEX_CMD_CONNECT) {
 			DEBUG(2, "We expect a connect-rsp\n");
 			if (obex_parse_connect_header(self, msg) < 0) {
-				self->state = MODE_SRV | STATE_IDLE;
+				self->state = MODE_CLI | STATE_IDLE;
 				obex_deliver_event(self, OBEX_EV_PARSEERR, self->object->opcode, 0, TRUE);
(Continue reading)

max ulidtko | 3 Nov 09:40 2010
Picon

[PATCH] obex_client state transition fixes

As far as I can figure out, an obex_t instance which makes a request
(obex client) should never get into a state with MODE_SRV set. This
breaks proper dispatching of events and so on.

And so I assume that those MODE_SRV assignments in obex_client.c were
some kind of mistake. The patch fixes it.
---
 lib/obex_client.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/lib/obex_client.c b/lib/obex_client.c
index 2ef636e..291cacf 100644
--- a/lib/obex_client.c
+++ b/lib/obex_client.c
 <at>  <at>  -88,7 +88,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
 			 * Jean II */
 			if (self->object->opcode == OBEX_CMD_CONNECT ||
 					obex_object_receive(self, msg) < 0) {
-				self->state = MODE_SRV | STATE_IDLE;
+				self->state = MODE_CLI | STATE_IDLE;
 				obex_deliver_event(self, OBEX_EV_PARSEERR, self->object->opcode, 0, TRUE);
 				return -1;
 			}
 <at>  <at>  -134,7 +134,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
 		if (self->object->opcode == OBEX_CMD_CONNECT) {
 			DEBUG(2, "We expect a connect-rsp\n");
 			if (obex_parse_connect_header(self, msg) < 0) {
-				self->state = MODE_SRV | STATE_IDLE;
+				self->state = MODE_CLI | STATE_IDLE;
 				obex_deliver_event(self, OBEX_EV_PARSEERR, self->object->opcode, 0, TRUE);
(Continue reading)

Luiz Augusto von Dentz | 3 Nov 09:52 2010
Picon

Re: [PATCH] obex_client state transition fixes

Hi,

On Wed, Nov 3, 2010 at 10:38 AM, max ulidtko <ulidtko <at> gmail.com> wrote:
> As far as I can figure out, an obex_t instance which makes a request
> (obex client) should never get into a state with MODE_SRV set. This
> breaks proper dispatching of events and so on.
>
> And so I assume that those MODE_SRV assignments in obex_client.c were
> some kind of mistake. The patch fixes it.
> ---
>  lib/obex_client.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/obex_client.c b/lib/obex_client.c
> index 2ef636e..291cacf 100644
> --- a/lib/obex_client.c
> +++ b/lib/obex_client.c
>  <at>  <at>  -88,7 +88,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
>                         * Jean II */
>                        if (self->object->opcode == OBEX_CMD_CONNECT ||
>                                        obex_object_receive(self, msg) < 0) {
> -                               self->state = MODE_SRV | STATE_IDLE;
> +                               self->state = MODE_CLI | STATE_IDLE;
>                                obex_deliver_event(self, OBEX_EV_PARSEERR,
self->object->opcode, 0, TRUE);
>                                return -1;
>                        }
>  <at>  <at>  -134,7 +134,7  <at>  <at>  int obex_client(obex_t *self, buf_t *msg, int final)
>                if (self->object->opcode == OBEX_CMD_CONNECT) {
>                        DEBUG(2, "We expect a connect-rsp\n");
(Continue reading)

Hendrik Sattler | 3 Nov 12:21 2010
Picon

Re: [PATCH] obex_client state transition fixes

Zitat von "Luiz Augusto von Dentz" <luiz.dentz <at> gmail.com>:
> On Wed, Nov 3, 2010 at 10:38 AM, max ulidtko <ulidtko <at> gmail.com> wrote:
>> As far as I can figure out, an obex_t instance which makes a request
>> (obex client) should never get into a state with MODE_SRV set. This
>> breaks proper dispatching of events and so on.
>>
>> And so I assume that those MODE_SRV assignments in obex_client.c were
>> some kind of mistake. The patch fixes it.
[...]
> Actually mode has been separated from state since some time, I don't
> think this patch even apply upstream anymore. But I agree that
> switching to server mode is a bit odd, but maybe there is a reason for
> that.

Indeed there is. MODE_SRV is also used as initial value for the mode  
field. Unless you take that obex_t and register as server with it, the  
MODE_SRV does nothing (there is no listening FD so nothing comes in  
this route).
MODE_CLI is automatically set once you send a request and everything  
is set back to initial values once that request ends.

Exactly which event is the problem here?

HS

------------------------------------------------------------------------------
Achieve Improved Network Security with IP and DNS Reputation.
Defend against bad network traffic, including botnets, malware, 
phishing sites, and compromised hosts - saving your company time, 
money, and embarrassment.   Learn More! 
(Continue reading)

Iain Hibbert | 3 Nov 12:41 2010
Picon

(no subject)

>From 3f4cbdd119e4c7f574f006845c8645ac29cd85f7 Mon Sep 17 00:00:00 2001
From: Iain Hibbert <plunky <at> rya-online.net>
Date: Tue, 26 Oct 2010 14:10:41 +0100
Subject: [PATCH] always return a static string

OBEX_ResponseToString() documentation says that it returns a static
string or NULL on error. This is not quite correct as the code does
never return NULL, and moreover it will be easier to use if that is
part of the API. Make it so.
---
 lib/obex.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/lib/obex.c b/lib/obex.c
index 29723ec..4704e5d 100644
--- a/lib/obex.c
+++ b/lib/obex.c
 <at>  <at>  -841,9 +841,11  <at>  <at>  int CALLAPI OBEX_ObjectGetCommand(obex_t *self, obex_object_t *object)
 /**
 	Return a human understandable string from a response-code.
 	\param rsp Response code.
-	\return static response code string, NULL on error
+	\return static response code string

-	The returned char must not be freed. Returns NULL on error.
+	The returned string must not be freed.
+	If the response code is unknown, the string "Unknown response" will
+	be returned.
  */
 LIB_SYMBOL
(Continue reading)

max ulidtko | 3 Nov 18:48 2010
Picon

Re: [PATCH] obex_client state transition fixes

Luiz Augusto von Dentz wrote:
>Actually mode has been separated from state since some time, I don't
>think this patch even apply upstream anymore. But I agree that
>switching to server mode is a bit odd, but maybe there is a reason for
>that.

Oh gods. Switched to 1.4 to test some app which used an older ABI and
forgot to switch back on master. Although updating the patch seems
trivial.

Hendrik Sattler wrote:
>Indeed there is. MODE_SRV is also used as initial value for the mode  
>field. Unless you take that obex_t and register as server with it, the
>MODE_SRV does nothing (there is no listening FD so nothing comes in  
>this route). MODE_CLI is automatically set once you send a request and
>everything is set back to initial values once that request ends.

Those nifty details aren't good; the constants should have clear and
not-obscure, not-confusing meaning and usage, shouldn't they? Or else
the development may become a nightmare: one will be obligated to know
all the internal machinery in detail to be able to use it.

>
>Exactly which event is the problem here?

The problem shows up e.g. in the test client; the event OBEX_EV_REQDONE
gets handled in wrong way because of client having
mode==OBEX_MODE_SERVER. I used the following test scenario:
1) Launch `apps/obex_test/obex_test -i` and make it listen on tcp
loopback
(Continue reading)

Hendrik Sattler | 3 Nov 21:40 2010
Picon

Re: [PATCH] obex_client state transition fixes

Am Mittwoch 03 November 2010, 18:48:58 schrieb max ulidtko:
> Hendrik Sattler wrote:
> >Indeed there is. MODE_SRV is also used as initial value for the mode
> >field. Unless you take that obex_t and register as server with it, the
> >MODE_SRV does nothing (there is no listening FD so nothing comes in
> >this route). MODE_CLI is automatically set once you send a request and
> >everything is set back to initial values once that request ends.
> 
> Those nifty details aren't good; the constants should have clear and
> not-obscure, not-confusing meaning and usage, shouldn't they? Or else
> the development may become a nightmare: one will be obligated to know
> all the internal machinery in detail to be able to use it.

There are more scary places.

> >Exactly which event is the problem here?
> 
> The problem shows up e.g. in the test client; the event OBEX_EV_REQDONE
> gets handled in wrong way because of client having
> mode==OBEX_MODE_SERVER. I used the following test scenario:
> 1) Launch `apps/obex_test/obex_test -i` and make it listen on tcp
> loopback
> 2) Launch another instance and make it connect to the server
> Here is log of such a launch (client side):

The commit that changes that behaviour was:
commit 356f9c1e2bcf91377b79957e3097ef74147dd808
Author: Marcel Holtmann <marcel <at> holtmann.org>
Date:   Mon Aug 28 12:56:36 2006 +0000

(Continue reading)

Christian Zuckschwerdt | 3 Nov 22:11 2010

Re: [PATCH] obex_client state transition fixes

Hi,

Am 03.11.2010 um 21:40 schrieb Hendrik Sattler:

>> P.S. Could the list moderator please approve my subscription? I don't
>> receive new messages, have to refresh mailarchive in browser.
> 
> Ask Zany or Marcel directly.

I'm reading the list and already solved the problem with Max off-list :)

regards,
Christian

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
hui li | 8 Nov 07:48 2010
Picon

brach support obex over l2cap and SRM

hi, all, since OBEX14 has released for a long time, I`d like to port
it on obex-data-server and openobex. What do you think about it?
As ods is closely related to blueman and openobex, the modification
will inevitably include blueman and openobex changes. Should I submit
patches in a branch? Please kindly give me your any suggestion.
Thanks.

I`ve created 3 repositories in github.com:
git://github.com/namili/blueman.git
git://github.com/namili/obex-data-server.git
git://github.com/namili/openobex.git

The 3 modified projects are based on some older version. They can be
built and run well.Currently support obex over l2cap and SRM.
I`ll port them on current version later.
Please kindly let me know if you have any question. Thank.

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
Iain Hibbert | 8 Nov 08:28 2010
Picon

Re: brach support obex over l2cap and SRM

On Mon, 8 Nov 2010, hui li wrote:

> hi, all, since OBEX14 has released for a long time

Hi, do you have a reference for this specification?

Google finds nothing about OBEX14 except your mail..

regards,
iain

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev

Gmane