obex-data-server vs. Sony Ericsson T610
Thomas Schwinge
Beware with me, I've never used bluetooth before :-). But now, a friend
of mine gave me this Sony Ericsson T610 to finally replace my good ol'
Siemens M 50, and I decided to give this bluetooth thingy a try.
I'm on Ubuntu jaunty, by the way. I installed blueman from the PPA
repository, and the phone is detected fine, and using some old TCL/TK
OBEX program (obextool, I think) I was able to browse and download the
few stored files (pictures in shabby quality) from the phone. However,
when I try to use blueman to browse the phone, it fails with ``Could not
get service channel''. Sending a file to the phone does work. Also,
accessing the files with FUSE obexfs does work.
I traced this error message down to obex-data-server. I came up with the
attached hack to get it working, based on the current subversion trunk
revision, obviously this is not acceptable as-is. I have no substantial
idea about bluetooth and all the protocols and services it involves, so
I'd need help on solving this properly. I also attached debug output
from the unpatched and the patched version.
Regards,
Thomas
Tadas Dailyda
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFKGT5ismqaiQAHQR4RAv75AJ9GlcuraOyGmk4fECfzrKWQksV1dgCdFy5c
Oo6ieGn9nDAQagJyf0UQhi0=
=b8Vo
-----END PGP SIGNATURE-----
Thomas Schwinge
On Sun, May 24, 2009 at 03:50:27PM +0200, Tadas Dailyda wrote:
> Please run 'sdptool browse <BT_ADDR>' in terminal and post the output here.
Browsing 00:0F:DE:69:05:03 ...
Service Name: Dial-up Networking
Service RecHandle: 0x10000
Service Class ID List:
"Dialup Networking" (0x1103)
"Generic Networking" (0x1201)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Service Name: Voice gateway
Service RecHandle: 0x10002
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Profile Descriptor List:
"Headset" (0x1108)
Version: 0x0100
Service Name: Serial Port 1
Service RecHandle: 0x10003
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 4
Service Name: Serial Port 2
Service RecHandle: 0x10004
Service Class ID List:
"Serial Port" (0x1101)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 5
Service Name: OBEX Object Push
Service RecHandle: 0x10005
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 10
"OBEX" (0x0008)
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
Service Name: IrMC Synchronization
Service RecHandle: 0x10006
Service Class ID List:
"IrMC Sync" (0x1104)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 11
"OBEX" (0x0008)
Profile Descriptor List:
"IrMC Sync" (0x1104)
Version: 0x0100
Service Name: HF Voice gateway
Service RecHandle: 0x10007
Service Class ID List:
"Handsfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 6
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0100
Service Name: OBEX Basic Imaging
Service RecHandle: 0x1000b
Service Class ID List:
"Imaging Responder" (0x111b)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 15
"OBEX" (0x0008)
Profile Descriptor List:
"Imaging" (0x111a)
Version: 0x0100
Service Name: OBEX File Transfer
Service RecHandle: 0x1000f
Service Class ID List:
"OBEX File Transfer" (0x1106)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 7
"OBEX" (0x0008)
Profile Descriptor List:
"OBEX File Transfer" (0x1106)
Version: 0x0100
> We have to see what services the particular device has and what is the UUID
> of the service with RFCOMM channel 10 which seems to work for you.
Hard-coding that to channel 7 also keeps it working, by the way.
Regards,
Thomas
Tadas Dailyda
checking what channel ods actually gets with such code:
channel = sdp_get_proto_port (protos, RFCOMM_UUID); //as is
g_message ("channel: %d", channel); //add
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFKGVUlsmqaiQAHQR4RApJ7AJ9N+K0AwkX+jTojqpHZNsJxNHli9ACfWMx0
> vb5hYYog3vXn+4k1JrNVjAg=
> =mLfB
> -----END PGP SIGNATURE-----
>
Thomas Schwinge
On Sun, May 24, 2009 at 04:39:17PM +0200, Tadas Dailyda wrote:
> Looking at the sdptool output, it seems that ods should work fine. Try
> checking what channel ods actually gets with such code:
>
> channel = sdp_get_proto_port (protos, RFCOMM_UUID); //as is
> g_message ("channel: %d", channel); //add
This yields channel 0, but I guess that this is due to protos not being
initialized, as I have to comment that out, for not to trigger the
``Could not get service channel'' error. So, might the problem then in
fact be with sdp_get_access_protos?
static void
sdp_get_channel (sdp_record_t *sdp_record,
OdsBluezCancellable *cb_data)
{
OdsBluezFunc cb = cb_data->cb;
GError *error = NULL;
sdp_list_t *protos = NULL;
gint channel = -1;
#if 0
g_message ("getting RFCOMM channel");
/* get channel for this service */
if (sdp_get_access_protos (sdp_record, &protos) != 0) {
g_set_error (&error, ODS_ERROR, ODS_ERROR_FAILED,
"Could not get service channel");
goto err;
}
channel = sdp_get_proto_port (protos, RFCOMM_UUID);
#else
channel = 10;
#endif
cb_data->channel = channel;
Regards,
Thomas
Tadas Dailyda
SUITE service, it finds some records. That shouldn't happen. BTW,
what's your bluez version?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFKGWEIsmqaiQAHQR4RAoAXAKCtv6A2/6PvQhH0q8c7hVHxW995kQCgw1wl
> dCefYqMsLt4j4JwIOpmHRxY=
> =moST
> -----END PGP SIGNATURE-----
>
>
Tadas Dailyda
sdp records better.
Thomas Schwinge
On Sun, May 24, 2009 at 05:14:51PM +0200, Tadas Dailyda wrote:
> Ok, that's quite strange. It seems that when ods searches for NOKIA PC
> SUITE service, it finds some records. That shouldn't happen. BTW,
> what's your bluez version?
That is bluez version 4.39-0ubuntu1.
Based on your diagnostics, here is another hack to make it work to me;
channel 7 is selected then.
Index: src/ods-bluez.c
===================================================================
--- src/ods-bluez.c (Revision 2836)
+++ src/ods-bluez.c (Arbeitskopie)
@@ -188,6 +188,7 @@
}
channel = sdp_get_proto_port (protos, RFCOMM_UUID);
+ g_message ("channel: %d", channel);
cb_data->channel = channel;
if (cb_data->uuid.value.uuid16 == IMAGING_RESPONDER_SVCLASS_ID) {
@@ -453,11 +454,13 @@
*/
/* if FTP was requested, use NOKIAFTP instead,
* if it isn't found we retreat to FTP in get_remote_service_handles_cb */
+#if 0
if (uuid->value.uuid16 == OBEX_FILETRANS_SVCLASS_ID ||
!memcmp(&uuid->value.uuid128, OBEX_FTP_UUID, sizeof(uint128_t))) {
g_message ("FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid");
sdp_uuid128_create (&cb_data->uuid, OBEX_NOKIAFTP_UUID);
} else
+#endif
memcpy (&cb_data->uuid, uuid, sizeof (uuid_t));
} else {
Regards,
Thomas
Thomas Schwinge
On Sun, May 24, 2009 at 05:25:58PM +0200, Tadas Dailyda wrote:
> Also run 'sdptool browse --tree <BD_ADDR>' so that I can analyze the
> sdp records better.
Browsing 00:0F:DE:69:05:03 ...
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10000
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1103 - DialupNetworking (DUN)
UUID16 : 0x1201 - GenericNetworking
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x1
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x1103 - DialupNetworking (DUN)
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 44 69 61 6c 2d 75 70 20 4e 65 74 77 6f 72 6b 69 6e 67 00
Attribute Identifier : 0x305
Integer : 0x0
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10002
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1112 - HeadsetAudioGateway
UUID16 : 0x1203 - GenericAudio
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x3
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x1108 - Headset
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 56 6f 69 63 65 20 67 61 74 65 77 61 79 00
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10003
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1101 - SerialPort
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x4
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x100
Data : 53 65 72 69 61 6c 20 50 6f 72 74 20 31 00
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10004
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1101 - SerialPort
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x5
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x100
Data : 53 65 72 69 61 6c 20 50 6f 72 74 20 32 00
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10005
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1105 - OBEXObjectPush
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0xa
Data Sequence
UUID16 : 0x0008 - OBEX
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x1105 - OBEXObjectPush
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 4f 42 45 58 20 4f 62 6a 65 63 74 20 50 75 73 68 00
Attribute Identifier : 0x303
Data Sequence
Integer : 0x1
Integer : 0x3
Integer : 0x5
Integer : 0xff
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10006
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1104 - IrMCSync
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0xb
Data Sequence
UUID16 : 0x0008 - OBEX
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x1104 - IrMCSync
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 49 72 4d 43 20 53 79 6e 63 68 72 6f 6e 69 7a 61 74 69 6f 6e 00
Attribute Identifier : 0x301
Data Sequence
Integer : 0x1
Integer : 0x3
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x10007
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x111f - HandsfreeAudioGateway
UUID16 : 0x1203 - GenericAudio
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x6
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x111e - Handsfree
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 48 46 20 56 6f 69 63 65 20 67 61 74 65 77 61 79 00
Attribute Identifier : 0x301
Integer : 0x1
Attribute Identifier : 0x311
Integer : 0x17
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x1000b
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x111b - ImagingResponder (BIP)
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0xf
Data Sequence
UUID16 : 0x0008 - OBEX
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x111a - Imaging (BIP)
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 4f 42 45 58 20 42 61 73 69 63 20 49 6d 61 67 69 6e 67 00
Attribute Identifier : 0x310
Integer : 0x1
Attribute Identifier : 0x311
Integer : 0x1
Attribute Identifier : 0x312
Integer : 0xb
Attribute Identifier : 0x313
Integer : 0xc3500
Attribute Identifier : 0x0 - ServiceRecordHandle
Integer : 0x1000f
Attribute Identifier : 0x1 - ServiceClassIDList
Data Sequence
UUID16 : 0x1106 - OBEXFileTransfer
Attribute Identifier : 0x4 - ProtocolDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x0100 - L2CAP
Data Sequence
UUID16 : 0x0003 - RFCOMM
Channel/Port (Integer) : 0x7
Data Sequence
UUID16 : 0x0008 - OBEX
Attribute Identifier : 0x5 - BrowseGroupList
Data Sequence
UUID16 : 0x1002 - PublicBrowseGroup
Attribute Identifier : 0x9 - BluetoothProfileDescriptorList
Data Sequence
Data Sequence
UUID16 : 0x1106 - OBEXFileTransfer
Version (Integer) : 0x100
Attribute Identifier : 0x100
Data : 4f 42 45 58 20 46 69 6c 65 20 54 72 61 6e 73 66 65 72 00
Regards,
Thomas
Tadas Dailyda
added one line in ods-bluez.c. Maybe it will help us detect which
record is mistaken for Nokia PC suite service.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFKGWk4smqaiQAHQR4RAvOhAJ448JGO8I5vGh1t8w2P8bv1N6UYMgCfUnAn
> dxZ+SPAXbi2wlJ/Xi5IVj5M=
> =DpcL
> -----END PGP SIGNATURE-----
>
>
Thomas Schwinge
On Sun, May 24, 2009 at 06:16:02PM +0200, Tadas Dailyda wrote:
> Update to svn version and post ods output of connection attempt. I
> added one line in ods-bluez.c. Maybe it will help us detect which
> record is mistaken for Nokia PC suite service.
Unfortunately it doesn't seem so:
** Message: obex-data-server 0.4.4
** Message: Using Session bus
** Message: server socket created
** Message: Server created by: :1.38
** Message: server socket created
** Message: Server created by: :1.38
** (obex-data-server:23473): WARNING **: Server path: /home/thomas
** (obex-data-server:23473): WARNING **: Server path: /home/thomas
** Message: Parsed[0]: ftp
** Message: FTP uuid selected, first checking for Nokia OBEX PC Suite Services uuid
** Message: Connected SDP session
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search process
** Message: SDP search completed
** Message: getting RFCOMM channel
** Message: session closed
** Message: Removing listened DBUS name :1.155 (object: /org/openobex/session0)
** Message: Removed from listened DBUS names list
Regards,
Thomas
Petit Eric
force chanel ?
something like obexftp -b <dev> -B <Chanel> ?
2009/5/24 Thomas Schwinge <tsch...@googlemail.com>:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFKGXaqsmqaiQAHQR4RAosCAJ9m6Gh0LNE0I3n9Vw1aHAbg2k5NcwCglUo0
> 70UJQvZGZ+P+OhI5y6rHu1I=
> =JzAT
> -----END PGP SIGNATURE-----
>
>
--
Cordially.
Small Eric Quotations of the days:
---------------------------------------------------------------------------
If one day one reproaches you that your work is not a work of
professional, say you that:
Amateurs built the arch of Noah, and professionals the Titanic.
---------------------------------------------------------------------------
Few people are done for independence, it is the privilege of the powerful ones.
---------------------------------------------------------------------------
No key was wounded during the drafting of this message.
Tadas Dailyda
only usable in cases of predetermined environments. Furthermore, this
might be used only for saving time that SDP record search takes and
not for general usage.
Petit Eric
> The applications using ods can force a specific channel but that's
> only usable in cases of predetermined environments. Furthermore, this
> might be used only for saving time that SDP record search takes and
> not for general usage.
i can rember device chanel and don't wait for discovery :D
Tadas Dailyda
randomizing OBEX_NOKIAFTP_UUID in ods-common.h just to see if this bug
is triggered by specific bits. I hope we can solve this because it's
quite major bug :)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
Tadas Dailyda
Maybe we could put this discussion into bugtracker at
http://bugs.muiline.com because it's really difficult to work this
way.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>