Re: [tor-dev] Iran
On 5/9/13 1:34 AM, Jacob Appelbaum wrote: Maybe OONI ppl can help with that? I have an idea that I think might help. It isn't related to any current pluggable transport. I think we could pump out a transport that would not be easy to block. It would be also be very interesting to be able to play with the DPI system from an internal iranian intranet address space, if someone have an access from linux box. -naif ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Channel incoming queue
On Thu, May 02, 2013 at 10:58:54AM -0400, MF Nowlan wrote:
Hi all,
I am working on integrating uTCP and uTLS (
http://arxiv.org/abs/1103.0463) into Tor to see if we can lower the
latency due to head of line blocking across circuits. This is
Tracker Item #7679 (
https://trac.torproject.org/projects/tor/ticket/7679). I want to
first test the Tor code's ability to process cells from different
circuits out of order with respect to how TCP delivered them. To
test this, I made some changes to the file named src/or/channel.c.
1. I forced queueing of cells into the channel's incoming_queue with:
channel_queue_cell(...) {
...
need_to_queue = 1; // Force all cells into the queue, so they do NOT
go directly to the handler.
...
2. Now, look for case when two cells from different circuits are
present in the incoming_queue and process the second cell before the
first cell.
channel_process_cells(...) {
...
while (NULL != (q = TOR_SIMPLEQ_FIRST(chan-incoming_queue))) {
// Remove q from the incoming_queue.
// if the queue is still not empty, get the next one,
// if the circuit ids do not match, Swap the cells.
}
...
}
My problem is that number 2. above never occurs. I have not observed
a case where the incoming_queue ever has two cells from different
circuits. In fact, I don't think I've ever had a time when the
incoming_queue has more than 1 cell in it. I am hammering a small
tor test network with 30+ curl requests at once. I have two proxies,
each of them uses the same entry node, and the same exit node, and
there is only one other node in the network, so the circuit that is
set up should be the same for every single request. Am I missing
something? Will this function (channel_process_cells) ever process
more than one cell at a time? I've checked the logs to verify that
different circuits are actually set up for the different requests
(rather than the Proxies just reusing the existing circuit and
giving each new request a new stream id).
[I wrote the channel code, so I'll explain it]
Under normal operation with the current channeltls.c implementation, those
queues should rarely, if ever have more than one cell. The queue exists
because the channel abstraction includes possibilities like going temporarily
into CHANNEL_STATE_MAINT and not processing new traffic, in which case those
queues will accumulate temporarily unprocessable cells. I believe some of
the opening and closing cases might cause them to fill. None of these normally
occur with channeltls.c, which is currently the only channel implementation
layer, and at least the CHANNEL_STATE_MAINT one never occurs.
Short version: you're seeing normal behavior, don't worry about it.
--
Andrea Shepard
and...@torproject.org
PGP fingerprint: 3611 95A4 0740 ED1B 7EA5 DF7E 4191 13D9 D0CF BDA5
pgpwnUEcL_iQq.pgp
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Tor Launcher UI feedback follow up
Thank you to everyone who provided feedback on the Tor Launcher UI. It has been very helpful to us and we made a lot of changes based on it. The most significant change was the addition of an initial question to the first run settings wizard, which allows people to skip all of the detailed questions and quickly connect. Take a look here: http://trial.pearlcrescent.com/tor/torlauncher/2013-05-08/SetupWizard/screen0-initialQuestion.png As Mike pointed out, we are trying to get to alpha ASAP so we can deliver much smaller TBB packages – without Vidalia. For that reason, some of the improvements that people suggested will be left out for now (e.g., automated probing for proxy or firewall settings). -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Launcher UI feedback follow up
Hi, Does this mean the strings are final (frozen)? I am one of Tor's support assistants/translators (in case you wonder why am I asking). Regards, Sheiref Alaa On Thu, May 9, 2013 at 3:29 PM, Mark Smith m...@pearlcrescent.com wrote: Thank you to everyone who provided feedback on the Tor Launcher UI. It has been very helpful to us and we made a lot of changes based on it. The most significant change was the addition of an initial question to the first run settings wizard, which allows people to skip all of the detailed questions and quickly connect. Take a look here: http://trial.pearlcrescent.**com/tor/torlauncher/2013-05-** 08/SetupWizard/screen0-**initialQuestion.pnghttp://trial.pearlcrescent.com/tor/torlauncher/2013-05-08/SetupWizard/screen0-initialQuestion.png As Mike pointed out, we are trying to get to alpha ASAP so we can deliver much smaller TBB packages – without Vidalia. For that reason, some of the improvements that people suggested will be left out for now (e.g., automated probing for proxy or firewall settings). -- Mark Smith Pearl Crescent, LLC http://pearlcrescent.com/ __**_ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**devhttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Launcher UI feedback follow up
Tom Ritter: Some small suggestions: - I'd flip the bottom and the top, with connect being on top. - Wording suggestion: This computer's internet connection is free of obstacles: [greenboldtext]My network operator does not threaten my person safety[/greenboldtext] This computer's Internet connection is [redboldtext]censored, filtered, or proxied[/redboldtext] Nitpick: you might be configuring someone else's computer, so “my” might not be appropriate. In some future, having stylized images on that screen could be great. In any cases, it's already quite an improvement. :) -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor Launcher UI feedback follow up
On 05/09/2013 10:09 AM, Sherief Alaa wrote: Hi, Does this mean the strings are final (frozen)? I am one of Tor's support assistants/translators (in case you wonder why am I asking). No, we are not ready to freeze the strings yet. But I think we are close. We are just waiting on some final feedback. -- Mark Smith Pearl Crescent http://pearlcrescent.com/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
