[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #8203 [Tor]: Inconsistent stream events when resolving hostname

#8203: Inconsistent stream events when resolving hostname
------------------------------------------------------+---------------------
 Reporter:  Desoxy                                    |          Owner:                    
     Type:  defect                                    |         Status:  needs_review      
 Priority:  normal                                    |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                       |        Version:                    
 Keywords:  tor-client controller dns 024-deferrable  |         Parent:                    
   Points:                                            |   Actualpoints:                    
------------------------------------------------------+---------------------
Changes (by Desoxy):

  * status:  needs_revision => needs_review


Comment:

 Thank you both for reviewing my patch.

 Regarding the "(Tor_internal)" address and the control spec: The control
 spec specified there would always be a SOURCE_ADDR (when extended events
 were turned on), but it specified that SOURCE_ADDR to be Address ":" Port,
 which means that returning "(Tor_internal):0" was actually violating that
 spec:

 {{{
   Address = ip4-address / ip6-address / hostname   (XXXX Define these)

 (...)

       "650" SP "STREAM" SP StreamID SP StreamStatus SP CircuitID SP Target
           [SP "REASON=" Reason [ SP "REMOTE_REASON=" Reason ]]
           [SP "SOURCE=" Source] [ SP "SOURCE_ADDR=" Address ":" Port ]
           [SP "PURPOSE=" Purpose]
           CRLF

 (...)

        Port = an integer from 0 to 65535 inclusive

 }}}

 I have now changed the patch to simply use the control connection
 informationas SOURCE_ADDR for method 3. This means that a) there is always
 a valid SOURCE_ADDR and b) the control spec does not have to be changed.

 Vidalia: Vidalia uses stream events to display the Tor network map.
 However, it does not particularly care about the StreamStatus, other than
 displaying it to the user. As far as I could see, there are no assumptions
 that a stream has to start with a StreamStatus of "NEW".

 Other controllers: Given that there are 3 different StreamEvent sequences
 that can happen depending on how the resolve request was made, it is a
 fair assumption that any controller relying on new streams having a "NEW"
 StreamStatus would have not worked with all 3 of them anyway. I am very
 much in favor of doing it right this time instead of keeping a duplicate
 "NEW" StreamStatus just to keep some controller library happy. Also, let's
 not forget that the "NEW" StreamStatus would only be sent after the stream
 was already attached to a circuit, while for non-DNS-streams it would be
 sent before the stream was attached to a circuit.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8203#comment:5>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs