Why 3 and 7? (was Re: patching uucico)

[David Burris]

>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
================================================================