Re: [tor-bugs] #9166 [Tor]: Write a UTP-based channel implementation

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9166: Write a UTP-based channel implementation
------------------------+------------------------------
     Reporter:  nickm   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  Tor: unspecified
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-relay utp
Actual Points:          |  Parent ID:  #9165
       Points:          |
------------------------+------------------------------

Comment (by karsten):

 Replying to [comment:29 robgjansen]:
 > I spent some time looking into this problem.

 Thanks!  Much appreciated.

 > Here are some observations.
 >
 > libutp does not have on_write and on_read functions that the OS (or
 shadow) calls. In fact, it does not handle OS events in any way - Tor is
 responsible for that (and it uses libevent to make this less painfull).
 Tor does this in
 [https://gitweb.torproject.org/karsten/tor.git/blob/refs/heads/utp:/src/or/connection.c#l2025
 connection.c line 2025].
 >
 > It appears that only the one utp_listener socket is used for each
 chaneltls.
 >
 > Tor creates a *READ* event for the utp listener, hands the event off to
 libevent, and then never looks at it again.

 Yes, so far this all matches my understanding.

 > This seems very fragile: all writes can only be triggered during a read
 event.

 Aha!  This would support why
 [https://gitweb.torproject.org/karsten/tor.git/commitdiff/346d38c8abea6e1af3ff00864ffcd3d877de0a41
 346d38c] makes the utp branch much faster.  Of course, reverting that
 commit and fixing the actual issue would be much better.  How would we fix
 this and make it less fragile?

 > Even worse, the return value for sendto is never checked and handled:
 I'm not sure the implications of sendto failing
 [https://gitweb.torproject.org/karsten/tor.git/blob/refs/heads/utp:/src/or/channeltls.c#l303
 here]. (Failing could in fact mean EAGAIN, ie EWOULDBLOCK, and isn't
 necessarily a bad thing.)

 Agreed that return values should be checked.  I think I did that while
 debugging and didn't get a non-zero return value, but that was before
 making the other fixes.  Worth adding this back in.  What would we do if
 we can't send, other than logging this fact?  Want to write a patch that I
 add to my utp branch, or shall I write that patch?

 >
 [https://gitweb.torproject.org/karsten/tor.git/blob/refs/heads/utp:/src/or/channeltls.c#l386
 utp_read_callback] seems to be getting called by Shadow just fine. The
 problem is that the call to
 [https://github.com/sjmurdoch/libutp/blob/master/utp.cpp#L2522
 UTP_IsIncomingUTP] triggers the sending of a reset
 [https://github.com/sjmurdoch/libutp/blob/master/utp.cpp#L2626 here],
 meaning that libutp never thinks the socket is writable and so UTP_Write
 never writes.
 >
 > I suggest the next step here is turing on libutp debug logs and trying
 to figure out why its sending resets in UTP_IsIncomingUTP.

 I'm not entirely sure how to turn on libutp debug logs.  I think it should
 be possible to log libutp messages to tor's logs.  Do you know how to do
 that?  If so, do you mind writing a patch?  And would it be useful if I
 created some libutp debug logs in my Chutney network for you to compare
 to?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9166#comment:30>
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