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

Close

obexftp segfaults/doesn't work with SF65

Help
2005-10-14
2013-05-01
  • Chris Le Sueur
    Chris Le Sueur
    2005-10-14

    First off, I know it's not listed as supported, but the chaps over at scmxx said it should work with OBEX.

    What originally happened was a segfault when it tried to connect to the phone. I found this was due to answer in do_at_cmd() (bfb_io.c) being "\r\n\r\n" so you ended up with an answer_size of -1 being passed to strncpy. I fixed that by replacing the characters with null bytes, (incidentally, this bug probably needs looking into anyway) so answer_size wasn't -1.
    Although this solved the segfault, what ends up happening is the connection to the phone timing out. It appears that obexftp disconnects the phone, because if you try then to use scmxx it doesn't work, but before using obexftp it does, and if you unplug/plug in the USB/Serial cable, the "connected" screen doesn't show up.

    With SCMxx I could grab SMS messages, but not do any other file transfer. The phone is, according to the scmxx people, not actually siemens, but rebranded. I can't find any information relating to this, though, but they say that it doesn't suport AT^S commands, and uses a charset called "IRA," indicating this.

    I'm connecting using the serial port, with a usb cable, and the device it's mapped to is /dev/ttyUSB0.

    Thanks!

     
    • I remember fixing that do_at_cmd problem a while ago. Can you check again with the developer snapshot 0.10.8?

      IrDA and BT should work. TTY will most likely not work if its not an original Siemens phone. You can check that with a terminal emulator: type AT^SIFS and AT^SBFB? or AT^SBFB=?

       
    • Chris Le Sueur
      Chris Le Sueur
      2005-10-14

      I'll update to the snapshot when I get time, which may or may not be soon :)

      Unfortunately, I don't have an IR receiver dongle for my PC, unless the Mindstorms thing will work... The SF65 doesn't have bluetooth, so that's a no go. My rusty knowledge tells me that IrDA is a protocol in its own right, and that the TTY uses some other thing?

      I couldn't get any meaningful output from the TTY device; it just spits characters at me, mostly \n.
      You don't happen to know a reliable way of finding out what phone the SF65 really is, do you? Perhaps there's some other software for it... It would indeed be irritating if there was no way to get my tacky photos off there, and suchlike!

       
    • Chris Le Sueur
      Chris Le Sueur
      2005-10-14

      Update: tried 0.10.8 - no segfault, but a "transport type unknown" I assume because it's not Siemens in some way. As I said, info on this imposter is not forthcoming, anything you have is most welcome.

       
    • Try to vary the speed (baud-rate) of the terminal emulator (e.g. miniterm) and send:
      AT<enter>
      Until you get an OK. Then try each of
      AT+GMI
      AT+GMM
      AT+GMR
      AT+GSN
      ATI9
      That will at least help to identify the phone.

       
      • Chris Le Sueur
        Chris Le Sueur
        2005-10-15

        baud rate 19200 works. The AT+G* commands identify it as a Siemens SF65, as per the branding, but AT^S* returns error. I tried pointing the phone at the mindstorms IR tower and using the IrDA function, but nothing happens on the phone, and running obexftp doesn't work.

         
    • Chris Le Sueur
      Chris Le Sueur
      2005-10-15

      OK, I fired up windows, and used a serial sniffer to obtain the garbage this thing responds to. The log I have isn't complete, but it shows me changing folders a couple of times. I might be able to use wine to run the phone's software, and capture more stuff here in linux. In the meantime, this is what I've got. I've not posted it here, because it's far too big, but if you want me to email it or something, I can do that.

      As an overview, the only AT^S command it uses that I noticed was AT^SQWE=<number>. The cding appeared to be done with a binary protocol, with obex layered on top.

      Here's what's probably the most useful bit:

      Request: 15/10/2005 21:38:53.84164 (+0.0000 seconds)

      80 00 1A 10 00 40 06 46 00 13 6B 01 CB 31 41 06 11 D4 9A 77 00 50 DA 3F 47 1F                     ?....@.F..k.1A..?w.P?G.     

      Answer: 15/10/2005 21:38:53.99864 (+0.1563 seconds)

      A0 00 1F 10 00 03 EE CB 00 00 00 03 4A 00 13 6B 01 CB 31 41 06 11 D4 9A 77 00 50 DA 3F 47 1F       .........J..k.1A..?w.P?G.

      Request: 15/10/2005 21:38:53.99864 (+0.0000 seconds)

      83 00 1C 42 00 19 78 2D 6F 62 65 78 2F 66 6F 6C 64 65 72 2D 6C 69 73 74 69 6E 67 00               ?..B..x-obex/folder-listing.   

      Answer: 15/10/2005 21:38:53.17064 (+0.1719 seconds)

      <xml reply follows, but is quite long>

      I'm not sure whether it's your job to be concerned about this garbage, or whether it's the job of someone who will create an application to deal solely with the SF65 (probably beyond my C skills, I'm afraid!) Or perhaps SCMxx...
      Hopefully, however, it'll be useful for you.

       
    • Very useful. Thank you. AT^SQWE is (AFAIK) a synonym to AT^SBFB. The dump show OBEX packets on top of BFB.
      That way everything should work, we just need to work out why the communication won't initialize.