Samsung SGH-D600: Request not successfull: 83

View: New views
4 Messages — Rating Filter:   Alert me  

Samsung SGH-D600: Request not successfull: 83

by Markus Wagner-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi List, hi devs!

I just followed the http://www.opensync.org/wiki/syncml-guide SyncML Guide and
I am trying to sync the phone via the syncml-obex-client plugin.

When trying to sync, I get the following:

markus@swordfish ~/opensync/log $ msynctool --sync syncmlfile
Synchronizing group "syncmlfile"
The previous synchronization was unclean. Slow-syncing
Member 1 of type file-sync just connected
Member 2 of type syncml-obex-client had an error while connecting: Request not
successfull: 83
Member 1 of type file-sync just disconnected
All clients have disconnected
The sync failed: Unable to connect one of the members
Error synchronizing: Unable to connect one of the members

This is my client configuration:

<config>
        <bluetooth_address>00:15:B9:13:26:36</bluetooth_address>
        <bluetooth_channel>6</bluetooth_channel>
        <interface>0</interface>
        <identifier></identifier>
        <version>1</version>
        <wbxml>1</wbxml>
        <username></username>
        <password></password>
        <type>2</type>
        <usestringtable>0</usestringtable>
        <onlyreplace>0</onlyreplace>
        <recvLimit>10000</recvLimit>
        <maxObjSize></maxObjSize>
        <contact_db>addressbook</contact_db>
        <calendar_db>calendar</calendar_db>
        <note_db>tasks</note_db>
</config>

In earlier posts I read, that I have to set the channel to the "obex syncml
channel" - due to this 'sdptool browse', am I using the right channel??

Thanks for hints on this error!

Markus

PS: Playing around with version only brings unknown format with 2; wbxml
changing; maxObjSize doesnt make a difference either...

=========[ sdptool browse]=========================
markus@swordfish ~/opensync/log $ sdptool browse
Inquiring ...
Browsing 00:15:B9:13:26:36 ...
Service Name: WBTEXT
Service RecHandle: 0x10000
Service Class ID List:
  "Error: This is UUID-128" (0xdb1d8f12-95f3-402c-9b97-bc504c9a55c4)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Error: This is UUID-128" (0x1cdb1d8f-1295-f340-2c9b-97bc504c9a55)
    Version: 0x0100

Service Name: Serial Port
Service RecHandle: 0x10001
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2
Profile Descriptor List:
  "Serial Port" (0x1101)
    Version: 0x0100

Service Name: Dial-up Networking
Service RecHandle: 0x10002
Service Class ID List:
  "Dialup Networking" (0x1103)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100

Service Name: Voice GW
Service RecHandle: 0x10003
Service Class ID List:
  "Headset Audio Gateway" (0x1112)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 4
Profile Descriptor List:
  "Headset" (0x1108)
    Version: 0x0100

Service Name: Voice GW
Service RecHandle: 0x10004
Service Class ID List:
  "Handfree Audio Gateway" (0x111f)
  "Generic Audio" (0x1203)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 5
Profile Descriptor List:
  "Handsfree" (0x111e)
    Version: 0x0101

Service Name: Advanced audio source
Service RecHandle: 0x10005
Service Class ID List:
  "Audio Source" (0x110a)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 25
  "AVDTP" (0x0019)
    uint16: 0x100
Profile Descriptor List:
  "Advanced Audio" (0x110d)
    Version: 0x0100

Service RecHandle: 0x10006
Service Class ID List:
  "AV Remote Target" (0x110c)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 23
  "AVCTP" (0x0017)
    uint16: 0x100
Profile Descriptor List:
  "AV Remote" (0x110e)
    Version: 0x0100

Service Name: OBEX File Transfer
Service RecHandle: 0x10007
Service Class ID List:
  "OBEX File Transfer" (0x1106)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 6
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX File Transfer" (0x1106)
    Version: 0x0100

Service Name: Object Push
Service RecHandle: 0x10008
Service Class ID List:
  "OBEX Object Push" (0x1105)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 7
  "OBEX" (0x0008)
