Description of problem:

OpenObex attempts to listen/connect on incorrect SDP channel numbers.
obex_test and gnome-obex-server both behave similarly.

How reproducible:
100%

Steps to Reproduce:
1. strace obex_test -b <bdaddr> <channel>
  ( my example is '00:80:37:95:CD:02 10')

Actual results:

socket(0x1f /* PF_??? */, SOCK_STREAM, 3) = 3
bind(3, {sa_family=0x1f /* AF_??? */,
sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) = 0
connect(3, {sa_family=0x1f /* AF_??? */,
sa_data="\2\315\2257\200\0\0\0\0\0\0\0\0\0"}, 10) = -1 EINVAL (Invalid
argument)
close(3)                                = 0
write(1, "Transport connect error! (Blueto"..., 37Transport connect
error! (Bluetooth)



Expected results (i.e. what happens on i386):
socket(0x1f /* PF_??? */, SOCK_STREAM, 3) = 3
bind(3, {sa_family=0x1f /* AF_??? */,
sa_data="\0\0\0\0\0\0\0\0\0\0\0\0\0\0"}, 10) = 0
connect(3, {sa_family=0x1f /* AF_??? */,
sa_data="\2\315\2257\200\0\n\0\0\0\0\0\0\0"}, 10) = 0
write(3, "\200\0\20\21\0\4\0J\0\tLinux\0", 16) = 16
select(4, [3], NULL, NULL, {10, 0})     = 1 (in [3], left {10, 0})
read(3, "\240\0\7", 3)                  = 3
read(3, "\20\0\2\0", 4)                 = 4
write(1, "Connect OK!\n", 12Connect OK!
)           = 12


Additional info:

Probably an endianness bug.