#30472: Implement a mechanism for PT reachability testing -----------------------------------------------+--------------------------- Reporter: phw | Owner: phw Type: project | Status: | needs_review Priority: High | Milestone: Component: Circumvention/Pluggable transport | Version: Severity: Major | Resolution: Keywords: reachability | Actual Points: Parent ID: #30471 | Points: Reviewer: | Sponsor: Sponsor19 -----------------------------------------------+---------------------------
Comment (by cohosh): Replying to [comment:4 phw]: > I built a small golang service that lets bridge operators test their obfs4 port. For now, the code is available at https://github.com/NullHypothesis/obfs4PortScan. > > I set up a demo at https://nymity.ch:8081. After entering your bridge's IP address and port, the service tells you if the port is reachable or not. If the port is unreachable, the service tells you the error message it got. The tool also has a simple rate limiter that limits requests to an average of one per second, with bursts of up to five per second. > Awesome! It worked for me :) I just have a few minor comments: - A nicer way to express the timeout [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43 here] would be {{{ timeout := 3* time.Second }}}, but even better would be to set a commented constant at the beginning of the file. - In `main()` you could have the certificate and key files passed in as specific arguments such as `--cert` or `--key` as the broker does [https://gitweb.torproject.org/pluggable- transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage of this is making sure they are passed in the correct order (which should be documented outside of the usage function). - Do you also want timestamps in your logs? As a more general note, is this meant to be used in an automated way for bridge operators to log and report to themselves when their port isn't reachable? Or as an occasional manual check? I know this is something temporary so maybe not a large consideration, but returning something other than a `200 OK` if the port is unreachable would make it easier to write a client-side go program that performs this check automatically. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30472#comment:6> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs