Re: [coldsync-hackers] Snapshot: 2.0.0

[John-David Smith <jdsmith@astro.cornell.edu>]

Andrew Arensburger wrote:
> 
> On Fri, Feb 23, 2001 at 04:58:53PM -0500, JD Smith wrote:
> > Andrew wrote:
> 
> > I went back through all my versions of coldsync resident, and tried them
> > out, (RH6.2, Kernel 2.2.16 -- so it's not a 2.4.x issue!) using exactly
> > the same .coldsyncrc file.  Only at Coldsync version 1.4.4a was I able
> > to get the sync to work as I remember it used to: at 115200 baud, no ACK
> > timeouts, and *fast*.  By the way the "a" was for the patch I submitted
> > long ago to do "install-only" ala "pilot-xfer -i" -- i.e. unrelated to
> > serial I/O.  The next version I have is 1.5.3, which exhibits the same
> > behaviour as current versions. Somewhere between the two something must
> > have happened to the I/O code.
> 
>         I've just looked at the diffs between 1.4.4 and 1.5.3, and the
> only thing that's changed that even remotely looks as if it might have
> anything to do with this problem is that in
> libpconn/PConnection_serial.c,
> 
>                 sleep(1);
> 
> now says
>         #if defined(__FreeBSD__)
>                 sleep(1);
>         #endif
> 
> You may want to try reinstating the sleep(1) and see if that helps.
> 
>         Though another thing that occurs to me is this: there are
> several instances of tcsetattr(TCSANOW). Perhaps those need to be
> changed to use TCSADRAIN or TCSAFLUSH. If you could play around with
> this and see what (if anything) helps, I'd appreciate it.
>         Obviously, if the sleep(1) proves unnecessary, that'd be best.

Well, I took a look.  You can make 1.5.3 act like 1.4.4 by reinstating the
sleep(), the only real change.  This doesn't gaurantee it will work at a given
speed... you just make it past the ACK Timeout phase, but you may then get Bad
CRC's... seems to depend on the hardware.  The TCSANOW setting doesn't seem to
matter.  

This is a long way from solving the problem though.  2.0.0 has many more changes
in PConnection_serial.c and associated files, and even with sleep(1) reinstated,
still hangs up on ACK Timeouts.  Interestingly, it seems to read a PADP command
with success:

bps_entry(115200) == 1
Got PADP message: type 1, flags 0xc0, size 10
PADP <<< 01 00 01 02 00 00 00 01 c2 00                     | ........Â.
Sending ACK: type 2, flags 0xc0, size 10, xid 0xff
offset == 0 (of 10)
Sending type 1, flags 0xc0, size 10, xid 0x01
about to slp_write()

Here's a few things I've gathered:

CMP in version 1.4.4 does a rate change request:

CMP: Sending type 2, flags 0x80, v1.1, rate 115200

whereas in 2.0.0, no such thing:

CMP: Sending type 2, flags 0x00, v1.1, rate 115200

(0x80 is CMP_IFLAG_CHANGERATE)

This reflects cmp_accept() being removed from coldsync.c, where CHANGERATE was
always set.  In any case, the rate is the same either way.  I don't think this
is a showstopper.

Once the WAKEUP packet is received and acknowledged, the very next thing sent is
different between the two versions:

1.4.4:

frag_flags == 0xc0, frag_len == 2
Sending type 1, flags 0xc0, size 2, xid 0x02
about to slp_write()
PADP >>> 01 c0 00 02 12 00                                 | .À....
ACK <<< 02 c0 00 02                                       | .À..

vs.

2.0.0:

frag_flags == 0xc0, frag_len == 2
Sending type 1, flags 0xc0, size 2, xid 0x02
about to slp_write()
PADP >>> 01 c0 00 02 10 00                                 | .À....
ACK Timeout. Attempting to resend.

notice the second to last byte is "10" instead of "12".  This is the dlp_request
id: 

dlp_send_req: Calculating outgoing request buffer
>>> request id 0x10, 0 args

I.e. DLPCMD_ReadSysInfo in the good old days.  DLPCMD_ReadUserInfo now. Probably
reflects the new emphasis on getting the user name right from the get go
(anti-bargle bug).  Should it matter that the serial number (and sysinfo) is
read after the username now?  I don't see why, unless the ROM version from
SysInfo is being used to set up other connection parameters.  Any thoughts? 


>         Rather than adding a new keyword to the config file syntax, I
> think it might be cleaner to just change the command line syntax from
> 
>         coldsync -ms
> to
>         coldsync -ms [database ...]
> 
> Thus, if you run it as 'coldsync -ms AddressDB', it would run a sync
> as normal, but only for the AddressDB database.
>         "Normal sync" could include a Fetch conduit that checks for
> the existence of ~/address-I-just-wrote-down , parses it, and adds it
> to ~/.palm/backup/AddressDB.pdb .

This sound right.  It might be easier to skip the fetch conduit and roll your
own tool to use p5-Palm and insert the named file (or stdin) into the database,
then call coldsync as a one-shot.  E.g.:

% add-addr
Type address, end with C-d or "." on line by itself
Andrew Arensburger
123 Palm Blvd.
Santa Palma, CA 90210
.

(That's how I've done my version using pilot-addresses).

JD

-- 
This message was sent through the coldsync-hackers mailing list.  To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body.  For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.