September 2011 - tor-dev - lists.torproject.org

connection_edge_process_relay_cell(): data cell dropped, unknown stream
by Fabian Keil 22 Sep '11

22 Sep '11

While experimenting with Tor v0.2.3.4-alpha's "optimistic data" and thus keeping an eye on the logs, I noticed that I get a lot of the following messages (with and without "optimistic data"): Sep 20 13:47:57.428 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8236 relay cells here (command 2, stream 49411). Sep 20 13:47:57.428 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 911. Sep 20 13:47:57.428 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.431 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8237 relay cells here (command 2, stream 49411). Sep 20 13:47:57.431 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 910. Sep 20 13:47:57.431 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8238 relay cells here (command 2, stream 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 909. Sep 20 13:47:57.432 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:47:57.432 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8239 relay cells here (command 2, stream 49411). [...] Sep 20 13:48:01.479 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8379 relay cells here (command 2, stream 49411). Sep 20 13:48:01.479 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 968. Sep 20 13:48:01.479 [info] {APP} connection_edge_process_relay_cell(): data cell dropped, unknown stream (streamid 49411). Sep 20 13:48:01.479 [debug] {APP} relay_lookup_conn(): found conn for stream 49410. Sometimes up to 400-500 dropped cells per unknown stream id. The deliver window seems to go down to 900 and then starts at 999 again. It's my impression that it always happens after the client connection is closed prematurely, something my feed reader unfortunately does frequently: Sep 20 13:47:56.608 [debug] {APP} connection_edge_process_relay_cell(): Now seen 8235 relay cells here (command 2, stream 49411). Sep 20 13:47:56.608 [debug] {APP} connection_edge_process_relay_cell(): circ deliver_window now 912. Sep 20 13:47:56.792 [debug] {APP} circuit_consider_stop_edge_reading(): considering layer_hint->package_window 995 Sep 20 13:47:56.792 [info] {EDGE} connection_edge_reached_eof(): conn (fd 14) reached eof. Closing. I assume it can take several seconds for the exit relay to stop sending data and the Tor client has to continue reading from the stream to keep the circuit usable. Is that correct? Is it intended behaviour for the Tor client to forget a stream id before the stream is actually closed on the remote end? Fabian

2 2

Tor-related postdoc position available
by Ian Goldberg 19 Sep '11

19 Sep '11

In case you're interested but hadn't yet heard, I've got a postdoctoral researcher position available "in the field of privacy-enhancing technologies, preferably on the topic of privacy-preserving communications systems". If you (or someone you know) is finishing up a PhD and would like to work on PETs/Tor stuff with us Waterloo folks, drop me a line (noting "Postdoctoral position" in the subject line). Details are here: http://crysp.uwaterloo.ca/prospective/postdoc/ Thanks, - Ian

1 0

Building an automatic censorship-detection system for Tor
by Karsten Loesing 17 Sep '11

17 Sep '11

In the past years we observed sudden drops in Tor usage in certain countries. Some of these events may be attributed to countries specifically wanting to block Tor, as it enables their citizens to circumvent their censorship infrastructure. Other events likely result from country-wide Internet outages that are unrelated to Tor. Two such events happened in January 2011 in Iran [0] and Egypt [1]. The key point is that we can derive from observed Tor usage when something potentially interesting is going on in a country. We should be able to build a system that keeps track of our daily user estimates per country and automatically sends out a warning whenever there are sudden changes. George Danezis wrote "An anomaly-based censorship-detection system for Tor" [2]. George's detection code [3] uses our daily user estimates [4] as input and gives a list of sudden upturns and downturns per country as output. We integrated the results of his script in the metrics website [5] to demonstrate what events the detector recognizes as possible censorship events. For example, the detector would have warned in January 2011 about the events in Iran [6] and Egypt [7], shown as red dots for downturns. However, as one can see, George's script also detects quite a few false positives. Whenever there's a red or blue dot, the script would have issued a warning for a human to check. It would be neat to reduce these false warnings while still catching the really suspicious events. Want to help us make our censorship-detection system better? Any suggestion to improve George's algorithm or to come up with an alternative approach to detect possible censorship events in our data would be much appreciated! Let us know if we can help you get started. [0] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [1] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [2] https://metrics.torproject.org/papers/detector-2011-08-11.pdf [3] https://gitweb.torproject.org/metrics-tasks.git/tree/HEAD:/task-2718 [4] https://metrics.torproject.org/csv/direct-users.csv [5] https://metrics.torproject.org/users.html#censorship-events [6] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-… [7] https://metrics.torproject.org/users.html?graph=direct-users&start=2011-01-…

3 2

Run Tor relay in background on OS X
by Doug Ransom 03 Sep '11

03 Sep '11

Hi, I was thinking of tweaking TOR and/or Vidalia so users can easily (i.e. w/o being a skilled unix sysadmin) to configure TOR to run at boot. Any thoughts or concerns before I poke at the source code? In the past I have had some success running TOR at boot using Launchd, but its hard and doesnt play nice with Vidalia. Doug Ransom doug.ransom(a)alumni.uvic.ca

1 0