Extend Chutney to be able to verify that we can send and retrieve traffic
This is related to #8530 (moved).
Activity
The plan was to use nc(1) but -w not working when using a socks proxy and Python 2.x popen() not knowing about timeouts made me implement a select loop. It should be good enough for this (in fact, too good for sending data over loopback IMO) and reasonably easily extendable to support multiple listeners should we want to test several circuits in parallell some day.
Please see branch bug8531 in my Chutney repo.
Trac:
Status: new to needs_review
Stuff to fix before merging:
This needs documentation and comments.
Exiting with a -1 exit code is not so great -- exit codes are often restricted to 8 bits unsigned, so you might as well just exit with 1 or with 0.
Stuff that we should open new tickets for:
This is okay for now, I think, but we should very soon come up with a way to make it cleaner and more extensible: we certainly don't want to put every network test we're ever going to write into a new method in TorNet.py, right?
We sholdl consider the use of the asyncore or asynchat modules rather than invoking select.select directly.
Trac:
Status: needs_review to needs_revision-
Note to self: when merging this, merge #8530 (moved) too.
Added some documentation and comments in updated branch bug8531. There are a few bug fixes in there too.
Rationale behind exit(-1) is that it turns into highest available number which hopefully won't collide with a wrapping shell script trying to exit with different codes depending on error (like 1, 2, 3). I changed it to 255 since that's more explicit.
Created new tickets #9086 (moved) and #9087 (moved).
Trac:
Status: needs_revision to needs_reviewmentioned in issue #9086 (moved)
mentioned in issue #9087 (moved)
moved to tpo/core/chutney#8531 (closed)
mentioned in issue tpo/core/chutney#9086 (closed)
mentioned in issue tpo/core/chutney#9087 (closed)