Why 3 and 7? (was Re: patching uucico)
burris at highspl
Mon Jun 10 00:28:29 AEST 1991
>From article <1991Jun9.063022.229 at netcom.COM>, by gandrews at netcom.COM (Greg Andrews):
> In article <1991Jun8.205320.2659 at highspl> burris at highspl (David Burris) writes:
>>Yes, the max is seven, though it doesn't seem it needs to be. The
>>value used for the window size is a char. There are two spots where
>>the code checks for != 0 and two spots where the code sets the window
>>size back to 3 if it is greater than 7. If one wanted to find the
>>spots to patch the checks for greater that 7, it could be patched to
>>window_size = BUFSIZ/64. Check your /usr/include/stdio.h file for
> Oh? A simple patch will allow packet ID numbers greater than 7? Take a
> look at the code that extracts the packet number from the received data
> bytes. Surprise!
> As has meen mentioned in a previous article (not mine), the uucp "g"
> protocol uses a SINGLE BYTE to send the packet information. There are
> five other bytes in the packet header, but they don't carry the info
> for the window. For data packets that byte contains three pieces of
> o The packet type (most significant two bits)
> o The packet identification number (next most significant three bits)
> o The ID number of the last acked packet (least significant three bits)
Ok I hadn't gotten that far in my investigation yet. This would
definately be a stopping point.
If the protocol only allows three bits for the window number, the
situation is hopeless for the 'g' protocol to use larger than 7.
David Burris Aurora,Il.
burris at highspl ..!linac!highspl!burris
More information about the Comp.sys.3b1