I've been experiencing a strange problem using pilot-link, and I
wonder if anyone else has also encountered it.
When I use pilot-xfer (or any other pilot-link program that
communicates through HotSync), I often get
pi_accept: Connection timed out
as soon as I press the HotSync button on my cradle. If I immediately
retry the program, it works.
I turned on debugging and traced through execution a bit, but what I'm
finding is quite strange:
- First, I'm always getting 10 SLP loopback packets (protocol type
3) before the first PADB packet (protocol type 2).
- The failures always occur on the last (tenth) SLP loopback
packet. The immediate failure is that the transmitted CRC16
checksum doesn't match the one calculated by the pilot-link
code.
- I've checked the calculation with another CRC16 implementation,
and the pilot-link checksum seems to be correct.
- The difference is always that the transmitted packet has bit 7
turned on when it shouldn't be. For example:
my crc=0x3345 your crc=0x33c5
where 0x3345 is the correct checksum.
- The successes always occur when the CRC16 checksum for the tenth
packet really *does* have bit 7 turned on.
- It doesn't seem to matter what baud rate I'm using. And the
failures are so consistent that I doubt that I'm encountering
a real transmission error.
If it matters, I have a Palm Vx and I'm using it on Red Hat 6.1
running on a Dell Dimension XPS Pro200n (200 MHz Pentium Pro).
Does anyone have any idea what's going on?
This is an annoying problem, so I'm tempted to work around it by
simply ignoring checksum errors on loopback packets -- given that
pilot-link ignores all loopback packets anyway...
--Elgin
