waitfor('Waittime'=>0) may wait forever
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 57
- Forks
- 36
- PR merge metrics
- No merged PRs in 30d
Description
(Moving from Ruby core bug report I filed 3 years ago, recently rejected because net-telnet has been extracted here. Originally reported on ruby 2.0.0p247 (2013-06-27 revision 41674) [armv6l-linux-eabihf] as https://bugs.ruby-lang.org/issues/8668 )
waitfor('Waittime'=>0) says it will not wait once the expected prompt has matched, yet if the remote end continues to send data, it will in fact wait, possibly forever.
Line 555 of net/telnet.rb (from 2.0.0) is:
until(prompt === line and not IO::select([@sock], nil, nil, waittime))
Which means even though prompt has matched, it will still call IO::select, and if new data has arrived, it will make another pass through this loop. In my case there is constantly new data arriving (though it is only telnet control data) and so the loop never exits even though the prompt was matched long ago.
I fixed this with:
until(prompt === line and (waittime==0 or not IO::select([@sock], nil, nil, waittime)))
Though I don't know what other implications that change might have.
There is a related bug with 'Timeout': if the remote end keeps sending data (even if only telnet control codes), but it never matches the prompt, waitfor() will wait forever.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in net/telnet.rb around line 555 and trace the waitfor method's prompt and timeout handling, including IO::select. Verify the behavior when Waittime is 0 and when incoming data continues without matching the prompt; done means both cases terminate according to their documented options.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100