[rancid] expect/tcl bug?

[heasley]

Thu, Jul 06, 2017 at 06:40:31PM +0000, Gauthier, Chris:
> 
>     Thu, Jul 06, 2017 at 06:32:05PM +0000, Gauthier, Chris:
>     > Is the expect/tcl bug still relevant even though it was first reported in 2001? TIA
> 
>     I can't say if it is.  it is difficult to replicate and I have just blindy
>     applied applied it to all solaris/linux installs since.
> 
> I’m willing to test it, but don’t know how to replicate it.

exactly. :)

what happens, iirc, is that due to timing (ie: when data arrives & when &
how much tcl decides to read from the fd), there is a partial match on the
buffer, and after that rather than a match attempt again, there is a
read(2), at which point it hangs because the fd is blocking.  There isnt
more data to read, the needed data is in the buffer already.

eg buffer:
    some output.....blah blah blah \r\nprompt#

it has that in the buffer.  reads up to the \n, calls read(2) and blocks
until the timeout.  but the device is waiting for more commands.  and the
prompt is in buffer already, it just needs to run the expect again.

the patch/hack fixes this by making the fd non-blocking (temporarily).