[tor-bugs] #5280 [Obfsproxy]: obfsproxy transport functions do not understand TCP

[Tor Bug Tracker & Wiki]

#5280: obfsproxy transport functions do not understand TCP
-----------------------+----------------------------------------------------
 Reporter:  asn        |          Owner:  asn
     Type:  defect     |         Status:  new
 Priority:  normal     |      Milestone:     
Component:  Obfsproxy  |        Version:     
 Keywords:             |         Parent:     
   Points:             |   Actualpoints:     
-----------------------+----------------------------------------------------

Comment(by nickm):

 You're a little mistaken about the rules for when libevent calls a read
 callback.

 The only things guaranteed about read callback is that you will get a read
 callback when a read adds data to a bufferevent's input buffer, and that
 input buffer is greater  greater than the read low watermark for that
 bufferevent.

 The 4096-bytes-at-a-time thing is an implementation detail that *will*
 change in future versions; you can't count on it at all.  It's also not
 necessarily true: if read high watermarks are enabled, or rate limiting is
 enabled, Libevent may read less at a time.  Also, if there are less than
 4096 bytes to read, Libevent will read them, and then still call the read
 callback if the conditions in the last paragraph are met.


 Similarly, the amount of data that will get written at a time, or that
 will get written with a single syscall, is not specified by the Libevent
 API.  Generally, it's "as much as possible," except if rate-limiting is
 enabled.

 Bufferevents doesn't have access to the actual boundaries of TCP packets,
 since the Berkeley Sockets API doesn't provide that. (Unless if you're
 building your own packets with raw sockets or something, but that's not so
 standard.) If I call send() twice in succession, that might make 3 TCP
 packets, or it might make 1, or it might make 0 if the kernel is waiting
 for the other side to ack data that's already been sent. So at best, all
 you can hope to do is get some control over what syscalls are called, not
 over what packets are generated directly.  If you can rephrase what you
 need in terms of syscalls, there might be a prayer of getting it, but if
 you actually need direct control over packets, bufferevents can't get you
 that.

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