Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T14:28:47Zhttps://gitlab.torproject.org/legacy/trac/-/issues/516read-history/write-history show non-relayed traffic too2020-06-13T14:28:47ZRoger Dingledineread-history/write-history show non-relayed traffic tooIn connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any...In connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any numbers higher than that in the read-history/write-history lines will be
due to locally initiated traffic.
The easy fix would be to only count bytes that were sent on relayed connections --
so locally initiated directory connections, and all circuits on connections that
recently carried traffic for an origin circuit, would be ignored:
Index: connection.c
===================================================================
--- connection.c (revision 11723)
+++ connection.c (working copy)
@@ -1546,12 +1546,12 @@
if (!connection_is_rate_limited(conn))
return; /* local IPs are free */
- if (num_read > 0)
- rep_hist_note_bytes_read(num_read, now);
- if (num_written > 0)
- rep_hist_note_bytes_written(num_written, now);
+ if (connection_counts_as_relayed_traffic(conn, now)) {
+ if (num_read > 0)
+ rep_hist_note_bytes_read(num_read, now);
+ if (num_written > 0)
+ rep_hist_note_bytes_written(num_written, now);
- if (connection_counts_as_relayed_traffic(conn, now)) {
global_relayed_read_bucket -= num_read;
global_relayed_write_bucket -= num_written;
}
Then I realized that this has the mirror-image problem: if the server
has uniform enough usage around its BandwidthRate, then just as we
were looking at spikes before and knowing they came from non-relayed
traffic, now we look at dips and conclude the same thing.
Hm.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/525Non-servers and hibernating servers still relay traffic2020-06-13T14:07:30ZNick MathewsonNon-servers and hibernating servers still relay trafficSee thread on or-dev: "Turning off a server", especially Roger's comments at
http://archives.seul.org/or/dev/Oct-2007/msg00007.html
There are two issues here:
1) Perhaps non-servers (those with ORPort off) should be disabled in the...See thread on or-dev: "Turning off a server", especially Roger's comments at
http://archives.seul.org/or/dev/Oct-2007/msg00007.html
There are two issues here:
1) Perhaps non-servers (those with ORPort off) should be disabled in the same way as hibernating servers.
2) Perhaps active streams should get throttled or killed. once we're hibernating or ORPort is off.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/507tor-gencert linked against event/pthread2020-06-13T13:58:41Zweasel (Peter Palfrader)tor-gencert linked against event/pthreadtor-gencert is linked against libevent and libpthread tho it probably doesn't need those.
Since tor-gencert is quite a file that you might want to transfer to a computer that
doesn't have libevent it would be nice if it could not be link...tor-gencert is linked against libevent and libpthread tho it probably doesn't need those.
Since tor-gencert is quite a file that you might want to transfer to a computer that
doesn't have libevent it would be nice if it could not be linked against that library.
Unless of course it needs libevent.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/484not freeing an mmap2020-06-13T13:58:38ZRoger Dingledinenot freeing an mmap==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c...==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c:138)
==26396== by 0x80EDA36: tor_mmap_file (compat.c:172)
==26396== by 0x80C79E2: router_rebuild_store (routerlist.c:591)
==26396== by 0x80C7F88: router_reload_router_list_impl (routerlist.c:694)
==26396== by 0x80C7FCE: router_reload_router_list (routerlist.c:712)
==26396== by 0x80ADAE2: do_main_loop (main.c:1366)
==26396== by 0x80AF05A: tor_main (main.c:2660)
==26396== by 0x80E5C55: main (tor_main.c:28)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/513Torbutton 1.1.7.-alfa disables private data clear upon close Firefox2007-09-28T00:20:54ZTracTorbutton 1.1.7.-alfa disables private data clear upon close FirefoxTor/Privoxy/Vidalia bundle 0.2.0.7-alpha with Torbutton 1.1.7-alpha, Firefox 2.0.0.7, WinXP sp2
Toggling Torbutton to "off" will disable (uncheck option box)
Firefox -> Tools -> Options -> Privacy, Private Date "Always clear my private ...Tor/Privoxy/Vidalia bundle 0.2.0.7-alpha with Torbutton 1.1.7-alpha, Firefox 2.0.0.7, WinXP sp2
Toggling Torbutton to "off" will disable (uncheck option box)
Firefox -> Tools -> Options -> Privacy, Private Date "Always clear my private data when I close Firefox"
Result: Firefox will not clear private data (search history, cach
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: docTor