0

Currently the only way I know if signaling NEWNYM worked is if I didn't receive a message stating that I've been rate limited.

Is there a way to send something via GETINFO both pre/post signaling for a new identity and compare them after?

Not seeing anything in the spec (https://torproject.gitlab.io/torspec/control-spec/#getinfo), help would be very much appreciated :-D!

EDIT: My workaround. I created a custom listener to write all notice messages to a string buffer. Added the listener before signaling NEWNYM, then waited a few milliseconds and checked the buffer to see if it contained the Rate limited message. If not, I posted to the notification that Identity was changed.

https://github.com/05nelsonm/TorOnionProxyLibrary-Android/commit/778590d12db95a80b84cf3b4ff6fa93ef732284e

If you've got any better ideas, would be much appreciated.

Improve this question
3
  • What about the standard signal reply (250 OK)? For example, see how Stem processes the reply.
    – Steve
    Jun 25 '20 at 20:50
  • Isn't that reply saying the signal was successfully accepted, not that the identity was successfully changed? I'm using jtorctl 0.4 for Android to signal and if it was a success, it does not throw an IOException, where if it fails to signal, it does.
    – 05nelsonm
    Jun 26 '20 at 2:41
  • You're right, it queues the reply message before processing the signal (and even before activating the Libevent event). github.com/torproject/tor/blob/…
    – Steve
    Jun 26 '20 at 4:34
0

The best way to do this is to watch for the 650 SIGNAL NEWNYM message. You can see here in signewnym_impl() that the control event is sent only after Tor's circuit states have been changed. It may take some time for this to occur, especially if the event is deferred. This is backed up by the control-spec, which says:

4.1.17. Signal received

The syntax is:

 "650" SP "SIGNAL" SP Signal CRLF

 Signal = "RELOAD" / "DUMP" / "DEBUG" / "NEWNYM" / "CLEARDNSCACHE"

A signal has been received and actions taken by Tor. The meaning of each signal, and the mapping to Unix signals, is as defined in section 3.7. Future versions of Tor MAY generate signals other than those listed here; controllers MUST be able to accept them.

If Tor chose to ignore a signal (such as NEWNYM), this event will not be sent. Note that some options (like ReloadTorrcOnSIGHUP) may affect the semantics of the signals here.

Note that the HALT (SIGTERM) and SHUTDOWN (SIGINT) signals do not currently generate any event.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.