pi_accept timeout problem

["David A. Desrosiers" <setuid linuxcare com>]

	While beating up pilot-link 0.9.5 against gnome-{pilot|conduits}
tonight, I stumbled upon a problem which has been fixed for quite some
time in pilot-link (post 0.9.3) with the pi_accept timeout problems. The
problem is that the 10th packet in the sync is passing an invalid crc back
to the conduit.

	Most people in the past would see this error being reported as: 

	pi_accept: Connection timed out

	gpilotd reports it as: 

	gpilotd-WARNING **: pi_accept_to: Connection timed out

	(Offending code is in gpilotd/gpilotd.c, search for pi_accept)

	You'll always get 10 SLP loopback packets (of type 3) before the
first PADB packet (of type 2), include/pi-slp.h libsock/slp.c. The
previous failures would always occur on the last (tenth) SLP loopback
packet. The immediate failure was that the transmitted CRS16 checksum
didn't match the one calculated by the pilot-link code. The difference is
always that the transmitted packet has bit 7 turned on when it shouldn't
be.  

	The successes always occur when the CRC16 checksum for the tenth
packet really *DOES* have bit 7 turned on. A second attempt at pressing
hotsync or initiating it from the desktop would usually solve the problem.

	We fixed this in pilot-link with a small hack to ignore loopback
packets (which we were ignoring anyway, the fix is in slp.c, search for
LOOP). I can't seem to figure out why gpilotd would still exhibit this
problem, since libpisock has the fix, and presumably since gpilotd relies
on the headers (and libpisock, no?), the problem should be gone. I'll dig
a little further later on. We need to fix this problem in pilot-link
better than this hack, although this hack is non-destructive at the
moment.

	I just got back from BALUG, so I'm busy trying to crank out the
last of the pilot-link versions this week to meet a deadline jpr needed.
When I get a bit more time, I'll chase this down in gpilotd.c, but if
someone else wants to take it upon themselves to check that out, that
would be great.

	Here's what I got after an apparently successful sync of Address
information into gnomecard (I had DLP_TRACE enabled in pilot-link, because
I was fighting another problem with the same symptoms).


gpilotd-Message: Restarting irda funk...
gpilotd-Message: Watching MyPilot (/dev/irnine)
gpilotd-Message: Woke on MyPilot
gpilotd-Message: setting PILOTRATE=115200

gpilotd-WARNING **: pi_accept_to: Connection timed out    <--- should 
gpilotd-Message: Restarting irda funk...                       never see
gpilotd-Message: Watching MyPilot (/dev/irnine)                this here

	Oh, and the condition you trap here in gpilotd/gpilotd.c:

	if (device->port && strlen(device->port) > 13) {
	{...}
	
	...has also been fixed in 0.9.5. Perhaps a simple dependancy check
on it to ensure the users have this version? About a half-week away, and
0.9.5 will hit the streets live.




/d