Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

BtOBEX_TransportConnect, detect user rejects?

Help
2008-11-20
2013-05-01
  • I'm writing some software in C with OpenObex + BlueZ on Linux (Ubuntu 8.10) to push files via bluetooth to mobile phones. So far I have figured out that different phones handle Object Push differently in regards when the user will get the question to accept or reject the incomming file.

    Sony Ericsson W910i will allow the BtOBEX_TransportConnect and OBEX_CMD_CONNECT, and will ask user at OBEX_CMD_PUT. This is all good and no problems.

    Then we have a whole bunch of phones, tested on a couple of Nokia and Samsung, that will ask the user to accept/reject already at BtOBEX_TransportConnect. Now to the problem...

    BtOBEX_TransportConnect will only return -1 as indication of error, hence I can't decide if (1) the user rejected the request, (2) there was a timeout because the user did not see the accept-dialog in time, or (3) it was not possible to connect to the device at all.

    Is there a way to detect this? Is there a simple solution or do I have to do this with a custom transport, OBEX_RegisterCTransport (and is it even possible then)?

    Thanks!

     
    • Bolick
      Bolick
      2008-11-22

      Hello!
      I'm involved in the same process. So I have a little experience on this topic :)

      It's  important for me to distinguish 2 different events: user rejected my attempt to establish connection and timeout (user has no idea of my bluetooth activity).

      My experience told me, that BtObex has different states for this events. And you can easily find it in "ussp-push" debug output:

      TIMEOUT

      ./ussp-push --debug --timeo 15   11:11:11:11:11:11@1 lfile rfile
      pushing file lfile
      name=rfile, size=56658
      __obex_connect: client_context_t = 0x6a988
      Registered transport
      Set user data
      Created new objext
      cobex_write
      Local device 00:00:00:00:00:00
      Remote device 11:11:11:11:11:11 (1)
      connect timeout
      cobex_init returned -1
      obex_event: client_context_t = 0x6a988
      Made some progress...
      Started a new request
      cobex_handle_input
      Error while doing OBEX_HandleInput()
      Connection return code: -1, id: 0
      __obex_connect: error=-1
      Unable to connect to the server
      Error

      REJECT

      ./ussp-push --debug --timeo 15   11:11:11:11:11:11@1 lfile rfile
      pushing file lfile
      name=rfile, size=56658
      __obex_connect: client_context_t = 0x6a988
      Registered transport
      Set user data
      Created new objext
      cobex_write
      Local device 00:00:00:00:00:00
      Remote device 11:11:11:11:11:11 (1)
      Wrote 0 fragment
      Write error: Transport endpoint is not connected
      obex_event: client_context_t = 0x6a988
      cobex_disconnect
      Link broken!
      Started a new request
      cobex_close
      __obex_connect: error=-2
      Unable to connect to the server
      Error

      As you can see, there are 2 different errors: -1 and -2.

      But, what's interesting, just few minutes ago I've found that there's very strange dependence: if I set --timeo > 30 (set in seconds), I have the same answer for both situations: error -2.

      Thanks

       
    • I've made similar findings, though not using ussp-push, but hcidump. (only including from the difference).

      REJECT:
      ...
      > ACL data: handle 42 flags 0x02 dlen 8
          L2CAP(d): cid 0x0040 len 4 [psm 3]
            RFCOMM(s): DM: cr 1 dlci 18 pf 1 ilen 0 fcs 0x18
      < ACL data: handle 42 flags 0x02 dlen 8
          L2CAP(d): cid 0x0040 len 4 [psm 3]
            RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
      < ACL data: handle 42 flags 0x02 dlen 12
          L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
      ...

      TIMEOUT:
      ...
      < ACL data: handle 42 flags 0x02 dlen 8
          L2CAP(d): cid 0x0040 len 4 [psm 3]
            RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3
      < ACL data: handle 42 flags 0x02 dlen 8
          L2CAP(d): cid 0x0040 len 4 [psm 3]
            RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
      < ACL data: handle 42 flags 0x02 dlen 12
          L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
      ...

      So the question is how to get this info from the OpenObex...