Re: pilot-link fails: replace with coldsync?

[Scott Otterson <scotto u washington edu>]

> From: JP Rosevear <jpr helixcode com>
> Date: 30 Nov 2000 05:37:47 +0500
>
> On 29 Nov 2000 10:40:42 -0800, Scott Otterson wrote:
> > pilot-link has bugs. Is there a way to make gnome-pilot use coldsync
> > instead of pilot-link?
> 
> Its possible I suppose.  This seems a bit premature though, because as I
> read it cold sync was just fixed and the snap shot is broken in other
> ways..

Yes, it seems like there are a few things not done yet but coldsync does
synch my Palm reliably.  It would be great if gnome-pim moved in its
direction, or at least used it as an example for fixing these pilot-link
bugs.

> This may also be fixed in the 0.9.5pre* releases of pilot-link.
> Have you tried those?  If it is still broken there hopefully Dave or I
> can take a closer look

I downloaded and built pilot-link.0.9.5-pre3 and it still has the same
problems: After backing up a few files, it prints:

  Weird packet
  Failed, unable to back up database
  Weird packet
  RAM backup done.
  Weird packet
  Weird packet

and then exits.  I'm not sure what the "RAM backup done" message means
but an ls in the backup directory reveals that the backup hasn't
actually finished.  If this helps, I've appended chunks of another
couple of emails from the coldsynch author, explaining how he fixed the
serial port problems:

email 1
-------------------------------------------------------------------------

Re: [coldsync-hackers] coldsync 1.5.3 nov 27 snapshot
Date: Wed, 29 Nov 2000 20:21:44 -0500 (EST)
From:  Andrew Arensburger <arensb+CShackers ooblick com>

< stuff deleted >

        Yeah, you're going to continue seeing "Bad CRC" errors under
Linux
until the serial device is fixed (or until you comment out that
fprintf()
:-) ). When it gets a malformed packet like that, ColdSync doesn't
acknowledge it and waits for the Palm to resend it, just as it's always
done.
        The improvement in v1.5.3 is that it no longer falls over with
"Unexpected data packet. I'm confused!", which was the main reason why
it
would fail to complete a sync[1]. Now that it can deal with these cases,
it stands a much better chance of completing a full sync, even on a
noisy
serial line.

[1] In case you care: this happened when ColdSync sent out a data packet
and waited for an ACK packet from the Palm. But instead of an ACK, it
got
another data packet.
        This can happen if the Palm sent ColdSync a data packet, and
ColdSync acknowledged it, but the ACK got lost or corrupt on the way to
the Palm. In this case, the Palm would resend the data packet again. But
as far as ColdSync was concerned, it had already received the data
packet
and send back an ACK.
        In 1.5.3, ColdSync figures that whatever the data packet is,
it's
old news, and unimportant. So it sends back an ACK to shut the Palm up,
and tries resending.

email 2
---------------------------------------------------------------------------

Re: [coldsync-hackers] coldsync 1.5.3 nov 27 snapshot
Date: Thu, 30 Nov 2000 02:27:53 -0500 (EST)
From: Andrew Arensburger <arensb+CShackers ooblick com>

On Wed, 29 Nov 2000, Greg KH wrote:
> On Wed, Nov 29, 2000 at 08:21:44PM -0500, Andrew Arensburger wrote:
> >     Yeah, you're going to continue seeing "Bad CRC" errors under Linux
> > until the serial device is fixed (or until you comment out that fprintf()
> > :-) ). When it gets a malformed packet like that, ColdSync doesn't
> > acknowledge it and waits for the Palm to resend it, just as it's always
> > done.
> 
> Hm, I'm all ears as to what needs to be fixed in the Linux serial driver :)
> 
> Seriously, what's the problem?  Why do you think that the serial driver
> (or the usb visor) driver drops bytes at the beginning?

        It's not the USB driver: I've gotten this on the plain old
serial
port.
        In brief, ColdSync (and pilot-link) under Linux appear to get a
lot of dropped characters from the serial port. I'm afraid to look at
the
pilot-link source, but all ColdSync does is
        open()
        cfsetspeed(B9600)
        cfmakeraw()
        cfsetspeed()
        read() and write()
        close()

        I haven't noticed any definite pattern to the dropped bytes;
it's
not doing tab-expansion or CRLF->LF conversion. It did seem to me that
the
dropped sequences were usually 1-3 bytes long; I didn't see any longer
than 5 or 6. At one point, there appeared to be a 16-byte period (i.e.,
it
would get 14 correct bytes, drop 2, get 14 more, drop 2, and so forth).
The value 0x0d appeared to be dropped more often than other values.
        (Bear in mind, however, that I am a homo sapiens; members of my
species are very good at noticing patterns even where there aren't any.)

> I'd be glad to fix this in the kernel, if that's what's needed.

        This might be a kernel problem. I took a brief glance, but
didn't
stay long enough to go into full kernel-dive mode (besides, there's a
huge
installed base with the current kernel, and I should cope with that). I
did see a comment that said something like, "If the user wants it raw,
turn off overrun checking as well". Dunno if that means anything,
though.