Profile Descriptor List:
  "OBEX Object Push" (0x1105)
    Version: 0x0100



_______________________________________________
Opensync-users mailing list
Opensync-users@...
https://lists.sourceforge.net/lists/listinfo/opensync-users

log.tar.gz (8K) Download Attachment

Re: Samsung SGH-D600: Request not successfull: 83

by Stefan Schmidt-9 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hallo,

lately I did some experiments on using opensync with the Samsung SGH-D500,
which I suppose uses the same syncml protocol as your mobile.

According to http://www.traud.de/gsm/samsung.htm , the device is capable of
SyncML over Obex, but as I understood you can't use Obex over Bluetooth
directly to talk syncml. Rather you need to start a syncml-session via the
Bluetooth Dialup-Profile (maybe also IRDA or cable connection possible) by
giving the AT-Command
AT+CPROT=0


I tried hacking the necessary changes for such a connection into libsyncml and
the syncml-plugin of opensync, but I did not succeed in exchanging data. I
got a CONNECT message from the phone and then some obex failures (which I
have not been able to interpret so far).

Due to lack of time I have not yet continued to try some harder, but I'm still
very interested in getting the phone synchronized... Let me know if you'd
like my piece of code as a starting point.

With kind regards,
Stefan Schmidt

Am Dienstag, 20. Juni 2006 20:01 schrieb Markus Wagner:

> Hi List, hi devs!
>
> I just followed the http://www.opensync.org/wiki/syncml-guide SyncML Guide
> and I am trying to sync the phone via the syncml-obex-client plugin.
>
> When trying to sync, I get the following:
>
> markus@swordfish ~/opensync/log $ msynctool --sync syncmlfile
> Synchronizing group "syncmlfile"
> The previous synchronization was unclean. Slow-syncing
> Member 1 of type file-sync just connected
> Member 2 of type syncml-obex-client had an error while connecting: Request
> not successfull: 83
> Member 1 of type file-sync just disconnected
> All clients have disconnected
> The sync failed: Unable to connect one of the members
> Error synchronizing: Unable to connect one of the members
[...]


_______________________________________________
Opensync-users mailing list
Opensync-users@...
https://lists.sourceforge.net/lists/listinfo/opensync-users

Re: Samsung SGH-D600: Request not successfull: 83

by Martin Schulze-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I tried to get the very same phone working with Opensync some time ago.
After introducing a lot of hacks, I got some communication working but I
couldn't proceed due to lack of time.

There are several issues with the SGH-D600:

1) Like Stefan reported, an AT-Command has to be sent before a
syncml-session can be started ("AT+CPROT=0\r" did the job for me).

2) The Teleca client (which the SGH-D600 is using internally) has some
non-standard behaviour in the OBEX protocol. If I remember correctly, it
requires an empty put final OBEX packet which is incompatible with e.g.
with Nokia mobile phones.
My solution was to add an empty OBEX header (type OBEX_HDR_EMPTY) to the
OBEX packet in function smlTransportObexClientSend().

3) Only syncml version 1.1 is supported. That means that the
syncronization cannot be triggered by sending a SAN-Notification.
Instead, a server alert (type SML_ALERT_TWO_WAY_BY_SERVER) needs to be
sent in client_connect() (syncml-plugin.c).
I don't know the current status of the code base, but back in February I
needed to change the whole logic of how a sycml session is started in
opensync.

4) Furthermore, there are some weird restrictions in the xml protocol.
Some headers are needed or forbidden - I don't remember the details and
gave up somewhere at that point.

I'm sorry that I never managed to get a patch ready. The problem is that
basically all the changes are work-arounds for this obscure
OBEX/syncml-client. As such they must only get active if this client is
identified. In order to avoid contamination of the codebase with a bunch
of hacks, opensync needs some mechanisms to guess the sycml client and
to activate such workarounds on demand.

Regards,

  Martin


Am Dienstag, den 20.06.2006, 22:41 +0200 schrieb Stefan Schmidt:

