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

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Aug 8 07:59:45 UTC 2013


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

Comment(by karsten):

 After reading Tor/libutp code and staring at Tor/Shadow logs for about two
 days I need to pause a bit.  Quick update of the current roadblocks:

  - There's probably a problem in Shadow that prevents nodes from sending
 or receiving UDP packets.  As a result, libutp's callbacks `on_read` and
 `on_write` are never called, so there's no way how nodes can communicate
 using uTP.  I'll look more into this once the next roadblock is out of the
 way.

  - Steven suggested setting up a client and private bridge in a non-
 simulated environment and use uTP for the first hop from client to bridge.
 This works only if the client has `cached-*` files in its data directory
 before starting, and it takes about a minute for the first circuit to be
 built.  I assume there's something wrong with buffers, but I don't know
 yet what it is.  I identified a few places in Steven's code which might be
 wrong and asked Steven for feedback, though fixing them didn't fix the
 described problem.  I guess I should simply mention them below:

 1.
 https://gitweb.torproject.org/sjm217/tor.git/blob/refs/heads/utp:/src/or/channeltls.c#l203

 Are you really sure you're supposed to return the number of bytes *left*
 in your virtual 8K buffer, not the number of bytes *in* your buffer?  The
 documentation in utp.h says "The uTP socket layer calls this to retrieve
 number of bytes currently in read buffer", and the code in utp.cpp, AFAIU,
 expects the number of bytes in the buffer, too:

 {{{
 // Calculates the current receive window
 size_t get_rcv_window() const
 {
   ...
   // Trim window down according to what's already in buffer.
   const size_t numbuf = func.get_rb_size(userdata);
   assert((int)numbuf >= 0);
   return opt_rcvbuf > numbuf ? opt_rcvbuf - numbuf : 0;
 }
 }}}

 2.
 https://gitweb.torproject.org/sjm217/tor.git/blob/refs/heads/utp:/src/or/channeltls.c#l278

 Could it be a problem that you're using malloc here, not tor_malloc_zero?

 3.
 https://gitweb.torproject.org/sjm217/tor.git/blob/refs/heads/utp:/src/or/channeltls.c#l900

 Why do you think UTP_Write wants the total number of bytes in the buffer,
 not just the ones you just added?

 4.
 https://gitweb.torproject.org/sjm217/tor.git/blob/refs/heads/utp:/src/or/main.c#l1116

 Why did you change this line from connection_or_write_cell_to_buf?  Is
 this really related to the libutp stuff?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9166#comment:18>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list