Opened 4 years ago

Closed 4 years ago

#7558 closed defect (fixed)

'GETINFO orconn-status' unexpectedly providing ServerID rather than LongName

Reported by: eoinof Owned by: nickm
Priority: Medium Milestone:
Component: Core Tor/Stem Version:
Severity: Keywords: testing
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I found a minor bug in
/test/integ/control/controller.py
def test_enable_feature

If networking is enabled but not online, then data
like this can be in orconn_output
orconn_output == '$590A7A707B0FAFEF93F57FF061303D4415A13045 LAUNCHED'
This causes the regular expression to fail on line 346

When properly offline the test is skipped as orconn_output is a blank string
and when fully online the string is '$C4C7BF6724E2AA980E4664C04BC264C4AC7D0627~Anonymous CONNECTED\n ...'
which matches the regular expression

One way to fix this would be to only apply the regular expression if the 2nd part of the orconn_output is CONNECTED.
And add a separate regular expression for the LAUNCHED status, and possibly for any other possible strings?

I encountered this when running in a virtual machine without an internet connection.

Child Tickets

Change History (9)

comment:1 Changed 4 years ago by atagar

  • Priority changed from trivial to normal

Great catch, Eoin! This looks like it may be a tor bug. Could you please start tor in your VM with an open control port and try the following?

atagar@morrigan:~/Desktop/stem$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.

AUTHENTICATE
250 OK

USEFEATURE VERBOSE_NAMES
250 OK

GETINFO version
250-version=0.2.1.30
250 OK

GETINFO orconn-status
250+orconn-status=
$FF70FEE26E41E0CD582C4348E78F7CACE393B299=Zwiebelschale CONNECTED
$7610BBD3F5BB67284EEE8476721AE6109DC29BEA=chaoscomputerclub3 CONNECTED
$9E4F56839C06738DA4B806068854C06780EFBD18=Amunet5 CONNECTED
$071C2D9D0E03D75FF30DCCA850BB29CA4A4BB383=CzechMix CONNECTED
$5D0034A368E0ABAF663D21847E1C9B6CFA09752A~Karlstad CONNECTED
$4A0CCD2DDC7995083D73F5D667100C8A5831F16D=Tonga LAUNCHED
.
250 OK

If you're running Tor verion 0.1.2.2 or later and get something like "$590A7A707B0FAFEF93F57FF061303D4415A13045 LAUNCHED" then that's a tor bug since it should provide a 'LongName' rather than 'ServerID'.

https://gitweb.torproject.org/torspec.git/blob/HEAD:/control-spec.txt#l572

comment:2 Changed 4 years ago by eoinof

I'm afraid I haven't been able to replicate this behaviour.
I'll try a bit harder when I get a chance & update this
ticket again.

This was the output from one testing run.

AUTHENTICATE
250 OK
USEFEATURE VERBOSE_NAMES
250 OK
GETINFO version
250-version=0.2.2.35 (git-73ff13ab3cc9570d)
250 OK
GETINFO orconn-status
250-orconn-status=$B93DCC053D7F0472BB17A4514E06FE76D9FB714B=XXX LAUNCHED
250 OK
GETINFO orconn-status
250-orconn-status=$4493B473A59E4D5C14F32A95F9831D2A2550DBA2=XXX LAUNCHED

comment:3 Changed 4 years ago by atagar

  • Keywords testing added
  • Status changed from new to needs_information

Hi Eoin. Any luck reproducing this?

comment:4 Changed 4 years ago by eoinof

Hi Daniel, sorry for the delay,

I managed to reproduce the problem, though it's a pretty unusual
situation so maybe it's not a bug?

I remembered that I had been deleting some files so I checked what ones
had been recently replaced.

I deleted the contents of /stem/test/data and then ran the integ tests while not
connected to the internet

This was how the test failed.

FAIL: test_enable_feature
----------------------------------------------------------------------
Traceback:
  File "/home/eoin/stem/test/integ/control/controller.py", line 346, in test_enable_feature
    self.assertTrue(re.match("\$[0-9a-fA-F]{40}[~=].*", controller.get_info('orconn-status').split()[0]))
AssertionError: None is not true

I then started tor using the newly created config file /stem/test/data/torrc

This is what I see in telnet

eoin@eoin-VirtualBox:~/stem$ telnet localhost 1111
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
AUTHENTICATE
250 OK
USEFEATURE VERBOSE_NAMES
250 OK
GETINFO version
250-version=0.2.2.35 (git-73ff13ab3cc9570d)
250 OK
GETINFO orconn-status
250-orconn-status=$F397038ADC51336135E7B80BD99CA3844360292B LAUNCHED
250 OK
GETINFO orconn-status
250-orconn-status=
250 OK

comment:5 follow-up: Changed 4 years ago by atagar

  • Component changed from Stem to Tor
  • Owner changed from atagar to nickm
  • Status changed from needs_information to assigned

Thanks Eoin! Reassigning this to Nick.

Nick: Here's a short description of the bug...

  1. Start tor 0.2.2.35 with a blank data directory, and no network connection.
  2. Connect to it with a controller, set VERBOSE_NAMES, then call 'GETINFO orconn-status'.

Expected:

orconn-status with LongName entries (ex. "$FF70FEE26E41E0CD582C4348E78F7CACE393B299=Zwiebelschale")

Actual:

tor provides ServerID entries (ex. "$F397038ADC51336135E7B80BD99CA3844360292B")

Hi Daniel, sorry for the delay,

s/Daniel/Damian

comment:6 Changed 4 years ago by atagar

  • Summary changed from Minor bug in control test to 'GETINFO orconn-status' unexpectedly providing ServerID rather than LongName

Revising the summary.

Nick: when you're done with this ticket please reassign it back to the stem component, since I'll probably want to add an assertion in the tests for this

comment:7 in reply to: ↑ 5 Changed 4 years ago by rransom

  • Component changed from Tor to Stem

Replying to atagar:

Thanks Eoin! Reassigning this to Nick.

Nick: Here's a short description of the bug...

  1. Start tor 0.2.2.35 with a blank data directory, and no network connection.
  2. Connect to it with a controller, set VERBOSE_NAMES, then call 'GETINFO orconn-status'.

Expected:

orconn-status with LongName entries (ex. "$FF70FEE26E41E0CD582C4348E78F7CACE393B299=Zwiebelschale")

Actual:

tor provides ServerID entries (ex. "$F397038ADC51336135E7B80BD99CA3844360292B")

That's a LongName entry with the (optional) nickname omitted. See https://gitweb.torproject.org/torspec.git/blob/aeebf8950ad137478b661cc2b6fa4c47c5f88f2f:/control-spec.txt#l169.

This is probably easiest to trigger by putting a Bridge option which specifies a fingerprint in Tor's configuration.

comment:8 Changed 4 years ago by atagar

Baka. You're right. The test should probably use _parse_circ_entry rather than its own regex...

https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/control.py#l1589

comment:9 Changed 4 years ago by atagar

  • Resolution set to fixed
  • Status changed from assigned to closed

On reflection the regex really wasn't important for this test so simply dropped it...

https://gitweb.torproject.org/stem.git/commitdiff/6f94c909d21b710fe86030cf3c1824102fc52613

Feel free to reopen if this didn't do the trick.

Note: See TracTickets for help on using tickets.