> Hallo,
>
> lately I did some experiments on using opensync with the Samsung SGH-D500,
> which I suppose uses the same syncml protocol as your mobile.
>
> According to http://www.traud.de/gsm/samsung.htm , the device is capable of
> SyncML over Obex, but as I understood you can't use Obex over Bluetooth
> directly to talk syncml. Rather you need to start a syncml-session via the
> Bluetooth Dialup-Profile (maybe also IRDA or cable connection possible) by
> giving the AT-Command
> AT+CPROT=0
>
>
> I tried hacking the necessary changes for such a connection into libsyncml and
> the syncml-plugin of opensync, but I did not succeed in exchanging data. I
> got a CONNECT message from the phone and then some obex failures (which I
> have not been able to interpret so far).
>
> Due to lack of time I have not yet continued to try some harder, but I'm still
> very interested in getting the phone synchronized... Let me know if you'd
> like my piece of code as a starting point.
>
> With kind regards,
> Stefan Schmidt
>
> Am Dienstag, 20. Juni 2006 20:01 schrieb Markus Wagner:
> > Hi List, hi devs!
> >
> > I just followed the http://www.opensync.org/wiki/syncml-guide SyncML Guide
> > and I am trying to sync the phone via the syncml-obex-client plugin.
> >
> > When trying to sync, I get the following:
> >
> > markus@swordfish ~/opensync/log $ msynctool --sync syncmlfile
> > Synchronizing group "syncmlfile"
> > The previous synchronization was unclean. Slow-syncing
> > Member 1 of type file-sync just connected
> > Member 2 of type syncml-obex-client had an error while connecting: Request
> > not successfull: 83
> > Member 1 of type file-sync just disconnected
> > All clients have disconnected
> > The sync failed: Unable to connect one of the members
> > Error synchronizing: Unable to connect one of the members
> [...]
>
>
> _______________________________________________
> Opensync-users mailing list
> Opensync-users@...
> https://lists.sourceforge.net/lists/listinfo/opensync-users



_______________________________________________
Opensync-users mailing list
Opensync-users@...
https://lists.sourceforge.net/lists/listinfo/opensync-users

Re: Samsung SGH-D600: Request not successfull: 83

by Markus Wagner-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Wednesday 21 June 2006 00:01, Martin Schulze wrote:
> I tried to get the very same phone working with Opensync some time ago.
> After introducing a lot of hacks, I got some communication working but I
> couldn't proceed due to lack of time.
>
> There are several issues with the SGH-D600:
>
> 1) Like Stefan reported, an AT-Command has to be sent before a
> syncml-session can be started ("AT+CPROT=0\r" did the job for me).

Hm, i guess that could be realized, though communication on another bt channel
(serial chat?!) has to be done in advance...

> [...]
> 3) Only syncml version 1.1 is supported. That means that the
> syncronization cannot be triggered by sending a SAN-Notification.
> Instead, a server alert (type SML_ALERT_TWO_WAY_BY_SERVER) needs to be
> sent in client_connect() (syncml-plugin.c).
> I don't know the current status of the code base, but back in February I
> needed to change the whole logic of how a sycml session is started in
> opensync.

Rumors are, that 1.1 is now in the code base and ready for testing.

> 4) Furthermore, there are some weird restrictions in the xml protocol.
> Some headers are needed or forbidden - I don't remember the details and
> gave up somewhere at that point.

> I'm sorry that I never managed to get a patch ready. The problem is that
> basically all the changes are work-arounds for this obscure
> OBEX/syncml-client. As such they must only get active if this client is
> identified. In order to avoid contamination of the codebase with a bunch
> of hacks, opensync needs some mechanisms to guess the sycml client and
> to activate such workarounds on demand.

Unfortunately I am quite limited on time, too. Furthermore I am not very
talented when it comes to Ccoding or/and understanding what already has been
done and how obex,bt,syncml and all play together. (Easy readings to get
started anywhere?!). Maybe if this knowledge is there, I cannot hold back and
start hacking :-p
But in anycase; I'd be willing to test, give feedbacks and debugs...

BTW: I find the idea of a pluggable "bug-work-around" mechanism very charming.

m


_______________________________________________
Opensync-users mailing list
Opensync-users@...
https://lists.sourceforge.net/lists/listinfo/opensync-users