Why 3 and 7? (was Re: patching uucico)
David Burris
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
>>BUFSIZ.
>>
>
> 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
> information:
>
> 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
mailing list