Ticket #18 (assigned defect)

Opened 14 months ago

Last modified 14 months ago

Fix proposal for Sony Ericsson models connection with DCU-11 USB cable (pl2303 module)

Reported by: ymartin Owned by: zany
Priority: minor Milestone:
Component: obexftp Version:
Keywords: Ericsson pl2303 connection Cc:

Description

I'm owner of a Sony Ericsonn K300i and obexftp fails to connect twice. This issue seems to concern other models according to the users' reports: T610, T616, T630.

I have compared obexftp source with multisync 0.82 - known to work perfectly when the pl2303 module is involved.

The attached patch fixes this issue but I have no idea what the impact is for other phones... As the trouble only concerns disconnection, I guess it is possible to use a condition with the phone model.

Attachments

obexftp-k300i-patch.txt (0.8 KB) - added by ymartin 14 months ago.
Patch tested with k300i based on 0.22-rc7

Change History

Changed 14 months ago by ymartin

Patch tested with k300i based on 0.22-rc7

Changed 14 months ago by zany

  • keywords Ericsson added; Ericsonn removed
  • owner changed from somebody to zany
  • summary changed from Fix proposal for Sony Ericsonn models connection with DCU-11 USB cable (pl2303 module) to Fix proposal for Sony Ericsson models connection with DCU-11 USB cable (pl2303 module)
  • status changed from new to assigned
  • priority changed from major to minor

Your patch is based on multisync and thus and old version of obexftp. Then problem is a regression then, i.e. it's broken in newer versions. The change was introduced with 0.10.4, 3 years ago. But since a break is only send on failed connection init it's a rare case.

Summing your patch up:

  • Replacing TIOCSBRK with TCSBRKP
  • Forcing a break on bfb_io_close

About the break ioctl:

  • TIOCSBRK: Turn break on, unconditionally
  • TCSBRK: non-zero arg means wait for all output data to be sent but don't send break
  • TCSBRKP: POSIX tcsendbreak(), like above but different length then .25s if non-zero arg.

Turing on a break signal (and leaving it on) is not what we want, I was pointed to this in 2004 but didn't get it back then.

The ioctl is fixed in svn trunk now. Can you recheck if you need the forcible break, and if it works?

Changed 14 months ago by ymartin

Sorry but I have not found any explanation here how to create a working "./configure" from trunk. I have tried "autoconf configure.in > configure" but it reports error about macro "AM_INIT_AUTOMAKE". On my Mandriva 2007.1, I have autoconf 2.61 and automake 1.9.6 - are that versions OK ?

Changed 14 months ago by zany

It's the usual

  • aclocal
  • libtoolize
  • autoheader
  • automake --add-missing
  • autoconf

May need a bit of --force. I never get those right, too. Here is a fresh snapshot http://triq.net/obexftp/obexftp-0.22-rc8.tar.bz2

Changed 14 months ago by ymartin

Hum, really "usual" ? I have not found such sequence in the GNU build system documentation about autoconf/automake.

Thanks for the fix. It is better - before cable disconnection was never for a second connection to succeed - but it is no so efficient than with the "forcible break". In multisync 0.82 this break is forced. Here is an execution sequence without the "forcible break":

yma@hp ~/tools/multisync/obexftp-0.22/apps> ./obexftp -t /dev/ttyUSB0 -U IRMC -l
Using SYNCH uuid.
Connecting...done
Receiving "(null)"... <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<!--
 XML Coder, May 24 2005, 21:06:32, (C) 2001 Sony Ericsson Mobile Communications AB 
-->
<folder-listing version="1.0"><folder name="Images"/>
<folder name="Sons"/>
<folder name="Thèmes"/>
<folder name="Vidéos"/>
<folder name="Autre"/>
</folder-listing>
done
Disconnecting...done
yma@hp ~/tools/multisync/obexftp-0.22/apps> ./obexftp -t /dev/ttyUSB0 -U IRMC -l
Using SYNCH uuid.
Connecting...failed: connect
Still trying to connect
Connecting...failed: connect
Still trying to connect
Connecting...failed: connect
Still trying to connect
yma@hp ~/tools/multisync/obexftp-0.22/apps> ./obexftp -t /dev/ttyUSB0 -U IRMC -l
Using SYNCH uuid.
Connecting...failed: connect
Still trying to connect
Connecting...failed: connect
Still trying to connect
Connecting...done
Receiving "(null)"... <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
<!--
 XML Coder, May 24 2005, 21:06:32, (C) 2001 Sony Ericsson Mobile Communications AB 
-->
<folder-listing version="1.0"><folder name="Images"/>
<folder name="Sons"/>
<folder name="Thèmes"/>
<folder name="Vidéos"/>
<folder name="Autre"/>
</folder-listing>
done
Disconnecting...done

With the "forcible break" - the modem connection is "more" successful. I guess there is an issue with the DCU-11 modem but we have to live with.

Do you think it is necessary to implement a list of models requiring the "forcible break" at disconnection ?

When testing, I got such behavior twice:

yma@hp ~/tools/multisync/obexftp-0.22/apps> ./obexftp -t /dev/ttyUSB0 -U IRMC -l
Using SYNCH uuid.
Connecting...failed: FBS UUID
Still trying to connect
Connecting...done
Receiving "(null)"... failed: (null)
Disconnecting...done

Really strange: why "FBS" when I ask for IRMC ?

And I think this idea may be a good improvement: an option to disable the phone session notification - the jingle makes me nervous after a while - I will try to do it.

Changed 14 months ago by zany

Always sending a break could be a good default. I'll test that with some more mobiles.

The "FBS UUID" error you get is actually a OBEX-CONNECT failure (the error message is bad).

Note: See TracTickets for help on using tickets.