Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:09:49Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1097Very recent version of Windows [major=6,minor=1]2020-06-27T14:09:49ZRoger DingledineVery recent version of Windows [major=6,minor=1]Our Windows version detection code needs an update, now that
major=6 minor=1 is out (whatever that is).
[Automatically added by flyspray2trac: Operating System: All]Our Windows version detection code needs an update, now that
major=6 minor=1 is out (whatever that is).
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1099Spurious bootstrap warnings if no-route-to-host2020-06-27T14:09:49ZRoger DingledineSpurious bootstrap warnings if no-route-to-hostSep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect t...Sep 19 22:42:11.251 [warn] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (No route to host; NOROUTE; count 1; recommendation warn)
$ telnet 89.54.142.227 443
Trying 89.54.142.227...
telnet: Unable to connect to remote host: No route to host
This isn't a problem with my network, it's a problem with that host.
And it looks like Tor can't tell the difference:
$ grep END_OR_CONN_REASON_NO_ROUTE *.h
or.h:#define END_OR_CONN_REASON_NO_ROUTE 6 /* no route to host/net */
We should teach it the difference.
Step one is to do this in errno_to_orconn_end_reason(), which I think will
solve the particular issue here.
Step two would be to solve it in tls_error_to_orconn_end_reason(), but I
bet that might be trickier.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1100problem to connecting to tor network2020-06-27T14:09:48ZTracproblem to connecting to tor networkhi
i am from Iran, and i use tor for passing filtering,
from the uprising of people on friday(18 sep) at
first government stop https protocol and tor obviously has stoped,
and now after 2 days;
gmail, yahoo and many https services has ...hi
i am from Iran, and i use tor for passing filtering,
from the uprising of people on friday(18 sep) at
first government stop https protocol and tor obviously has stoped,
and now after 2 days;
gmail, yahoo and many https services has been back but tor is not working
please help me slove this problem
the vidalia has been stoped at "establishing an encrypted directory connection"
status message
here is my log
Sep 20 19:56:14.937 [Notice] Tor v0.2.1.19. This is experimental software. Do not rely on it for strong anonymity. (Running on Windows "Longhorn" Service Pack 2 [workstation] {terminal services, single user})
Sep 20 19:56:14.937 [Notice] Initialized libevent version 1.4.11-stable using method win32. Good.
Sep 20 19:56:14.938 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 20 19:56:14.938 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 20 19:56:15.045 [Notice] Parsing GEOIP file.
Sep 20 19:56:18.012 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 19:56:47.990 [Notice] No current certificate known for authority ides; launching request.
Sep 20 19:56:47.991 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 19:56:47.991 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 19:58:19.065 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 19:58:19.066 [Notice] No current certificate known for authority ides; launching request.
Sep 20 19:58:19.066 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 19:58:19.067 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 20:04:25.521 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority ides; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 20:04:25.522 [Notice] No current certificate known for authority dannenberg; launching request.
Sep 20 20:15:36.221 [Notice] No current certificate known for authority moria1; launching request.
Sep 20 20:15:36.221 [Notice] No current certificate known for authority tor26; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority dizum; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority ides; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority gabelmoo; launching request.
Sep 20 20:15:36.222 [Notice] No current certificate known for authority dannenberg; launching request.
thanks for your time
Mohsen
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: Mohsenhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1101getinfo config-file doesn't handle relative paths well2020-06-27T14:09:48ZRoger Dingledinegetinfo config-file doesn't handle relative paths wellHere's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no h...Here's how getinfo config-file is supposed to go:
getinfo config-file
250-config-file=/usr/local/etc/tor/torrc
250 OK
But I started my tor like "path/to/tor -f moria2-orrc", so getinfo
config-file simply returns "moria2-orrc" with no hint about where
it is. That means controllers like arm don't know where to look.
Should we change Tor so it prepends an absolute path when answering
the controller?
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1103circuit_build_times_generate_sample() asserting2020-06-27T14:09:48ZRoger Dingledinecircuit_build_times_generate_sample() assertingApparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) f...Apparently running 0.2.2.2-alpha.
<hexa> my relay just died with 15:12:00 [ERR] Bug: circuitbuild.c:576:
circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
Looks like we should a) make this not fatal, and b) figure out if there's a
further bug.
[Automatically added by flyspray2trac: Operating System: All]Mike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1104We should have an option that disables connections to bridge auth and fallback2020-06-27T14:09:48ZSebastian HahnWe should have an option that disables connections to bridge auth and fallback] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
...] I meant UpdateBridgesFromAuthority 0
] Or does that not prevent connections to the Authority?
] If it doesn't, I think we should have some config option that means
"never talk to the bridge authority". Else it's easier to spot that
someone is trying to use Tor
arma] right. we've never really solved that part of the problem. i
figured i'd do it once somebody blocks it.
arma] whether tor decides to go to the bridge authority directly
depends on a couple of things.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1107PublishServerDescriptor allows options 0 and 1 simultaneously2020-06-27T14:09:48ZSebastian HahnPublishServerDescriptor allows options 0 and 1 simultaneouslyThat doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]That doesn't make sense, and I think we should reject a config like that.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1108Assertion Failed2020-06-27T14:09:48ZTracAssertion FailedI have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anon...I have to roll back to version 0.2.1.19-alpha
cause version 0.2.2.2-alpha did not start
[code]
Sep 28 11:04:21.640 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:04:21.750 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:04:21.750 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:04:21.750 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:04:21.750 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:04:21.750 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:04:21.750 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:04:21.796 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:05:28.062 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:05:28.171 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:05:28.171 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:05:28.171 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:05:28.171 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:05:28.171 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:05:28.171 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 28 11:05:28.218 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
Sep 28 11:08:06.468 [Notice] Tor v0.2.2.2-alpha (git-54ba86d9d0cff2ce). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 28 11:08:06.468 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Sep 28 11:08:06.468 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 28 11:08:06.562 [Notice] Opening Directory listener on 0.0.0.0:563
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 28 11:08:06.562 [Notice] Opening Socks listener on 192.168.254.1:9050
Sep 28 11:08:06.562 [Notice] Opening DNS listener on 127.0.0.1:53
Sep 28 11:08:06.562 [Notice] Opening Control listener on 127.0.0.1:9051
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/tpo/core/tor/-/issues/1109Assertion Failed2020-06-27T14:09:48ZTracAssertion FailedI was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong a...I was´nt able to re-open , nor to add data to task 1108
thus, I am reporting this again
thanks
> Sep 28 15:06:13.968 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:06:14.187 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:06:14.187 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:06:14.296 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:06:14.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:06:14.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:06:14.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:06:14.437 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
> Sep 28 15:07:19.296 [Notice] Tor v0.2.2.3-alpha
> (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on
> it for strong anonymity. (Running on Windows XP Service Pack 3
> [workstation] {terminal services, single user})
> Sep 28 15:07:19.406 [Notice] Initialized libevent version
> 1.4.12-stable using method win32. Good.
> Sep 28 15:07:19.406 [Notice] Opening OR listener on 0.0.0.0:9001
> Sep 28 15:07:19.406 [Notice] Opening Directory listener on 0.0.0.0:563
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 127.0.0.1:9050
> Sep 28 15:07:19.406 [Notice] Opening Socks listener on 192.168.254.1:9050
> Sep 28 15:07:19.406 [Notice] Opening DNS listener on 127.0.0.1:53
> Sep 28 15:07:19.406 [Notice] Opening Control listener on 127.0.0.1:9051
> Sep 28 15:07:19.453 [Error] Bug: circuitbuild.c:380:
> circuit_build_times_shuffle_array: Assertion cbt->total_build_times ==
> cbt->build_times_idx failed; aborting.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/tpo/core/tor/-/issues/1111assert on start up of 0.2.2.3-alpha2020-06-27T14:09:47ZAndrew Lewmanassert on start up of 0.2.2.3-alphaOn start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libev...On start up, Oct 02 07:38:44.749 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array:
Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
full log is:
Oct 02 07:42:06.995 [notice] Initialized libevent version 1.3e using method epoll. Good.
Oct 02 07:42:06.995 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 02 07:42:06.995 [notice] Opening Control listener on 127.0.0.1:9051
Oct 02 07:42:07.011 [err] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
(gdb) bt
#0 0x00007ffe9e44afb5 in raise () from /lib/libc.so.6
#1 0x00007ffe9e44cbc3 in abort () from /lib/libc.so.6
legacy/trac#2 0x000000000040feb0 in circuit_build_times_parse_state (cbt=0x719f00, state=0x8918b0, msg=0x7fffa7a56a38) at circuitbuild.c:380
legacy/trac#3 0x0000000000425fbb in set_options (new_val=<value optimized out>, msg=<value optimized out>) at config.c:5075
legacy/trac#4 0x0000000000426561 in options_init_from_string (
cf=0x87d540 "# This file was generated by Tor; if you edit it, comments will not be preserved\n# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it\n\nBridge 97.107.129.143:80 06008EDA5"..., command=<value optimized out>, command_arg=0x0, msg=0x7fffa7a56b40) at config.c:4287
legacy/trac#5 0x000000000042696a in options_init_from_torrc (argc=3, argv=0x7fffa7a56dd8) at config.c:4161
legacy/trac#6 0x0000000000463115 in tor_init (argc=3, argv=0x7fffa7a56dd8) at main.c:1873
legacy/trac#7 0x0000000000466d16 in tor_main (argc=3, argv=<value optimized out>) at main.c:2120
legacy/trac#8 0x00007ffe9e4365a6 in __libc_start_main () from /lib/libc.so.6
legacy/trac#9 0x0000000000407819 in _start () at ../sysdeps/x86_64/elf/start.S:113
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/1112Tor can´t open directory2020-06-27T14:09:47ZTracTor can´t open directoryAfter I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und...After I installed Tor it ran. (I wanted to create a bridge, as requested in the blog ). After restarted the computer,
it doesn´t work. The message protocol says :
Okt 03 00:35:24.218 [Warnung] Error creating directory "C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor": Invalid argument
Okt 03 00:35:24.218 [Warnung] Failed to parse/validate config: Couldn't access/create private data directory ""C:\\Dokumente und Einstellungen\\*****\366rg\\Anwendungsdaten\\tor""
Okt 03 00:35:24.218 [Fehler] Reading config failed--see warnings above.
Im not the only one, this question I found, but it wasn´t solved:
http://www.multimediaxis.de/showthread.php?t=119538
Also other directorys I can´t open to write since then.
But I´ll wait for an answer, before I try to deinstall tor.
MfG h
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: hhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1113Bridge relays should deny all exits by default2020-06-27T14:09:47ZSebastian HahnBridge relays should deny all exits by defaultI think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating Sy...I think we should make it explicit that Bridges are entry points into
the Tor network, and not allow the default exit policy if no ExitPolicy
line is given.
Does that sound plausible?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1114DH key warn message2020-06-27T14:09:47ZTracDH key warn messageHello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16....Hello,
got this warnings on Debian Etch with Tor 0.2.0.35:
Sep 19 06:00:09.581 [warn] DH key must be at least 2.
Sep 19 06:00:09.581 [warn] Rejecting insecure DH key [0]
Sep 19 06:00:09.581 [warn] Rejected invalid g!^x
Sep 21 08:25:16.213 [warn] DH key must be at least 2.
Sep 21 08:25:16.213 [warn] Rejecting insecure DH key [0]
Sep 21 08:25:16.213 [warn] Rejected invalid g!^x
Sep 24 05:22:43.076 [warn] DH key must be at least 2.
Sep 24 05:22:43.077 [warn] Rejecting insecure DH key [0]
Sep 24 05:22:43.077 [warn] Rejected invalid g!^x
Sep 27 15:15:39.650 [warn] DH key must be at least 2.
Sep 27 15:15:39.650 [warn] Rejecting insecure DH key [0]
Sep 27 15:15:39.650 [warn] Rejected invalid g!^x
Sep 28 09:13:31.569 [warn] DH key must be at least 2.
Sep 28 09:13:31.569 [warn] Rejecting insecure DH key [0]
Sep 28 09:13:31.569 [warn] Rejected invalid g!^x
Sep 28 12:13:14.071 [warn] DH key must be at least 2.
Sep 28 12:13:14.071 [warn] Rejecting insecure DH key [0]
Sep 28 12:13:14.071 [warn] Rejected invalid g!^x
Sep 28 19:41:23.658 [warn] DH key must be at least 2.
Sep 28 19:41:23.659 [warn] Rejecting insecure DH key [0]
Sep 28 19:41:23.659 [warn] Rejected invalid g!^x
And also on Debian Lenny with Tor 0.2.2.3-alpha:
Sep 30 07:50:05.236 [warn] DH key must be at least 2.
Sep 30 07:50:05.236 [warn] Rejecting insecure DH key [0]
Sep 30 07:50:05.236 [warn] Rejected invalid g!^x
Oct 06 02:51:08.319 [warn] DH key must be at least 2.
Oct 06 02:51:08.319 [warn] Rejecting insecure DH key [0]
Oct 06 02:51:08.319 [warn] Rejected invalid g!^x
Anoyone else seeing them?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonflyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1116'Stable' flag assignment inconsistant2020-06-27T14:09:47ZTom Lowenthal'Stable' flag assignment inconsistantLooking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/che...Looking at a consensus document [though I used torstatus.all.de for ease of sorting data] it seems that the 'stable' flag
is not being consistently assigned.
According to the v3 directory specification at https://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt ,
routers with a weighted MTBF more than either the median or seven days should be marked stable, and MTBF data more
than a month old shouldn't be that relevant when assigning the flag. Since the median uptime is about 3 days, one should
roughly expect that any router with more than 30 days of uptime (and which are still valid) should have the stable flag.
However when relays are sorted in order of uptime, several apparently-longrunning routers do not have the flag.
Since this data is liable to change as relays go up an down, here are some noted not-'stable' routers at the time of
writing. The routers have uptimes more than a month, so their (correctly) weighted MTBF should certainly be more than
a week, and more than the median, about three days.
wie6ud6be - 148d
anonymde - 112d
torpfaffenederorg - 110d
rentalsponge - 70d
xhyG5r96QGlRqL - 57d
niugnip - 56d
oeiwuqej - 49d
gremlin - 42d
editingconfigishard - 39d
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1117bridge authorities mark every bridge stable+guard2020-06-27T14:09:47ZRoger Dingledinebridge authorities mark every bridge stable+guardTonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operati...Tonga lists every bridge as Stable and Guard.
Nick suggests this is because "bridge authorities don't count a
bridge as having Failed for MTBF purposes when they find it to be
non-Running"
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedMatthew FinkelMatthew Finkelhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11180.2.2.4 fails to compile on osx x862020-06-27T14:09:47ZAndrew Lewman0.2.2.4 fails to compile on osx x86gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Dev...gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I/usr/local/include -I../or -O -g -mmacosx-version-min=10.4 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -Wall -g -O2 -fno-strict-aliasing -c test.c
test.c:46:18: error: test.h: No such file or directory
test.c: In function ‘test_buffers’:
test.c:181: warning: implicit declaration of function ‘test_fail’
test.c:184: warning: implicit declaration of function ‘test_eq’
test.c:196: warning: implicit declaration of function ‘test_memeq’
test.c:400: warning: label ‘done’ defined but not used
test.c: In function ‘test_onion_handshake’:
test.c:427: warning: implicit declaration of function ‘test_assert’
test.c:445: warning: implicit declaration of function ‘test_memneq’
test.c:447: warning: label ‘done’ defined but not used
test.c: In function ‘test_circuit_timeout’:
test.c:612: warning: label ‘done’ defined but not used
test.c: In function ‘test_policy_summary_helper’:
test.c:637: warning: implicit declaration of function ‘test_streq’
test.c:639: warning: label ‘done’ defined but not used
test.c: In function ‘test_policies’:
test.c:792: warning: label ‘done’ defined but not used
test.c: In function ‘test_rend_fns’:
test.c:998: warning: label ‘done’ defined but not used
test.c: In function ‘test_geoip’:
test.c:1071: warning: label ‘done’ defined but not used
test.c: At top level:
test.c:1076: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1076: warning: its scope is only this definition or declaration, which is probably not what you want
test.c: In function ‘legacy_test_setup’:
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1089: warning: ‘struct testcase_t’ declared inside parameter list
test.c:1096: error: variable ‘legacy_setup’ has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for ‘legacy_setup’)
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for ‘legacy_setup’)
test.c:1108: error: array type has incomplete element type
test.c:1116: error: ‘TT_SKIP’ undeclared here (not in a function)
test.c:1119: error: ‘END_OF_TESTCASES’ undeclared here (not in a function)
test.c:1121: error: array type has incomplete element type
test.c:1122: error: array type has incomplete element type
test.c:1123: error: array type has incomplete element type
test.c:1124: error: array type has incomplete element type
test.c:1125: error: array type has incomplete element type
test.c:1127: error: array type has incomplete element type
test.c:1135: error: ‘END_OF_GROUPS’ undeclared here (not in a function)
test.c: In function ‘main’:
test.c:1199: warning: implicit declaration of function ‘tinytest_main’
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]https://gitlab.torproject.org/tpo/core/tor/-/issues/1119Tor 0.2.2.4-alpha build failure2020-06-27T14:09:47ZAndrew LewmanTor 0.2.2.4-alpha build failuregcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .d...gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/Library/Tor/share\"" -DLOCALSTATEDIR="\"/Library/Tor/var\"" -DBINDIR="\"/Library/Tor\"" -I../../src/common -I../or -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT test.o -MD -MP -MF .deps/test.Tpo -c -o test.o test.c
test.c:46:18: test.h: No such file or directory
test.c: In function `test_buffers':
test.c:181: warning: implicit declaration of function `test_fail'
test.c:184: warning: implicit declaration of function `test_eq'
test.c:196: warning: implicit declaration of function `test_memeq'
test.c:400: warning: label `done' defined but not used
test.c: In function `test_onion_handshake':
test.c:427: warning: implicit declaration of function `test_assert'
test.c:445: warning: implicit declaration of function `test_memneq'
test.c:447: warning: label `done' defined but not used
test.c: In function `test_circuit_timeout':
test.c:612: warning: label `done' defined but not used
test.c: In function `test_policy_summary_helper':
test.c:637: warning: implicit declaration of function `test_streq'
test.c:639: warning: label `done' defined but not used
test.c: In function `test_policies':
test.c:792: warning: label `done' defined but not used
test.c: In function `test_rend_fns':
test.c:998: warning: label `done' defined but not used
test.c: In function `test_geoip':
test.c:1071: warning: label `done' defined but not used
test.c: In function `legacy_test_setup':
test.c:1078: error: dereferencing pointer to incomplete type
test.c: At top level:
test.c:1096: error: variable `legacy_setup' has initializer but incomplete type
test.c:1097: warning: excess elements in struct initializer
test.c:1097: warning: (near initialization for `legacy_setup')
test.c:1098: warning: excess elements in struct initializer
test.c:1098: warning: (near initialization for `legacy_setup')
test.c:1108: error: elements of array `test_array' have incomplete type
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1109: warning: excess elements in struct initializer
test.c:1109: warning: (near initialization for `test_array[0]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1110: warning: excess elements in struct initializer
test.c:1110: warning: (near initialization for `test_array[1]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1111: warning: excess elements in struct initializer
test.c:1111: warning: (near initialization for `test_array[2]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1112: warning: excess elements in struct initializer
test.c:1112: warning: (near initialization for `test_array[3]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1113: warning: excess elements in struct initializer
test.c:1113: warning: (near initialization for `test_array[4]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1114: warning: excess elements in struct initializer
test.c:1114: warning: (near initialization for `test_array[5]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: error: `TT_SKIP' undeclared here (not in a function)
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1116: warning: excess elements in struct initializer
test.c:1116: warning: (near initialization for `test_array[6]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: error: `TT_SKIP' undeclared here (not in a function)
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1117: warning: excess elements in struct initializer
test.c:1117: warning: (near initialization for `test_array[7]')
test.c:1119: error: `END_OF_TESTCASES' undeclared here (not in a function)
test.c:1119: error: initializer element is not constant
test.c:1119: error: (near initialization for `test_array[8]')
test.c:1127: error: elements of array `testgroups' have incomplete type
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1128: warning: excess elements in struct initializer
test.c:1128: warning: (near initialization for `testgroups[0]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1129: warning: excess elements in struct initializer
test.c:1129: warning: (near initialization for `testgroups[1]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1130: warning: excess elements in struct initializer
test.c:1130: warning: (near initialization for `testgroups[2]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1131: warning: excess elements in struct initializer
test.c:1131: warning: (near initialization for `testgroups[3]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1132: warning: excess elements in struct initializer
test.c:1132: warning: (near initialization for `testgroups[4]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1133: warning: excess elements in struct initializer
test.c:1133: warning: (near initialization for `testgroups[5]')
test.c:1135: error: `END_OF_GROUPS' undeclared here (not in a function)
test.c:1135: error: initializer element is not constant
test.c:1135: error: (near initialization for `testgroups[6]')
test.c: In function `main':
test.c:1199: warning: implicit declaration of function `tinytest_main'
../or/or.h: At top level:
test.c:1096: error: storage size of `legacy_setup' isn't known
make[4]: *** [test.o] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all] Error 2
make: *** [dist-osx] Error 2
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]https://gitlab.torproject.org/tpo/core/tor/-/issues/1121reason unexpected while uploading descriptor2020-06-27T14:09:47ZTracreason unexpected while uploading descriptorHi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks...Hi,
since i upgraded my relay to 0.2.2.5-alpha i am getting these warn message below.
Oct 12 13:15:10.985 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Oct 12 13:15:18.207 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Oct 12 13:15:18.207 [notice] Bootstrapped 100%: Done.
Oct 12 13:16:09.666 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:16:17.277 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Oct 12 13:16:18.508 [notice] Performing bandwidth self-test...done.
Oct 12 13:17:10.924 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Oct 12 13:23:16.169 [warn] http status 404 ("Not Found") reason unexpected while uploading descriptor to server '194.109.206.212:80').
Some kind of new bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: dragonflyTor: 0.3.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1122reachability and bandwidth tests are not carried over2020-06-27T14:09:46ZTracreachability and bandwidth tests are not carried overhello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not exe...hello, i run Kubuntu 9.10 x86 64 ,
commit 4b55ef26c93c5cadd866ca0be1e65547df7b6031 on branch origin/master 0.2.2.5 alpha
since last update, the tests of reachability and bandwidth are not carried over.. i think all tests are not executed for unknown reason .
i run as Bridge server
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1123Error parsing ListenAddress [::1]2020-06-27T14:09:46ZTracError parsing ListenAddress [::1]tor refuses to listen on an ipv6 address
Oct 15 18:33:37.140 [Notice] Tor v0.2.2.5-alpha (git-255245a2891cfa56). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] ...tor refuses to listen on an ipv6 address
Oct 15 18:33:37.140 [Notice] Tor v0.2.2.5-alpha (git-255245a2891cfa56). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Oct 15 18:33:37.250 [Warning] Port ":1]" out of range
Oct 15 18:33:37.312 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
Oct 15 18:33:37.312 [Notice] Opening OR listener on 0.0.0.0:9001
Oct 15 18:33:37.312 [Notice] Opening Directory listener on 0.0.0.0:9030
Oct 15 18:33:37.312 [Warning] Port ":1]" out of range
Oct 15 18:33:37.312 [Warning] Error parsing/resolving ListenAddress [::1]
Oct 15 18:33:37.312 [Notice] Opening Socks listener on 192.168.254.1:9050
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener OR listener on 0.0.0.0:9001
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener Directory listener on 0.0.0.0:9030
Oct 15 18:33:37.312 [Notice] Closing partially-constructed listener Socks listener on 192.168.254.1:9050
Oct 15 18:33:37.312 [Warning] Failed to parse/validate config: Failed to bind one of the listener ports.
Oct 15 18:33:37.312 [Error] Reading config failed--see warnings above.
my pc has full ipv6 connectivity as shown
netstat -on
TCP [::1]:8181 [::1]:1346 TIME_WAIT 0
TCP [::1]:8181 [::1]:1348 TIME_WAIT 0
TCP [::1]:8181 [::1]:1353 TIME_WAIT 0
TCP [::1]:8181 [::1]:1354 TIME_WAIT 0
TCP [::1]:8181 [::1]:1356 TIME_WAIT 0
TCP [::1]:8181 [::1]:1358 TIME_WAIT 0
TCP [::1]:8181 [::1]:1359 TIME_WAIT 0
TCP [::1]:8181 [::1]:1360 TIME_WAIT 0
TCP [::1]:8181 [::1]:1361 TIME_WAIT 0
TCP [::1]:8181 [::1]:1362 ESTABLISHED 1936
TCP [::1]:8181 [::1]:1363 ESTABLISHED 1936
TCP [::1]:8181 [::1]:1364 ESTABLISHED 1936
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:35656
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:43507
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:43600
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:44485
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:44638
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:45372
SYN_RECEIVED 5792
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:48601
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:54029
TIME_WAIT 0
TCP [2001:470:7:ff::2]:30806 [2001:41e0:ff16:0:224:81ff:fe36:25fc]:56457
TIME_WAIT 0
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: crpTor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1124Proxy error 504 connecting hidden serrvice2020-06-27T14:09:46ZTracProxy error 504 connecting hidden serrvicethis url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software...this url used to works OK
http://3xofiggysc6rgygv.onion:8181/
this is yacy hidden search engine, available for all tor users.
use: well , to seach for objectionable things , et all
However stopped working after I update tor software
the error is
[code]
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
The following error occurred while trying to access http://3xofiggysc6rgygv.onion:8181/:
504 Connect to 3xofiggysc6rgygv.onion:8181 failed: SOCKS error: host unreachable
Generated Fri, 16 Oct 2009 21:34:47 E. South America Standard Time by Polipo on localhost:8118.
[/code]
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: crphttps://gitlab.torproject.org/tpo/core/tor/-/issues/1125(*chp)->next assertion fail?2020-06-27T14:09:46ZRoger Dingledine(*chp)->next assertion fail?I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_...I found this on irc. So I have no idea if it's for real. The person indicated
it was on 0.2.2.5-alpha.
[Info] buf_shrink_freelists():
Cleaning freelist for 4096-byte chunks: keeping 9, dropping 1.
[Error] Bug: buffers.c:269: buf_shrink_freelists: Assertion
(*chp)->next fail
He also said "polipo still not starting with vidalai 2.5", so I'm thinking
probably Windows.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1126Error from libevent setting read event state for 10232020-06-27T14:09:46ZTracError from libevent setting read event state for 1023Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/Tor...Hello,
This morning i have a error in my log:
oct. 18 11:23:48.810 [Warning] Error from libevent setting read event state for 1023 to watched: No such file or directory
oct. 18 11:23:58.355 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:58.355 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:23:59.291 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:23:59.291 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:01.577 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:01.577 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:02.724 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:02.725 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:04.593 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:04.594 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
oct. 18 11:24:05.923 [Warning] Couldn't open "/home/moonlights/TorTeamHelp/state.tmp" (/home/moonlights/TorTeamHelp/state) for writing: Too many open files
oct. 18 11:24:05.923 [Warning] Unable to write state to file "/home/moonlights/TorTeamHelp/state"
i run Kubuntu KArmic 9.10 x86 64 on 64 bits 4 cores
Tor origin/master commit 5ef97ddd42dfd51fc296bb51b612780aec09c5c7
torrc spec: ports exit policy reject all */*
libevent + libevent extra 1.4.2 1.4.11-stable-1 (amd64)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1127no shutdown descriptor published when ORPort is closed but client stays up2020-06-27T14:09:46ZNick Mathewsonno shutdown descriptor published when ORPort is closed but client stays up(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha ...(Posted by request from Scott Bennett.)
Category: tor router -> tor client
Operating System: observed on FreeBSD 7.2-STABLE
Reported Version: 0.2.2.3-alpha
Title: no shutdown descriptor published when ORPort is closed but client stays up
Reported By: Scott Bennett
Description: When tor is running as both a router and a client, if a SIGINT
is sent to tor, tor closes the ORPort (and DirPort if applicable),
publishes a shutdown descriptor (i.e., a new descriptor in which the
"observed maximum 10s data rate in previous 24 hrs" is set to 0 to
discourage further attempts to include the node in new circuits), and
proceeds with the rest of the shutdown procedure. However, given the
same starting conditions, if the ORPort line in torrc is commented out
and a SIGHUP is sent to tor, tor will read the updated torrc, notice
that the ORPort is no longer to be used, close the ORPort (and DirPort
if applicable), and continue operation as a client process *without*
publishing a shutdown procedure. This situation results in many
unnecessary attempts by clients and routers to connect to the ORPort
(and DirPort if applicable) after it has been closed, wasting time and
causing avoidable circuit construction failures. This was observed in
tor 0.2.2.3-alpha. I haven't yet tried it in 0.2.2.5-alpha.
[Automatically added by flyspray2trac: Operating System: BSD]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1136When Tor is offline, it doesn't quite run out of relays, so doesn't realize i...2020-06-27T14:09:46ZRoger DingledineWhen Tor is offline, it doesn't quite run out of relays, so doesn't realize it's offlineIf your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actua...If your Tor client goes offline, it will keep trying to establish circuits,
and as each TLS connection fails, it will mark that relay down.
In update_router_have_minimum_dir_info() Tor checks whether (num_present < 2)
but we never actually mark down the last few relays, either because we don't
have enough left to make a circuit so we don't ever try another TLS connection,
or because none of the remaining relays are suitable exit nodes so we can't
pick a path that would be a useful circuit so we don't try.
I think we need to catch the case where we failed to pick a path because we
don't have enough circuits, and if it case occurs and many of our relays are
marked down, we should mark them up.
That will cause us to attempt circuits for a lot longer than currently, but on
the other hand Tor will actually work when you come back to the network and
try to make a new application request.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1137Mac OS X Tor crash2020-06-27T14:09:46ZcypherpunksMac OS X Tor crashI'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: ...I'm running Vidalia 0.2.4 with Tor 0.2.2.3-alpha (git-0f3417d1dbffdf7a). It appears that Mr. Mike Perry has caused some bugs with his circuit build time "improvements" in Tor. :-)
Here's the crash log:
Process: tor [204]
Path: /Applications/Vidalia.app/Contents/MacOS/tor
Identifier: tor
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: Vidalia [188]
Interval Since Last Report: 2883864 sec
Crashes Since Last Report: 2
Per-App Interval Since Last Report: 0 sec
Per-App Crashes Since Last Report: 2
Date/Time: 2009-10-25 21:40:30.778 -0700
OS Version: Mac OS X 10.5.8 (9L31a)
Report Version: 6
Anonymous UUID: 40FE94CF-131D-4773-90D7-DCB7EFF18865
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread: 0
Thread 0 Crashed:
0 libSystem.B.dylib 0x91a70e42 __kill + 10
1 libSystem.B.dylib 0x91ae323a raise + 26
2 libSystem.B.dylib 0x91aef679 abort + 73
3 tor 0x0000db0e circuit_build_times_parse_state + 958
4 tor 0x0002131a or_state_load + 602
5 tor 0x00022435 options_act + 3285
6 tor 0x0002267d set_options + 365
7 tor 0x000263c7 options_init_from_string + 567
8 tor 0x000267f6 options_init_from_torrc + 694
9 tor 0x0006f453 tor_init + 259
10 tor 0x000735d3 tor_main + 67
11 tor 0x00001ee2 _start + 216
12 tor 0x00001e09 start + 41
Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x00000000 ebx: 0x91aef639 ecx: 0xbfffeffc edx: 0x91a70e42
edi: 0x000e5e80 esi: 0x000e5fd8 ebp: 0xbffff018 esp: 0xbfffeffc
ss: 0x0000001f efl: 0x00000286 eip: 0x91a70e42 cs: 0x00000007
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037
cr2: 0xa02e1690
Binary Images:
0x1000 - 0x11bfef +tor ??? (???) <d67657b9b5e05c547bfeb1ac91c0ad69> /Applications/Vidalia.app/Contents/MacOS/tor
0x8fe00000 - 0x8fe2db43 dyld 97.1 (???) <458eed38a009e5658a79579e7bc26603> /usr/lib/dyld
0x90676000 - 0x9067dfe9 libgcc_s.1.dylib ??? (???) <f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0x91a02000 - 0x91b69ff3 libSystem.B.dylib ??? (???) <ae47ca9b1686b065f8ac4d2de09cc432> /usr/lib/libSystem.B.dylib
0x940b2000 - 0x94164ffb libcrypto.0.9.7.dylib ??? (???) <9d714c92872a93dd127ea8556b2c8945> /usr/lib/libcrypto.0.9.7.dylib
0x94cd6000 - 0x94cfafeb libssl.0.9.7.dylib ??? (???) <8084593b773bec8f2b9614fd23c5ed73> /usr/lib/libssl.0.9.7.dylib
0x9529e000 - 0x952acffd libz.1.dylib ??? (???) <5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
0x9608c000 - 0x96090fff libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib
0xffff0000 - 0xffff1780 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib
Here's my system info:
Model: Macmini2,1, BootROM MM21.009A.B00, 2 processors, Intel Core 2 Duo, 2 GHz, 1 GB
Graphics: kHW_IntelGMA950Item, GMA 950, spdisplays_builtin, spdisplays_integrated_vram
Memory Module: global_name
AirPort: spairport_wireless_card_type_airport_extreme (0x168C, 0x86), 1.4.16.2
Bluetooth: Version 2.1.8f2, 2 service, 1 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Serial ATA Device: Hitachi HTS541612J9SA00, 111.79 GB
Parallel ATA Device: PIONEER DVD-RW DVR-K06
USB Device: My Book, (null) mA
USB Device: Extreme III USB2.0 Reader/Writer, (null) mA
USB Device: Back-UPS ES 550 FW:840.B2.D USB FW:B2, (null) mA
USB Device: Apple Optical USB Mouse, (null) mA
USB Device: Bluetooth USB Host Controller, (null) mA
USB Device: IR Receiver, (null) mA
Tor crashes every time that I attempt to start it with Vidalia:
Oct 25 21:46:26.909 [Notice] Tor v0.2.2.3-alpha (git-0f3417d1dbffdf7a). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin i386)
Oct 25 21:46:26.910 [Notice] Initialized libevent version 1.4.12-stable using method kqueue. Good.
Oct 25 21:46:26.910 [Notice] Opening OR listener on 0.0.0.0:9001
Oct 25 21:46:26.910 [Notice] Opening Directory listener on 0.0.0.0:9030
Oct 25 21:46:26.911 [Notice] Opening Socks listener on 127.0.0.1:9050
Oct 25 21:46:26.911 [Notice] Opening Control listener on 127.0.0.1:9051
Oct 25 21:46:26.912 [Error] Bug: circuitbuild.c:380: circuit_build_times_shuffle_array: Assertion cbt->total_build_times == cbt->build_times_idx failed; aborting.
If I remove the state file from my ~/.tor/ directory, I am able to start Tor as expected. I do however expect it to crash or have this problem again at some point. I sadly unlinked the state file or I would have included it in this bug report.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]https://gitlab.torproject.org/tpo/core/tor/-/issues/1138If bridge authority is unreachable, client doesn't fallback to bridge2020-06-27T14:09:45ZRoger DingledineIf bridge authority is unreachable, client doesn't fallback to bridgeWhen a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authori...When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is
set (which it is when Vidalia configures you to use a bridge), Tor will go to
the authority first and look up the bridge by fingerprint.
If the bridge authority doesn't have the bridge, or Tor doesn't know the
fingerprint, then Tor will fall back to asking the bridge directly.
If the bridge authority is filtered, though, then Tor will never notice that
the bridge authority lookup failed. So it will never fall back. Fail.
Our workaround for now is to stop giving out fingerprints via bridgedb.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalRobert HoganRobert Hoganhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1139alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Asser...2020-06-27T14:09:45Zweasel (Peter Palfrader)alpha gcc bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failedHi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypt...Hi,
on alpha, in 0.2.2.4 and latest git the testsuite fails with:
[sid] weasel@albeniz:~/tmp/tor$ ./src/test/test --info
Oct 26 09:07:09.931 [info] crypto_global_init(): NOT using OpenSSL engine support.
Oct 26 09:07:09.932 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
Oct 26 09:07:09.934 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
buffers: OK
onion_handshake: OK
circuit_timeout: Oct 26 09:07:10.206 [err] Bug: circuitbuild.c:608: circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
circuitbuild.c:608 circuit_build_times_generate_sample: Assertion q_lo < q_hi failed; aborting.
zsh: abort (core dumped) ./src/test/test --info
See also http://experimental.ftbfs.de/fetch.php?pkg=tor&arch=alpha&ver=0.2.2.4-alpha-1&stamp=1255305733&file=log&as=raw
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1141bug in networkstatus.c using 0.2.1.202020-06-27T14:09:45ZTracbug in networkstatus.c using 0.2.1.20Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
Dat...Here is the config from the Tor client where the crash is happening:
TestingTorNetwork 1
DirServer bridgedirauth v3ident=3C1DA30FB6C8760E43C89ED36A700F429C5763E5 orport=443 172.16.234.136:995 B8F4F6B623E787C47A70111E7E5DE4A53A7A1840
DataDirectory /root/.tor/
UseBridges 1
Bridge 172.16.234.136:443
ClientOnly 1
Here is the output from Tor when the bug happens:
(gdb) run -f torrc log info
Starting program: /root/tor-0.2.1.20/src/or/tor -f torrc log info
Oct 31 19:18:12.716 [notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on OpenBSD amd64)
Oct 31 19:18:12.720 [warn] You have used DirServer or AlternateDirAuthority to specify alternate directory authorities in your configuration. This is potentially dangerous: it can make you look different from all other Tor users, and hurt your anonymity. Even if you've specified the same authorities as Tor uses by default, the defaults could change in the future. Be sure you know what you're doing.
Oct 31 19:18:12.720 [warn] TestingTorNetwork is set. This will make your node almost unusable in the public Tor network, and is therefore only advised if you are building a testing Tor network!
Oct 31 19:18:12.721 [notice] Initialized libevent version 1.3e using method kqueue. Good.
Oct 31 19:18:12.721 [notice] Opening Socks listener on 127.0.0.1:9050
Oct 31 19:18:12.723 [info] tor_lockfile_lock(): Locking "/root/.tor//lock"
Oct 31 19:18:12.723 [info] or_state_load(): Loaded state from "/root/.tor//state"
Oct 31 19:18:12.724 [info] read_file_to_str(): Could not open "/root/.tor//router-stability": No such file or directory
Oct 31 19:18:12.725 [info] geoip_load_file(): Failed to open GEOIP file /usr/local/share/tor/geoip.
Oct 31 19:18:12.725 [warn] You are running Tor as root. You don't need to, and you probably shouldn't.
Oct 31 19:18:12.744 [info] crypto_seed_rng(): Seeding RNG from "/dev/srandom"
Oct 31 19:18:12.798 [info] Bootstrapped 0%: Starting.
Oct 31 19:18:12.800 [info] trusted_dirs_load_certs_from_string(): Adding cached certificate for directory authority bridgedirauth with signing key F554586AA4C6DFB571A33EEBA89D9D48A94B618B
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//cached-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/root/.tor//unverified-consensus": No such file or directory
Oct 31 19:18:12.800 [info] read_file_to_str(): Could not open "/usr/local/share/tor/fallback-consensus": No such file or directory
Oct 31 19:18:12.801 [info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
Oct 31 19:18:12.801 [info] router_load_routers_from_string(): 1 elements to add
Oct 31 19:18:12.801 [info] add_an_entry_guard(): Chose 'bridgedirauth' as new entry guard.
Oct 31 19:18:12.802 [info] log_entry_guards(): bridgedirauth (down never-contacted)
Oct 31 19:18:12.802 [notice] new bridge descriptor 'bridgedirauth' (cached)
Oct 31 19:18:12.802 [info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
Oct 31 19:18:12.802 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.803 [info] onion_pick_cpath_exit(): Using requested exit node 'bridgedirauth'
Oct 31 19:18:12.803 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Router not connected (nothing is). Connecting.
Oct 31 19:18:12.803 [notice] Bootstrapped 5%: Connecting to directory server.
Oct 31 19:18:12.803 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.804 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.804 [info] directory_send_command(): Downloading consensus from 172.16.234.136:443 using /tor/status-vote/current/consensus.z
Oct 31 19:18:12.805 [info] router_load_routers_from_string(): 0 elements to add
Oct 31 19:18:12.805 [info] tor_mmap_file(): Could not open "/root/.tor//cached-extrainfo" for mmap(): No such file or directory
Oct 31 19:18:12.805 [notice] I learned some more directory information, but not enough to build a circuit: We have no network-status consensus.
Oct 31 19:18:12.806 [info] connection_ap_make_link(): Making internal direct tunnel to [scrubbed]:443 ...
Oct 31 19:18:12.806 [info] onion_pick_cpath_exit(): Using requested exit node '0000000000000000000000000000000000000000'
Oct 31 19:18:12.806 [info] circuit_handle_first_hop(): Next router is [scrubbed]: Not connected. Connecting.
Oct 31 19:18:12.806 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] get_interface_address6(): connect() failed: Invalid argument
Oct 31 19:18:12.807 [info] connection_ap_make_link(): ... application connection created and linked.
Oct 31 19:18:12.809 [info] or_state_save(): Saved state to "/root/.tor//state"
Oct 31 19:18:12.809 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Oct 31 19:18:12.810 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Oct 31 19:18:12.866 [info] connection_or_check_valid_tls_handshake(): Connected to router $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840 at 172.16.234.136:443 without knowing its key. Hoping for the best.
Oct 31 19:18:12.867 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.868 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE_FAST cell to 'bridgedirauth'
Oct 31 19:18:12.868 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.869 [info] command_process_versions_cell(): Negotiated version 2 with [scrubbed]:443; sending NETINFO.
Oct 31 19:18:12.869 [info] command_process_netinfo_cell(): Got good NETINFO cell from [scrubbed]:443; OR connection is now open, using protocol version 2
Oct 31 19:18:12.910 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.910 [info] exit circ (length 1, exit bridgedirauth): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.910 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.910 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Oct 31 19:18:12.910 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.911 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23920
Oct 31 19:18:12.911 [info] circuit_finish_handshake(): Finished building fast circuit hop:
Oct 31 19:18:12.911 [info] exit circ (length 1, exit 0000000000000000000000000000000000000000): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] circuit_send_next_onion_skin(): circuit built!
Oct 31 19:18:12.912 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.912 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket -1, n_circ_id 23921
Oct 31 19:18:12.913 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.914 [info] exit circ (length 1): $B8F4F6B623E787C47A70111E7E5DE4A53A7A1840(open)
Oct 31 19:18:12.914 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Oct 31 19:18:12.915 [info] connection_edge_process_relay_cell_not_open(): 'connected' received after 0 seconds.
Oct 31 19:18:12.915 [info] exit circ (length 1): $0000000000000000000000000000000000000000(open)
Oct 31 19:18:12.915 [notice] Bootstrapped 50%: Loading relay descriptors.
Oct 31 19:18:12.916 [info] connection_edge_process_relay_cell(): -1: end cell (closed normally) for stream 44628. Removing stream.
Oct 31 19:18:12.917 [info] _connection_free(): Freeing linked Socks connection [open] with 0 bytes on inbuf, 0 on outbuf.
Oct 31 19:18:12.918 [info] connection_dir_client_reached_eof(): Received consensus directory (size 1367) from server '172.16.234.136:443'
Oct 31 19:18:12.918 [info] 0 unknown, 0 missing key, 1 good, 0 bad, 0 no signature, 1 required
Oct 31 19:18:12.919 [err] Bug: networkstatus.c:1164: update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
networkstatus.c:1164 update_consensus_networkstatus_fetch_time: Assertion start+dl_interval < c->valid_until failed; aborting.
Here is the backtrace from this crashed process:
(gdb) backtrace
#0 0x000000020c37137a in kill () from /usr/lib/libc.so.51.0
#1 0x000000020c3bd765 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legacy/trac#2 0x000000000045cb81 in update_consensus_networkstatus_fetch_time (now=1257016692) at networkstatus.c:1183
legacy/trac#3 0x000000000045d29d in networkstatus_set_current_consensus (
consensus=0x20f769800 "network-status-version 3\nvote-status consensus\nconsensus-method 5\nvalid-after 2009-10-31 19:15:00\nfresh-until 2009-10-31 19:20:00\nvalid-until 2009-10-31 19:30:00\nvoting-delay 20 20\nclient-versions \nse"..., flags=0) at networkstatus.c:1527
legacy/trac#4 0x000000000043feac in connection_dir_client_reached_eof (conn=0x2088f0d00) at directory.c:1638
legacy/trac#5 0x000000000044061e in connection_dir_reached_eof (conn=0x2088f0d00) at directory.c:2040
legacy/trac#6 0x000000000042626f in connection_handle_read (conn=0x2088f0d00) at connection.c:2037
legacy/trac#7 0x0000000000457b91 in conn_read_callback (fd=8833, event=6, _conn=0x37b7) at main.c:456
legacy/trac#8 0x000000020377f2e2 in event_process_active (base=0x201cfdc00) at /usr/src/lib/libevent/event.c:333
legacy/trac#9 0x000000020377f501 in event_base_loop (base=0x201cfdc00, flags=1) at /usr/src/lib/libevent/event.c:450
legacy/trac#10 0x000000020377f3b5 in event_loop (flags=8833) at /usr/src/lib/libevent/event.c:383
legacy/trac#11 0x0000000000459726 in do_main_loop () at main.c:1444
legacy/trac#12 0x000000000045a88b in tor_main (argc=5, argv=0x7f7fffff1850) at main.c:2070
legacy/trac#13 0x000000000040702c in ___start ()
legacy/trac#14 0x0000000000000005 in ?? ()
legacy/trac#15 0x00007f7fffff1d00 in ?? ()
legacy/trac#16 0x00007f7fffff1d1e in ?? ()
legacy/trac#17 0x00007f7fffff1d21 in ?? ()
legacy/trac#18 0x00007f7fffff1d27 in ?? ()
legacy/trac#19 0x00007f7fffff1d2b in ?? ()
legacy/trac#20 0x0000000000000000 in ?? ()
The configs used for the servers in this network can be found here: http://pastebin.com/m65b5da00
I'd also be keen to hear if the configs I have for such a network actually make sense, and that I haven't forgotten something crucial when testing Tor.
Thanks
mikeb
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mikebTor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1143Tor can't start if DNS Port enabled in torrc2020-06-27T14:09:45ZTracTor can't start if DNS Port enabled in torrcHello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
U...Hello,
Today i updated my tor origin/master 0.2.2.5 alpha commit 69c0147ea6725a63f254333867c0504528c62daf and i was unable to start tor.
I run kubuntu karmic 9.10 on x86 64, kernel: 2.6.31-15-generic and libevent 2.0.2 alpha Path: .
URL: https://levent.svn.sourceforge.net/svnroot/levent/trunk/libevent
Repository Root: https://levent.svn.sourceforge.net/svnroot/levent
Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1516
Node Kind: directory
Schedule: normal
Last Changed Author: nickm
Last Changed Rev: 1516
Last Changed Date: 2009-11-06 22:46:57 +0100 (ven, 06 nov 2009)
After a few hours , i have found that was the "DNSPort xx DNS , ListenAddress 127.0.0.1:xxxx " when enabled who crash tor at start.
If i disable it, it start normally .
i have already report in libevent bug tracker the 2 kernel errors found in my log but give info here while i dunno what cause it.
2009-11-08 21:40:22 moon kernel [ 6907.854009] tor[11345]: segfault at 0 ip 00007f39cf943b18 sp 00007fff6dd87860 error 4 in libevent.so.2.0.0[7f39cf929000+40000]
2009-11-08 21:41:10 moon kernel [ 6955.458940] tor[11355]: segfault at 0 ip 00007f8ae258bb18 sp 00007fff58df22a0 error 4 in libevent.so.2.0.0[7f8ae2571000+40000]
best regards
SwissTorExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1144tor bridge can not work with openssl 0.9.8l2020-06-27T14:09:45ZTractor bridge can not work with openssl 0.9.8lDescription:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way with...Description:
After upgrade to openssl-0.9.8l which fixed the MTM attack (for reference see https://bugzilla.redhat.com/show_bug.cgi?id=533125) by disabling renegotiating, tor(using bridge) stops working.
Tor should find another way without renegotiating. For linux distributions, enabling a known insecure feature is not an option.
Tor log:
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 5%: Connecting to directory server.
Nov 10 14:31:15 cruiser Tor[9287]: Bootstrapped 10%: Finishing handshake with directory server.
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: TLS error: unexpected close while renegotiating
Nov 10 14:31:16 cruiser Tor[9287]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 7; recommendation warn)
reference:
http://bugs.archlinux.org/task/17088
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: lymanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1145Tor fails to load auth-certs2020-06-27T14:09:45ZTracTor fails to load auth-certsUsed the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Tra...Used the Tor Browser Bundle 1.2.9 under Windows 7 x64 German.
Worked smoothly, but today it was unable to build a circuit. Log and the Tor-Data is attached.
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: knappoTor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1147mlockall prevents compile for Android2020-06-27T14:09:45ZJacob Appelbaummlockall prevents compile for Androidbionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...bionic doesn't have an actual implementation of mlockall();
mlockall() is merely in the headers but not actually in the library.
This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1148mlockall prevents compile for Android2020-06-27T14:09:45ZJacob Appelbaummlockall prevents compile for Androidbionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2t...bionic doesn't have an actual implementation of mlockall(); mlockall() is merely in the headers but not actually in the library. This prevents Tor compilation with the bionic libc for Android handsets.
[Automatically added by flyspray2trac: Operating System: All]Jacob AppelbaumJacob Appelbaumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1150Tor crash on FreeBSD2020-06-27T14:09:44ZTracTor crash on FreeBSDTor crashes at random times, sometimes it will last days or even weeks, sometimes only a few hours until a crash.
This has been going on for a while over the past few months with various tor versions.
I just now got around to compiling ...Tor crashes at random times, sometimes it will last days or even weeks, sometimes only a few hours until a crash.
This has been going on for a while over the past few months with various tor versions.
I just now got around to compiling it with debug symbols.
This is the gdb from the crash today, its my first crash since compiling with debug so im not sure if it always crashes in the same place, I will update the bug on the next crash.
I'm not sure if I am doing this right, let me know if you need me to provide some different info.
OS is FreeBSD 7.2 32bit.
# gdb /usr/local/bin/tor tor.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd"...
Core was generated by `tor'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libz.so.4...done.
Loaded symbols for /lib/libz.so.4
Reading symbols from /usr/local/lib/libevent-1.4.so.3...done.
Loaded symbols for /usr/local/lib/libevent-1.4.so.3
Reading symbols from /usr/local/lib/libssl.so.5...done.
Loaded symbols for /usr/local/lib/libssl.so.5
Reading symbols from /usr/local/lib/libcrypto.so.5...done.
Loaded symbols for /usr/local/lib/libcrypto.so.5
Reading symbols from /lib/libthr.so.3...done.
Loaded symbols for /lib/libthr.so.3
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/lib/librt.so.1...done.
Loaded symbols for /usr/lib/librt.so.1
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 set_streams_blocked_on_circ (circ=Variable "circ" is not available.
) at relay.c:1764
1764 relay.c: No such file or directory.
in relay.c
[New Thread 0x28501040 (LWP 100379)]
(gdb) bt
#0 set_streams_blocked_on_circ (circ=Variable "circ" is not available.
) at relay.c:1764
#1 0x080b5774 in connection_or_flush_from_first_active_circuit (conn=0x28dedbb0, max=1, now=1258328897) at relay.c:1832
legacy/trac#2 0x0807c73b in connection_or_flushed_some (conn=0x28dedbb0) at connection_or.c:293
legacy/trac#3 0x0806f3b4 in connection_flushed_some (conn=0x28dedbb0) at connection.c:2832
legacy/trac#4 0x080731ad in connection_handle_write (conn=0x28dedbb0, force=0) at connection.c:2385
legacy/trac#5 0x080ab249 in conn_write_callback (fd=164, events=4, _conn=0x28dedbb0) at main.c:488
legacy/trac#6 0x28187692 in event_base_loop () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#7 0x281879c9 in event_loop () from /usr/local/lib/libevent-1.4.so.3
legacy/trac#8 0x080aaf49 in do_main_loop () at main.c:1444
legacy/trac#9 0x080ab167 in tor_main (argc=11, argv=0xbfbfec08) at main.c:2070
legacy/trac#10 0x080e8a02 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:30
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: foundbughttps://gitlab.torproject.org/tpo/core/tor/-/issues/1153dirvote.c writes to stdout2020-06-27T14:09:44ZRoger Dingledinedirvote.c writes to stdoutnetworkstatus_add_detached_signatures() has a bunch of puts() lines, e.g.
puts("A"). It also has some printf lines, etc.
I can get rid of them. But perhaps you meant to convert them into log lines?
[Automatically added by flyspray2trac...networkstatus_add_detached_signatures() has a bunch of puts() lines, e.g.
puts("A"). It also has some printf lines, etc.
I can get rid of them. But perhaps you meant to convert them into log lines?
[Automatically added by flyspray2trac: Operating System: All]0.2.2.6-alphaNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1155memset on mem or memset on circ?2020-06-27T14:09:44ZRoger Dingledinememset on mem or memset on circ?ABCD> "memset(circ, 0xAA, memlen)" and "memset(conn, 0xAA, memlen)"
theoretically incorrect. It should be "memset (mem, 0xAA, memlen)" instead.
> ABCD: ah. we're not poisoning all of it, because we're starting at the wrong
location?
ABCD...ABCD> "memset(circ, 0xAA, memlen)" and "memset(conn, 0xAA, memlen)"
theoretically incorrect. It should be "memset (mem, 0xAA, memlen)" instead.
> ABCD: ah. we're not poisoning all of it, because we're starting at the wrong
location?
ABCD> no, it's right becaouse offset zero. but actually circ and or_circ not
the same
> ah. yeah. i was just checking out TO_ORIGIN_CIRCUIT() to make sure the
offset is zero
> so the suggestion is to change it to mem, in case one day we make the offset
not zero?
ABCD> yes, at least DOWNCAST(or_connection_t, c) exist for something.
> explain that second part?
ABCD> as result it STRUCT_OFFSET(subtype, basemember) which zero if offset
strictly is zero.
> we're probably screwed in plenty of other places if we make _base not the
first element of these structs.
> also, why the heck are we poisoning the two types of structs with exactly
the same byte?
> shouldn't one of them by AB or something?
> 0xCC would probably make us happier
ABCD> I found only those two cases, introduced by r13414.
> ah. those are the commits we added when the cold boot attacks were first
known to us but hadn't been made public yet.
> we made sure to scribble on anything that might be sensitive, when we're
done using it.
> i do wonder how many compilers optimize it out, though.
> in fact. are the compilers more likely to optimize it out when we memset mem
and then free mem?
> whereas they'll leave it in if we memset circ and then free mem?
ABCD> compilers so smart this days, who knows.
So, three questions to ponder.
First: should we change circ and conn to mem in these two cases, to make it
clearer which struct we're clobbering? I would say yes.
Second: should we leave circ and conn alone, in hopes that the more complex
code is more likely to fool the compiler into not optimizing the code out?
I would say yes.
Third: should we change one of the AA's into CC, to reduce the chance that
one day we see AA in memory and realize we don't know which struct we're
looking at? I would say yes.
I think my 'yes' on #1 and legacy/trac#2 are incompatible, and I think yes for #1 should
take priority.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1158[info] circuit_testing_failed() on Fedora 122020-06-27T14:09:44ZTrac[info] circuit_testing_failed() on Fedora 12Working Fedora 11 setup with 0.2.1.20 upgraded to Fedora 12.
Rebuilt tor because of newer OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Tor keeps mentioning:
[info] circuit_testing_failed(): Our testing circuit (to see if your ORPort is reachable...Working Fedora 11 setup with 0.2.1.20 upgraded to Fedora 12.
Rebuilt tor because of newer OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Tor keeps mentioning:
[info] circuit_testing_failed(): Our testing circuit (to see if your ORPort is reachable) has failed. I'll try again later.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/tpo/core/tor/-/issues/1160AllowSingleHopExits setting can be bypassed by client2020-06-27T14:09:44ZTracAllowSingleHopExits setting can be bypassed by clientUsing the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but thi...Using the software Tortunnel
http://www.thoughtcrime.org/software/tortunnel/
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).
Maybe i'm being alarmist, but this seems like abuse waiting to happen -
a disaster for exit node operators and for network capacity re:p2p.
If this isnt fixable in a few days i'll be switching to non-exit.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1162cant start a relay2020-06-27T14:09:44ZTraccant start a relayHello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experi...Hello . I just tried your software. It works ok as long as I use it as a client but not if I try to relay : it crashes every time, it says tor as unexpedly exits.
here the log :
déc. 02 19:20:13.594 [Notice] Tor v0.2.1.20. This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
déc. 02 19:20:15.454 [Notice] Initialized libevent version 1.4.12-stable using method win32. Good.
déc. 02 19:20:15.454 [Notice] Opening Socks listener on 127.0.0.1:9050
déc. 02 19:20:15.454 [Notice] Opening Control listener on 127.0.0.1:9051
déc. 02 19:20:28.766 [Notice] Parsing GEOIP file.
déc. 02 19:20:28.766 [Notice] We now have enough directory information to build circuits.
déc. 02 19:20:28.766 [Notice] Bootstrapped 80%: Connecting to the Tor network.
déc. 02 19:20:28.766 [Notice] Bootstrapped 85%: Finishing handshake with first hop.
déc. 02 19:20:28.766 [Notice] Bootstrapped 90%: Establishing a Tor circuit.
déc. 02 19:20:28.766 [Notice] Tor has successfully opened a circuit. Looks like client functionality is working.
déc. 02 19:20:28.766 [Notice] Bootstrapped 100%: Done.
déc. 02 19:20:28.766 [Notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
déc. 02 19:20:28.766 [Notice] Opening OR listener on 0.0.0.0:443
déc. 02 19:20:28.766 [Notice] Opening Directory listener on 0.0.0.0:9030
déc. 02 19:20:28.766 [Notice] Your Tor server's identity key fingerprint is 'Unnamed AC09D7B124DE36F537AD17F586BF41C397F0B67F'
déc. 02 19:20:28.766 [Error] libevent call with win32 failed: Socket operation on nonsocket [WSAENOTSOCK ] [10038]
No matter what I try the last line always occur and crash the software.
Im under xp sp3 pro.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tedtedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1172ORPort found reachable, but I have no routerinfo2020-06-27T14:09:44ZTracORPort found reachable, but I have no routerinfoHello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_f...Hello,
Today i update the git version on master branch : commit d086c9a7f73ce5b9b7cf4add07fa7d071b829081
Merge: 9e6225a 28b29e0
and a bug are signaled on my log about the "router_or:port"
déc. 12 17:00:28.456 [Warning] router_orport_found_reachable(): Bug: ORPort found reachable, but I have no routerinfo yet. Failing to inform controller of success.
libevent: 2.03 alpha Repository UUID: ce677c24-8c1a-0410-9497-a30ef3a96221
Revision: 1557
libc6: 2.10.1 (ubuntu15) (amd64)
OS: kubuntu karmic 9.10 on x86 64 ,Linux moon 2.6.31-17-generic legacy/trac#54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
vidalia: 2.7svn Repository UUID: 819a2799-b909-0410-be78-af92f3896072
Revision: 4177
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1173crypto.c:613: error: comparison of unsigned expression >= 0 is always true2020-06-27T14:09:44ZRoger Dingledinecrypto.c:613: error: comparison of unsigned expression >= 0 is always truehttps://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-ar...https://buildbot.vidalia-project.net/builders/kore.fc12.tor-master/builds/0/steps/compile/logs/stdio
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -g -O2 -Wall -g -O2 -fno-strict-aliasing -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wbad-function-cast -Wswitch-enum -Werror -Winit-self -Wmissing-field-initializers -Wdeclaration-after-statement -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id -Woverride-init -Wstrict-overflow=1 -Wextra -Warray-bounds -MT crypto.o -MD -MP -MF .deps/crypto.Tpo -c -o crypto.o crypto.c
cc1: warnings being treated as errors
crypto.c: In function ‘crypto_pk_write_key_to_string_impl’:
crypto.c:613: error: comparison of unsigned expression >= 0 is always true
make[3]: *** [crypto.o] Error 1
Line is
tor_assert(buf->length >= 0);
where buf is
BUF_MEM *buf;
I bet fc12's openssl has a different BUF_MEM.
edmanm> [edmanm@kore ~]$ openssl version
edmanm> OpenSSL 1.0.0-fips-beta4 10 Nov 2009
Sebastian> the line hasn't been changed since r2461
Nick, any opinions?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1175Current Tor bundle crashing on Mac OS X 10.4.11/Intel2020-06-27T14:09:43ZTracCurrent Tor bundle crashing on Mac OS X 10.4.11/IntelI'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
...I'm downloading the regular recommended Tor bundle from the web site. When it crashes, I find this in the Vidalia log:
http://pastebin.com/m35b7f26d
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: wAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1176server_port_flush looks strange2020-06-27T14:09:43ZSebastian Hahnserver_port_flush looks strangeCoverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can neve...Coverity (cid 424) complains about us using a freed variable inside the
while loop. Technically we're not doing anything dangerous, because
we explicitly set that variable to null, but while looking at the loop, it
seems that it can never be executed more than once, because
port->pending_replies is never updated. It appears to me that a patch
like this should fix the problem:
diff --git a/src/or/eventdns.c b/src/or/eventdns.c
index 83bff67..70cf28c 100644
--- a/src/or/eventdns.c
+++ b/src/or/eventdns.c
@@ -1303,6 +1303,12 @@ server_port_flush(struct evdns_server_port *port)
return;
log(EVDNS_LOG_WARN, "Error %s (%d) while writing response to port; dropping", tor_socket_strerror(err), err);
}
+ if (req->next_pending && req->next_pending != req) {
+ port->pending_replies = req->next_pending;
+ } else {
+ port->pending_replies = NULL;
+ }
+
if (server_request_free(req)) {
/* we released the last reference to req->port. */
return;
But maybe I'm missing some subtleties here?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1177Segfault in unit tests on Mac OS X Panther2020-06-27T14:09:43ZedmanmSegfault in unit tests on Mac OS X Pantherhttps://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit bu...https://buildbot.vidalia-project.net/builders/phobos.osx-panther.tor-master/builds/2101/steps/test/logs/stdio
Last few lines of output:
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 102948 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 102948
Dec 15 15:46:33.895 [info] circuit_build_times_add_timeout_worker(): Generated synthetic circuit build time 65671 for timeout
Dec 15 15:46:33.895 [info] circuit_build_times_add_time(): Adding circuit build time 65671
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 55 buildtimes.
Dec 15 15:46:33.895 [notice] Network connection speed appears to have changed. Resetting timeout to 120s after 16 timeouts and 57 buildtimes.
process killed by signal 11
program finished with exit code -1
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Tor: 0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1181evdns_server_request_format_response() sets TC flag wrong2020-06-27T14:09:43ZRoger Dingledineevdns_server_request_format_response() sets TC flag wrongkenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers)...kenobi> evdns_server_request_format_response() with dnsname_to_labels()
wrongly implements part of rfc1035 about logic for sets of TC bit.
kenobi> " Messages carried by UDP are restricted to 512 bytes (not counting
the IP or UDP headers). Longer messages are truncated and the TC bit is set
in the header"
kenobi> TC bits should be sets only if lenght of all message via UDP was more
than 512 bytes. Not alone lables or names.
kenobi> for now TC bit sets for wrongly lengthed labels, which stricly limits
for 63, but those means transmited error not signaling truncate bit.
> do you have a patch? :)
kenobi> I do not have patch, because it's should be designed for future tcp
transport too, so it's slightly hard for patch by one line.
> (does this affect anything in practice, or is it just a theoretical
correctness issue?)
kenobi> It's can be exploit via exotic attack, if reverse lookup was
controled by attacker and exit relay was too. And resolv.conf contained ISP's
DNS.
> what would the attack achieve, in that case?
kenobi> ip address of ISP's DNS
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1184Sending useless relay cells after the destroy cell2020-06-27T14:09:43ZRoger DingledineSending useless relay cells after the destroy cellr9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call con...r9913 took out the "clear cell queue after sending destroy cell" logic.
Bug 1150 (comment 3519) points out that the cells are just going to get
dropped by the other side anyway.
I think it's right.
There are three places that call connection_or_send_destroy().
The first is in relay.c, where we unlink the circ from the n_conn
immediately after.
The second is in command.c, where we refuse new circuits for various
reasons. No cells queued yet.
The third is in circuitlist.c, during circuit-mark-for-close. So the
question is, if the circuit is marked, do we really want to still be
trying to send its cells? Either it got marked from the other side,
in which case the other side has already decided it doesn't want to hear
from us. Or it got marked from our side, in which case either that was
an error (circuit needs to die) or it has no streams on it, in which
case there's no harm in clearing its queue.
Did I miss anything?
Perhaps we should check, in main.c when we're considering whether to mark
it because it's idle, whether there are any cells still in its queue.
Or maybe we should just pass an argument into connection_or_send_destroy()
from the truncate case in relay.c saying "clear the queue please". Then we
can remain ambiguous in the cases above where I said "no harm because surely
the queue has nothing in it". That's certainly the safest approach, but
wouldn't it be nice to simplify rather than complexify? :)
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1187getinfo bridge status2020-06-27T14:09:43ZRoger Dingledinegetinfo bridge statusA user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which ...A user from China suggests at
http://blog.torproject.org/blog/bridge-distribution-strategies#comment-3336 :
"I have a fairly long list of bridges in my settings tab now, and I have no
idea which are actually of any use to me, and which are dead. Would it be
possible to have some visual indicator in the Vidalia bridge config dialog
that shows which bridges are healthy and which are not?"
This is a great idea, and we should do it. Perhaps Tor should expose this info
via a 'getinfo bridge-status' or equivalent, and then we can show which ones
are configured, which we have a fresh descriptor for, which we've found
reachable, etc. Once we've got the Tor side figured out, then Vidalia could
ask for the bridge status when you open the bridge config window, and mark them
as appropriate.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1190Renegotiation bug still present on OpenBSD 4.6 stable2020-06-27T14:09:43ZTracRenegotiation bug still present on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works wit...Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in .21, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.2.6-alpha
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistsTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1191renegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stable2020-06-27T14:09:43ZTracrenegotiation bug still present in 0.2.2.6-alpha on OpenBSD 4.6 stableRenegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working....Renegotiation bug still present on OpenBSD 4.6 with
ftp://ftp.openbsd.org/pub/OpenBSD/patches/4.6/common/004_openssl.patch applied.
Results in the supposedly fixed TLS renegotiation errors in 0.2.2.6-alpha, and prevents it from working. Works without the patch, but that
leaves the whole system vulnerable.
[warn] TLS error: unexpected close while renegotiating
same exact problem with 0.2.1.21
OpenBSD 4.6 ships with OpenSSL 0.9.8k
What is the work-around?
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: nixmlistshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1193Measured BW Authority will not work on private networks with less than 3 scan...2022-06-24T14:27:55ZTracMeasured BW Authority will not work on private networks with less than 3 scannersSince Measured BW votes are only used for consensus if there are at least 3 of them, this scheme will never work on a private tor network with less than 3 auth dirs.
I wonder if it would make sense to reduce this check to only one valid ...Since Measured BW votes are only used for consensus if there are at least 3 of them, this scheme will never work on a private tor network with less than 3 auth dirs.
I wonder if it would make sense to reduce this check to only one valid vote to be necessary if TestingTorNetwork is set.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: fabihttps://gitlab.torproject.org/tpo/core/tor/-/issues/1194crypto_rand_uint64: Assertion max > 0 failed2020-06-27T14:09:42ZTraccrypto_rand_uint64: Assertion max > 0 failedI'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c...I'm running tor-0.2.1.21 on an embedded device, a Sagem F@st 3464 modem/router.
some specs:
busybox-1.15.3
uclibc-0.9.26
libevent-1.4.12
openssl-0.9.8l
When starting tor it always fails with following error message:
[err] Bug: crypto.c:1876: crypto_rand_uint64: Assertion max > 0 failed; aborting.
Is there anything I can do to locate the problem?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cygeushttps://gitlab.torproject.org/tpo/core/tor/-/issues/1195manpage doesn't talk about mbytes and friends2020-06-27T14:09:42ZSebastian Hahnmanpage doesn't talk about mbytes and friendsMaking this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
...Making this bug report so I don't forget
waltman| In setting a value like AccountingMax in torrc, is there a difference
between "500 MB" and "500 MBytes"?
waltman| It's a bit confusing because the manpage says "KB", "MB", etc., but
the examples values all are "KBytes", e.g. "RelayBandwidthRate 100 KBytes"
Sebastian| you can use either one
waltman| cool, thanks
Sebastian| we should fix that in the manpage.
Sebastian| we're thinking about how we can make the manpage easier to
understand for the average use. Hopefully we'll find something.
In our efforts to make the manpage less confusing and more usable for people
with less *nix experience, we might want to explore explaining what we mean
when we allow the user to specify some amount of bandwidth in one section,
and the refer to that section from all the options.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1196upgrade log level of "Authenticated control connection" message to notice2020-06-27T14:09:42ZTracupgrade log level of "Authenticated control connection" message to noticeIt is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to...It is important for normal operation and security
to know when something connects to the control port.
Don't really want to see all the other info logging
under normal circumstances though.
Suggest upgrading the message from log_info to log_notice.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1197Graceful shutdown doesn't seem so graceful2020-06-27T14:09:42ZTracGraceful shutdown doesn't seem so gracefulMay be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge...May be by design: When doing a graceful shutdown, bandwidth graph shows data still flowing at full BW when relay's plug is pulled.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: sponge_bob_128https://gitlab.torproject.org/tpo/core/tor/-/issues/1198Solaris 10 compile error "RLIMIT_MEMLOCK undeclared"2020-06-27T14:09:42ZTracSolaris 10 compile error "RLIMIT_MEMLOCK undeclared"When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .de...When trying to compile tor-0.2.2.6-alpha I get the following error:
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
This is not an issue with tor-0.2.1.21, I have compiled and running tor-0.2.1.21.
The Solaris 10 is the latest release "5.10 Generic_127112-10 i86pc i386 i86pc" (Nov. 2009) with all recommended
patches.
The details for configure and compiling are as follows:
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
usmine:/usr/local/lib/tor-0.2.2.6-alpha> ./configure --with-libevent-dir=/opt/csw \
> --with-tor-user=tor \
> --with-tor-group=guest \
> --enable-eventdn \
> --sysconfdir=/home/tor
checking for a BSD-compatible install... /opt/sfw/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/sfw/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
configure: You are running Solaris; Sometimes threading makes
cpu workers lock up here, so I will disable threads.
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking for sed... sed
checking for sha1sum... /opt/sfw/bin/sha1sum
checking for openssl... /usr/local/ssl/bin/openssl
checking for win32... no
checking for MIPSpro compiler... no
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for library containing socket... -lsocket
checking for library containing gethostbyname... -lnsl
checking for library containing dlopen... none required
checking for library containing inet_aton... -lresolv
checking for gettimeofday... yes
checking for ftime... yes
checking for socketpair... yes
checking for uname... yes
checking for inet_aton... yes
checking for strptime... yes
checking for getrlimit... yes
checking for strlcat... yes
checking for strlcpy... yes
checking for strtoull... yes
checking for getaddrinfo... yes
checking for localtime_r... yes
checking for gmtime_r... yes
checking for memmem... no
checking for strtok_r... yes
checking for writev... yes
checking for readv... yes
checking for flock... no
checking for prctl... no
checking for mallinfo... no
checking for malloc_good_size... no
checking for malloc_usable_size... no
checking for sys/types.h... (cached) yes
checking for u_int64_t... no
checking for u_int32_t... no
checking for u_int16_t... no
checking for u_int8_t... no
checking for libevent directory... /opt/csw
checking whether we need extra options to link libevent... (none)
checking for event_get_version... yes
checking for event_get_version_number... no
checking for event_get_method... yes
checking for event_set_log_callback... yes
checking for evdns_set_outgoing_bind_address... no
checking for event_base_loopexit... yes
checking for struct event.min_heap_idx... no
checking event2/event.h usability... no
checking event2/event.h presence... no
checking for event2/event.h... no
checking event2/dns.h usability... no
checking event2/dns.h presence... no
checking for event2/dns.h... no
checking for openssl directory... /usr/local/ssl
checking whether we need extra options to link openssl... (none)
checking for zlib directory... (system)
checking whether we need extra options to link zlib... (none)
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for inttypes.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/limits.h usability... no
checking sys/limits.h presence... no
checking for sys/limits.h... no
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking machine/limits.h usability... no
checking machine/limits.h presence... no
checking for machine/limits.h... no
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/time.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for inttypes.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/utime.h usability... yes
checking sys/utime.h presence... yes
checking for sys/utime.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking netinet/in6.h usability... no
checking netinet/in6.h presence... no
checking for netinet/in6.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/syslimits.h usability... no
checking sys/syslimits.h presence... no
checking for sys/syslimits.h... no
checking malloc/malloc.h usability... no
checking malloc/malloc.h presence... no
checking for malloc/malloc.h... no
checking linux/types.h usability... no
checking linux/types.h presence... no
checking for linux/types.h... no
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking malloc_np.h usability... no
checking malloc_np.h presence... no
checking for malloc_np.h... no
checking sys/prctl.h usability... no
checking sys/prctl.h presence... no
checking for sys/prctl.h... no
checking for declaration of malloc_good_size... no
checking for net/if.h... yes
checking for net/pfvar.h... no
checking for linux/netfilter_ipv4.h... no
configure: Transparent proxy support enabled, but missing headers.
checking for struct timeval.tv_sec... yes
checking for int8_t... yes
checking size of int8_t... 1
checking for int16_t... yes
checking size of int16_t... 2
checking for int32_t... yes
checking size of int32_t... 4
checking for int64_t... yes
checking size of int64_t... 8
checking for uint8_t... yes
checking size of uint8_t... 1
checking for uint16_t... yes
checking size of uint16_t... 2
checking for uint32_t... yes
checking size of uint32_t... 4
checking for uint64_t... yes
checking size of uint64_t... 8
checking for intptr_t... yes
checking size of intptr_t... 4
checking for uintptr_t... yes
checking size of uintptr_t... 4
checking for char... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for long long... yes
checking size of long long... 8
checking for __int64... no
checking size of __int64... 0
checking for void *... yes
checking size of void *... 4
checking for time_t... yes
checking size of time_t... 4
checking for size_t... yes
checking size of size_t... 4
checking for uint... yes
checking for u_char... yes
checking for ssize_t... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6... yes
checking for sa_family_t... yes
checking for struct in6_addr.s6_addr32... no
checking for struct in6_addr.s6_addr16... no
checking for struct sockaddr_in.sin_len... no
checking for struct sockaddr_in6.sin6_len... no
checking for rlim_t... yes
checking whether time_t is signed... yes
checking for socklen_t... yes
checking size of socklen_t... 4
checking for cell_t... no
checking size of cell_t... 0
checking whether memset(0) sets pointers to NULL... yes
checking whether we can malloc(0) safely.... yes
checking whether we are using 2s-complement arithmetic... yes
checking whether to use dmalloc (debug memory allocation library)... no
checking for mlockall... yes
checking for getresuid... no
checking for getresgid... no
checking for gethostbyname_r... yes
checking how many arguments gethostbyname_r() wants... 5
checking whether the C compiler supports __func__... yes
checking whether the C compiler supports __FUNC__... no
checking whether the C compiler supports __FUNCTION__... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tor.spec
config.status: creating Doxyfile
config.status: creating contrib/tor.sh
config.status: creating contrib/torctl
config.status: creating contrib/torify
config.status: creating contrib/tor.logrotate
config.status: creating contrib/Makefile
config.status: creating contrib/osx/Makefile
config.status: creating contrib/osx/TorBundleDesc.plist
config.status: creating contrib/osx/TorBundleInfo.plist
config.status: creating contrib/osx/TorDesc.plist
config.status: creating contrib/osx/TorInfo.plist
config.status: creating contrib/osx/TorStartupDesc.plist
config.status: creating src/config/torrc.sample
config.status: creating doc/tor.1
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating doc/design-paper/Makefile
config.status: creating doc/spec/Makefile
config.status: creating src/config/Makefile
config.status: creating src/common/Makefile
config.status: creating src/or/Makefile
config.status: creating src/test/Makefile
config.status: creating src/win32/Makefile
config.status: creating src/tools/Makefile
config.status: creating contrib/suse/Makefile
config.status: creating contrib/suse/tor.sh
config.status: creating orconfig.h
config.status: executing depfiles commands
usmine:/usr/local/lib/tor-0.2.2.6-alpha> gmake
gmake all-recursive
gmake[1]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha'
Making all in src
gmake[2]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
Making all in common
gmake[3]: Entering directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT address.o -MD -MP -MF .deps/address.Tpo -c -o address.o address.c
mv -f .deps/address.Tpo .deps/address.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
log.c:95: warning: 'log_mutex' defined but not used
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_set_max_memlock':
compat.c:2224: error: `RLIMIT_MEMLOCK' undeclared (first use in this function)
compat.c:2224: error: (Each undeclared identifier is reported only once
compat.c:2224: error: for each function it appears in.)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src/common'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.2.2.6-alpha'
gmake: *** [all] Error 2
usmine:/usr/local/lib/tor-0.2.2.6-alpha>
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: ottohttps://gitlab.torproject.org/tpo/core/tor/-/issues/1200Add port share option to host HTTPS Server and Tor on same port2020-06-27T14:09:42ZTracAdd port share option to host HTTPS Server and Tor on same portOpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Th...OpenVPN includes a "port share" option that allows OpenVPN to run on port 443 and to pass through HTTPS
connections to a Web server running on the same machine (see http://christophe.vandeplas.com/2008/06/01/portsharing-with-openvpn). Thus, both applications are able to use
port 443 at the same time.
Implementing such a feature for Tor may allow to make it harder to detect Tor bridges from the outside, as they could
behave to non-Tor clients such as a regular Web server (and even include legitimate Web content).
Furthermore, such a feature may make it easier for people running bridges to run these bridges on port 443, as it is
still possible to run a HTTPS server at the same IP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: gstTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1201mapaddress broken2020-06-27T14:09:41ZTracmapaddress brokenSince an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Since an update to 0.2.1.21 from 0.2.1.20 in both Linux and Windows, the mapaddress feature in the torrc file broke.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: johndoe32102002Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1202tor slow loading network status2020-06-27T14:09:41ZTractor slow loading network statustor getting slow on loading network status
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tomlietor getting slow on loading network status
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: tomliehttps://gitlab.torproject.org/tpo/core/tor/-/issues/1203smartlist_choose_by_bandwidth() uses crypto_rand_uint64() wrong2020-06-27T14:09:41ZRoger Dingledinesmartlist_choose_by_bandwidth() uses crypto_rand_uint64() wrongIn smartlist_choose_by_bandwidth(), we sum up all the bandwidths available
and then use crypto_rand_uint64() to pick which relay we'll use. But we
have an off-by-one error.
Imagine there are three relays, each with bandwidth 1. So total...In smartlist_choose_by_bandwidth(), we sum up all the bandwidths available
and then use crypto_rand_uint64() to pick which relay we'll use. But we
have an off-by-one error.
Imagine there are three relays, each with bandwidth 1. So total_bw is 3.
So crypto_rand_uint64() can return {0, 1, 2} with equal probability.
Suppose it returns 1.
Then we go through the first round of the for() loop, at the end of which tmp = 1.
So 1 >= 1, and we break. We return the first relay when we should have returned
the second.
Ok, so this is a really crazy case that will never happen in practice, right?
Not quite.
First, it could have been triggered in the pathological case described by kenobi
here (if we hadn't accidentally made it much less likely by moving to KB in the
consensus):
https://bugs.torproject.org/flyspray/index.php?do=details&id=1194&area=comments#3664
Second, imagine if the first relay has 0 bandwidth, and the other relays have
some bandwidth. If crypto_rand_uint64() returns 0, we'll pick the first relay even
though it has no weight.
The fix (well, hack) is to set rand_bw++ once we've chosen it. Then we count our
fenceposts correctly.
In theory, we shouldn't run into the round-off error warn at the end of the for()
clause. Heck if I know how it'll go in practice though.
Thanks to kenobi for diagnosing and coming up with the fix.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1206Fluxe3 is not a guard2020-06-27T14:09:41ZSebastian HahnFluxe3 is not a guardFluxe3 isn't considered a guard (only one of the authorities votes for it).
It has been up for 13 days, before that it had a downtime for ~30 minutes,
and before that it was running for a week. Before that it was offline.
There are a fe...Fluxe3 isn't considered a guard (only one of the authorities votes for it).
It has been up for 13 days, before that it had a downtime for ~30 minutes,
and before that it was running for a week. Before that it was offline.
There are a few things that seem to be strange. When arma looked at
what moria thinks about fluxe3 three days ago, moria thought that fluxe3's
uptime was 18 days. It somehow missed the fact that the descriptor changed
to reflect the new uptime.
The other question is, does this influence why Fluxe3 is not a guard? Or are
there other issues?
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1208router_rebuild_descriptor(): Bug: Couldn't generate extra-info descriptor.2020-06-27T14:09:41ZTracrouter_rebuild_descriptor(): Bug: Couldn't generate extra-info descriptor.Client and server seem to work, but there warnings are distracting. Deleting the old cached stuff at /var/lib/tor and restarting did not help.
Tor version 0.2.2.6-alpha-dev (git-7d18108b743a2bed).
2010-01-11 20:52:52.194028156 [warn] c...Client and server seem to work, but there warnings are distracting. Deleting the old cached stuff at /var/lib/tor and restarting did not help.
Tor version 0.2.2.6-alpha-dev (git-7d18108b743a2bed).
2010-01-11 20:52:52.194028156 [warn] couldn't find end of hashed material "
2010-01-11 20:52:52.194028836 router-signature"
2010-01-11 20:52:52.194029277 [warn] router_rebuild_descriptor(): Bug: Couldn't generate extra-info descriptor.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safarihttps://gitlab.torproject.org/tpo/core/tor/-/issues/1209crypto.c:322 _crypto_new_pk_env_rsa: Assertion rsa failed; aborting.2020-06-27T14:09:41ZTraccrypto.c:322 _crypto_new_pk_env_rsa: Assertion rsa failed; aborting.I get this after SIGHUP
...
[debug] Removing exit policy reject 172.16.0.0/12:*. It is already covered by reject *:*.
[err] _crypto_new_pk_env_rsa(): Bug: crypto.c:322: _crypto_new_pk_env_rsa: Assertion rsa failed; aborting.
crypto.c:32...I get this after SIGHUP
...
[debug] Removing exit policy reject 172.16.0.0/12:*. It is already covered by reject *:*.
[err] _crypto_new_pk_env_rsa(): Bug: crypto.c:322: _crypto_new_pk_env_rsa: Assertion rsa failed; aborting.
crypto.c:322 _crypto_new_pk_env_rsa: Assertion rsa failed; aborting.
I have openssl cvs version from 20091229 (newer ones do not compile (without disabling ASM))
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safarihttps://gitlab.torproject.org/tpo/core/tor/-/issues/1211extrainfo_dump_to_string problem2020-06-27T14:09:41ZSebastian Hahnextrainfo_dump_to_string problemr1eo| extrainfo_dump_to_string() do wrong. if tor_snprintf() returns -1 no
need to ""Adding stats to extra-info descriptor."" useless anyway, need
to free() and to return -1; imidately.
[Automatically added by flysp...r1eo| extrainfo_dump_to_string() do wrong. if tor_snprintf() returns -1 no
need to ""Adding stats to extra-info descriptor."" useless anyway, need
to free() and to return -1; imidately.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1215Graph auto scaling2020-06-27T14:09:41ZTracGraph auto scalingCould you add a option to the graph so that it auto scales to the visible data, Like uTorrent.
Thnks
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: devin122Could you add a option to the graph so that it auto scales to the visible data, Like uTorrent.
Thnks
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: devin122https://gitlab.torproject.org/tpo/core/tor/-/issues/1217>=0.2.1.3-alpha don't weight guard choice2020-06-27T14:09:40ZRoger Dingledine>=0.2.1.3-alpha don't weight guard choiceRight now we're picking which guards we'll use uniformly at random from
all nodes, and we're picking which of our guards we'll use uniformly at
random from the nodes in our guard list that have the Guard flag.
We used to have this bad b...Right now we're picking which guards we'll use uniformly at random from
all nodes, and we're picking which of our guards we'll use uniformly at
random from the nodes in our guard list that have the Guard flag.
We used to have this bad behavior, but we fixed it in 0.2.0.3-alpha
and 0.1.2.17. See bug 440 for more details.
But then in 0.2.1.3-alpha (git ed781e69), we refactored how we called
router_choose_random_node(), and we got it wrong. We end up never passing
CRN_NEED_GUARD in the case where we're choosing a new entry guard (where
state is NULL).
So a) we don't choose it by bandwidth, and b) we don't even see if it's got
the Guard flag -- or even the Fast flag -- when selecting it.
The fix is to call router_choose_random_node() with the NEED_GUARD flag when
state is NULL. The next piece of the fix is to modify
remove_obsolete_entry_guards() so it discards guards chosen between 0.2.1.3-alpha
and 0.2.1.21, and between 0.2.2.1-alpha and 0.2.2.6-alpha.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.22https://gitlab.torproject.org/tpo/core/tor/-/issues/1218Tor crashes on Windows when no bridges available2020-06-27T14:09:40ZTracTor crashes on Windows when no bridges availableI'm running the Tor Browser bundle (Vidalia 0.2.6, Tor 0.2.1.21) on Windows XP and wanted to know
what happens, when information about bridges are wrong. Therefore I stopped Tor, deleted all consensus, descriptor
and geoip-files and edit...I'm running the Tor Browser bundle (Vidalia 0.2.6, Tor 0.2.1.21) on Windows XP and wanted to know
what happens, when information about bridges are wrong. Therefore I stopped Tor, deleted all consensus, descriptor
and geoip-files and edited the torrc:
AvoidDiskWrites 1
# two randomly selected "wrong" IPs, meaning there is no running bridge with that IP
Bridge 91.231.45.12:80
Bridge 141.35.112.65:443
ControlPort 9051
CookieAuthentication 1
DataDirectory .\Data\Tor
GeoIPFile .\Data\Tor\geoip
Log notice stdout
SocksListenAddress 127.0.0.1
UpdateBridgesFromAuthority 1
UseBridges 1
When I restarted Tor, it crashed and wanted to system crash reports. I'm not able to copy this report. But
it looks a bit like a core dump to me. If you have an idea how to copy this report or where it is saved, I can
send it.
The log file itself only has an info level entry:
Jan 18 12:09:47.546 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
You can download the debug-log at <URL:http://kubieziel.de/tmp/tor-log.zip>.
Steps to reproduce:
1. Start Tor with some valid bridges and wait until bootstrapping is done.
2. Stop Tor
3. Go to DATADIR and remove all cached-* files
4. Enter some wrong information about bridges (I just select some random IP addresses) and save the file
5. Restart Tor
It only works if bridges are involved and if you first start Tor with "good" information. If the information
is "bad" from the first start of Tor, it just waits for the bridge (no crash).
At the moment I only tested this on Windows.
If there is any information missing please ask. I subscribed to this bug.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: kubiezielhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1222Tor falsely believing to be offline2020-06-27T14:09:40ZTracTor falsely believing to be offlineActually, don't know if it's a bug in the server or client, or both. Running Tor server on Win 2k,
low bandwidth & severely port limited but still technically an exit; not using the client much, I still
will let the server run unattende...Actually, don't know if it's a bug in the server or client, or both. Running Tor server on Win 2k,
low bandwidth & severely port limited but still technically an exit; not using the client much, I still
will let the server run unattended for days at times. The problem is, after Tor and computer have
run unattended for say a dozen hours, when I come back and make a client request myself thru Tor,
I will get this notice : "Application request when we're believed to be offline."
After which Tor (successfully)fetches directory information again.
I told of this problem on the IRC chat in the past, but apparently it hasn't made its way to the bug repository :(
Questions : - why did Tor believe it was "offline" ? Or is the warning bogus ? Was the /server/ still relaying and exiting
in the meantime ? I wonder why I would leave the puter running if Tor *really* falls asleep :=)
- Workaround, any ? Maybe send some sort of (TCP-)ping thru Tor at regular intervals ?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: noino667Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1223Latest OS X security update disables renegotiation2020-06-27T14:09:40ZSebastian HahnLatest OS X security update disables renegotiationMeaning our current Tor bundles will not work
[Automatically added by flyspray2trac: Operating System: All]Meaning our current Tor bundles will not work
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1225hang on establishing encrypted directory connection snow leopard2020-06-27T14:09:40ZTrachang on establishing encrypted directory connection snow leopardusing the default settings in the tor client 0.2.6 qt 3.4.5 on os x 10.6 snow leopard (you dont list 10.6 snow leopard) hangs on establishing encrypted directory connection.
from different searches i get that it is an isp blocking tor b...using the default settings in the tor client 0.2.6 qt 3.4.5 on os x 10.6 snow leopard (you dont list 10.6 snow leopard) hangs on establishing encrypted directory connection.
from different searches i get that it is an isp blocking tor but i tried different isps and even going through a vpn and the same thing.
i have a ppc based mac running 10.5.8 and it works ok.
i suspect that tor is not snow leopard compatible with this latest version of tor
i suspect it may be something apple did possibly the removal of the ppc code and having intel only.
Jan 22 10:41:59.437 [Notice] Tor v0.2.1.21. This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin Power Macintosh)
Jan 22 10:41:59.546 [Notice] Initialized libevent version 1.4.13-stable using method kqueue. Good.
Jan 22 10:41:59.554 [Notice] Opening Socks listener on 127.0.0.1:9050
Jan 22 10:41:59.563 [Notice] Opening Control listener on 127.0.0.1:9051
Jan 22 10:42:00.549 [Notice] Bootstrapped 10%: Finishing handshake with directory server.
Jan 22 10:42:00.862 [Warning] TLS error: unexpected close while renegotiating
Jan 22 10:42:01.173 [Warning] TLS error: unexpected close while renegotiating
Jan 22 10:42:01.264 [Notice] No current certificate known for authority moria1; launching request.
Jan 22 10:42:01.272 [Notice] No current certificate known for authority tor26; launching request.
Jan 22 10:42:01.280 [Notice] No current certificate known for authority dizum; launching request.
Jan 22 10:42:01.293 [Notice] No current certificate known for authority ides; launching request.
Jan 22 10:42:01.301 [Notice] No current certificate known for authority gabelmoo; launching request.
Jan 22 10:42:01.309 [Notice] No current certificate known for authority dannenberg; launching request.
Jan 22 10:42:01.318 [Notice] No current certificate known for authority urras; launching request.
Jan 22 10:42:01.527 [Warning] TLS error: unexpected close while renegotiating
Jan 22 10:42:01.766 [Warning] TLS error: unexpected close while renegotiating
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: ejonesss0.2.1.22https://gitlab.torproject.org/tpo/core/tor/-/issues/1226Tor for Mac OSX will not work after install the Security Update 2010-0012020-06-27T14:09:40ZTracTor for Mac OSX will not work after install the Security Update 2010-001apple disabled the renegotiation in OpenSSL in this update.
So the tor all the systems that installed this update will fail to connect to the server.
The following warning will be showned:
TLS error: unexpected close while renegotiating ...apple disabled the renegotiation in OpenSSL in this update.
So the tor all the systems that installed this update will fail to connect to the server.
The following warning will be showned:
TLS error: unexpected close while renegotiating (SSL_ST_OK)
please check http://support.apple.com/kb/HT4004 for the details
*
OpenSSL
CVE-ID: CVE-2009-3555
Available for: Mac OS X v10.5.8, Mac OS X Server v10.5.8, Mac OS X v10.6.2, Mac OS X Server v10.6.2
Impact: An attacker with a privileged network position may capture data or change the operations performed in sessions protected by SSL
Description: A man-in-the-middle vulnerability exists in the SSL and TLS protocols. Further information is available at http://www.phonefactor.com/sslgap A change to the renegotiation protocol is underway within the IETF. This update disables renegotiation in OpenSSL as a preventive security measure. The issue does not affect services using Secure Transport as it does not support renegotiation. Credit to Steve Dispensa and Marsh Ray of PhoneFactor, Inc. for reporting this issue.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: clucklyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1228microdescriptor() make errors on build2020-06-27T14:09:40ZTracmicrodescriptor() make errors on buildThe new git commit 256861023e18f760bb5497630e02f139d17301b4 make 2 errors on build Tor v0.2.2.7-alpha (git-3b4b6009a0020fb5). (Running on Linux x86_64)
cc1: warnings being treated as errors ...The new git commit 256861023e18f760bb5497630e02f139d17301b4 make 2 errors on build Tor v0.2.2.7-alpha (git-3b4b6009a0020fb5). (Running on Linux x86_64)
cc1: warnings being treated as errors
microdesc.c: In function ‘microdescs_add_list_to_cache’:
microdesc.c:180: error: comparison of unsigned expression < 0 is always false
microdesc.c: In function ‘microdesc_cache_rebuild’:
microdesc.c:306: error: comparison of unsigned expression < 0 is always false
make[2]: *** [microdesc.o] Erreur 1
make[2]: quittant le répertoire « /home/moonlights/tor/src/or »
make[1]: *** [install-recursive] Erreur 1
make[1]: quittant le répertoire « /home/moonlights/tor/src »
make: *** [install-recursive] Erreur 1
on Kubuntu karmic 9.10
Linux moon 2.6.31-18-generic legacy/trac#55-Ubuntu SMP Fri Jan 8 14:54:52 UTC 2010 x86_64 GNU/Linux
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1229cpu affinity cpuworker threads2020-06-27T14:09:40ZTraccpu affinity cpuworker threadsv0.2.2.6-alpha on Debian Squeeze x86_64
On Blutmagie exit node I recently noticed all onionskin cpuworker threads _always_ run on
the same core as the main thread. Don't know if this is can be considered a bug, but it
renders the Numcpu...v0.2.2.6-alpha on Debian Squeeze x86_64
On Blutmagie exit node I recently noticed all onionskin cpuworker threads _always_ run on
the same core as the main thread. Don't know if this is can be considered a bug, but it
renders the Numcpu config option pretty useless.
Olaf
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ P COMMAND
25495 debian-t 20 0 987m 567m 27m R 95.7 14.3 11369:12 0 tor
7328 debian-t 20 0 987m 567m 27m S 2.7 14.3 15:04.47 0 tor
7330 debian-t 20 0 987m 567m 27m S 2.3 14.3 15:59.22 0 tor
1 root 20 0 10324 684 572 S 0.0 0.0 1:32.45 1 init
[...]
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Falohttps://gitlab.torproject.org/tpo/core/tor/-/issues/1231Epoll MOD on fd 146 failed.2020-06-27T14:09:40ZTracEpoll MOD on fd 146 failed.hello,
Today i have a waring in my log that i never see before from libevent.
janv. 25 04:39:28.180 [Warning] Warning from libevent: Epoll MOD on fd 146 failed. Old events were 6; read change was 0; write change was 2.: Bad file descr...hello,
Today i have a waring in my log that i never see before from libevent.
janv. 25 04:39:28.180 [Warning] Warning from libevent: Epoll MOD on fd 146 failed. Old events were 6; read change was 0; write change was 2.: Bad file descriptor
Tor v0.2.2.7-alpha (git-a93cabd9ab1ea961). (Running on Linux x86_64), Linux moon 2.6.31-18-generic legacy/trac#55-Ubuntu SMP Fri Jan 8 14:54:52 UTC 2010 x86_64 GNU/Linux
Kububtu karmic 9.10
tor commit a93cabd9ab1ea9614136033f6c17eac295ff4adf
libevent commit 70a4a3ef141e8e5f21549669fc4f67ae75d150f1
SwissTorExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1232Bridge crash2020-06-27T14:09:39ZWendy SeltzerBridge crashBridge crashed after a few days, running Tor 0.2.2.7-alpha (git-c939509051f90d72)
from the log:
Jan 22 12:25:02.350 [err] routerlist_assert_ok(): Bug: routerlist.c:4699: router
list_assert_ok: Assertion r == r2 failed; aborting.
(gdb) ...Bridge crashed after a few days, running Tor 0.2.2.7-alpha (git-c939509051f90d72)
from the log:
Jan 22 12:25:02.350 [err] routerlist_assert_ok(): Bug: routerlist.c:4699: router
list_assert_ok: Assertion r == r2 failed; aborting.
(gdb) bt
#0 0x006af422 in __kernel_vsyscall ()
#1 0x0090a4d1 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0x0090d932 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0x0807d48e in routerlist_assert_ok (rl=<value optimized out>)
at routerlist.c:4727
legacy/trac#4 0x08083cc0 in router_load_routers_from_string (s=0x9bae98d "", eos=0x0,
saved_location=SAVED_NOWHERE, requested_fingerprints=0x8f32590,
descriptor_digests=1,
prepend_annotations=0xbfa9aeec "@downloaded-at 2010-01-22 19:25:02\n@source \"80.251.122.132\"\n") at routerlist.c:3460
legacy/trac#5 0x080dd7f9 in connection_dir_client_reached_eof (
conn=<value optimized out>) at directory.c:1623
legacy/trac#6 0x080de50e in connection_dir_client_reached_eof (conn=0x8d19360)
at directory.c:1894
legacy/trac#7 0x080c048d in fprintf (conn=0x8d19360) at /usr/include/bits/stdio2.h:98
legacy/trac#8 TO_OR_CONN (conn=0x8d19360) at or.h:1248
legacy/trac#9 connection_read_to_buf (conn=0x8d19360) at connection.c:2446
legacy/trac#10 connection_handle_read_impl (conn=0x8d19360) at connection.c:2339
legacy/trac#11 connection_handle_read (conn=0x8d19360) at connection.c:2407
legacy/trac#12 0x08051134 in conn_write_callback (fd=63, events=2, _conn=0x8d19360)
at main.c:523
legacy/trac#13 0x00776248 in event_base_loop () from /usr/lib/libevent-1.4.so.2
legacy/trac#14 0x080527c1 in do_main_loop () at main.c:1506
legacy/trac#15 0x08052a3d in tor_main (argc=1, argv=0xbfa9b2e4) at main.c:2130
legacy/trac#16 0x0804db7b in frame_dummy () from /usr/local/bin/tor
legacy/trac#17 0x008f6b56 in __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#18 0x0804dac1 in geteuid@plt () from /usr/local/bin/tor
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1233Bridge History Shows Corrupt Data2020-06-27T14:09:39ZTracBridge History Shows Corrupt DataViewing bridge stats sometimes shows corrupt data. Often followed by a tor.exe crash.
[Automatically added by flyspray2trac: Operating System: Windows 7]
**Trac**:
**Username**: BarkerJrViewing bridge stats sometimes shows corrupt data. Often followed by a tor.exe crash.
[Automatically added by flyspray2trac: Operating System: Windows 7]
**Trac**:
**Username**: BarkerJrhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1236Tor doesn't warn if it gets an IP address as fqdn2020-06-27T14:09:39ZSebastian HahnTor doesn't warn if it gets an IP address as fqdnUsing the typical Firefox + Torbutton -> Polipo -> Tor setup,
I noticed that Tor doesn't create warnings when I directly type
IP addresses into the browser's location bar. This is because
Polipo forwards that request as a fqdn, so Tor ne...Using the typical Firefox + Torbutton -> Polipo -> Tor setup,
I noticed that Tor doesn't create warnings when I directly type
IP addresses into the browser's location bar. This is because
Polipo forwards that request as a fqdn, so Tor never thinks it
has an IP address. I don't know if that is the right behaviour
from Polipo, but it seems that we might not warn about leaks
when the application resolves the IP itself and tells us we're
connecting to a hostname?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1237Tor 0.2.2.8-alpha doesn't compile with CFLAGS=-static for a static binary2020-06-27T14:09:39ZTracTor 0.2.2.8-alpha doesn't compile with CFLAGS=-static for a static binaryI think I found a little problem with Tor 0.2.2.8-alpha. I compile my Tor static with "env CFLAGS=-static ./configure && make",
which worked fine so far, and which is described like this on the wiki. Worked fine until 0.2.2.7-alpha. Wit...I think I found a little problem with Tor 0.2.2.8-alpha. I compile my Tor static with "env CFLAGS=-static ./configure && make",
which worked fine so far, and which is described like this on the wiki. Worked fine until 0.2.2.7-alpha. With 0.2.2.8-alpha as well
as with the latest git version, on both OpenBSD 4.7-beta and FreeBSD 8.0, I get this error (from OpenBSD with latest git version):
http://pastebin.ca/1774260
$ env CFLAGS=-static ./configure && make
[...]
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -static -Wall -g -O2 -fno-strict-aliasing -MT eventdns.o -MD -MP -MF ".deps/eventdns.Tpo" -c -o eventdns.o eventdns.c; then mv -f ".deps/eventdns.Tpo" ".deps/eventdns.Po"; else rm -f ".deps/eventdns.Tpo"; exit 1; fi
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -static -Wall -g -O2 -fno-strict-aliasing -MT config_codedigest.o -MD -MP -MF ".deps/config_codedigest.Tpo" -c -o config_codedigest.o config_codedigest.c; then mv -f ".deps/config_codedigest.Tpo" ".deps/config_codedigest.Po"; else rm -f ".deps/config_codedigest.Tpo"; exit 1; fi
rm -f libtor.a
ar cru libtor.a buffers.o circuitbuild.o circuitlist.o circuituse.o command.o config.o connection.o connection_edge.o connection_or.o control.o cpuworker.o directory.o dirserv.o dirvote.o dns.o dnsserv.o geoip.o hibernate.o main.o microdesc.o networkstatus.o onion.o policies.o reasons.o relay.o rendcommon.o rendclient.o rendmid.o rendservice.o rephist.o router.o routerlist.o routerparse.o eventdns.o config_codedigest.o
ranlib libtor.a
if gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../../src/common -static -Wall -g -O2 -fno-strict-aliasing -MT tor_main.o -MD -MP -MF ".deps/tor_main.Tpo" -c -o tor_main.o tor_main.c; then mv -f ".deps/tor_main.Tpo" ".deps/tor_main.Po"; else rm -f ".deps/tor_main.Tpo"; exit 1; fi
gcc -static -Wall -g -O2 -fno-strict-aliasing -o tor tor_main.o ./libtor.a ../common/libor.a ../common/libor-crypto.a ../common/libor-event.a -lz -lm -levent -lcrypto -lssl -lpthread
/usr/lib/libssl.a(s3_srvr.o)(.text+0x27d1): In function `ssl3_get_client_key_exchange':
/usr/src/lib/libssl/src/ssl/s3_srvr.c:2264: undefined reference to `ECDH_compute_key'
/usr/lib/libssl.a(s3_srvr.o)(.text+0x2c47): In function `ssl3_get_cert_verify':
/usr/src/lib/libssl/src/ssl/s3_srvr.c:2332: undefined reference to `X509_certificate_type'
/usr/lib/libssl.a(s3_clnt.o)(.text+0x2d66): In function `ssl3_send_client_key_exchange':
/usr/src/lib/libssl/src/ssl/s3_clnt.c:2251: undefined reference to `ECDH_compute_key'
/usr/lib/libssl.a(s3_clnt.o)(.text+0x334b): In function `ssl3_check_cert_and_algorithm':
/usr/src/lib/libssl/src/ssl/s3_clnt.c:2567: undefined reference to `X509_certificate_type'
/usr/lib/libssl.a(s3_clnt.o)(.text+0x36f7): In function `ssl_do_client_cert_cb':
/usr/src/lib/libssl/src/ssl/s3_clnt.c:2734: undefined reference to `ENGINE_load_ssl_client_cert'
/usr/lib/libssl.a(ssl_rsa.o)(.text+0x113): In function `SSL_use_certificate_file':
/usr/src/lib/libssl/src/ssl/ssl_rsa.c:112: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(ssl_rsa.o)(.text+0x9bd): In function `SSL_CTX_use_certificate_file':
/usr/src/lib/libssl/src/ssl/ssl_rsa.c:481: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(ssl_rsa.o)(.text+0xf27): In function `SSL_CTX_use_certificate_chain_file':
/usr/src/lib/libssl/src/ssl/ssl_rsa.c:726: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(ssl_rsa.o)(.text+0xf76):/usr/src/lib/libssl/src/ssl/ssl_rsa.c:745: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(s3_pkt.o)(.text+0x624): In function `ssl3_do_uncompress':
/usr/src/lib/libssl/src/ssl/s3_pkt.c:480: undefined reference to `COMP_expand_block'
/usr/lib/libssl.a(s3_pkt.o)(.text+0x670): In function `ssl3_do_compress':
/usr/src/lib/libssl/src/ssl/s3_pkt.c:498: undefined reference to `COMP_compress_block'
/usr/lib/libssl.a(ssl_ciph.o)(.text+0x1bd): In function `load_builtin_compressions':
/usr/src/lib/libssl/src/ssl/ssl_ciph.c:295: undefined reference to `COMP_zlib'
/usr/lib/libssl.a(ssl_ciph.o)(.text+0x331): In function `ssl_cipher_get_evp':
/usr/src/lib/libssl/src/ssl/ssl_ciph.c:366: undefined reference to `EVP_enc_null'
/usr/lib/libssl.a(ssl_lib.o)(.text+0x2dd5): In function `ssl_clear_cipher_ctx':
/usr/src/lib/libssl/src/ssl/ssl_lib.c:2352: undefined reference to `COMP_CTX_free'
/usr/lib/libssl.a(ssl_lib.o)(.text+0x2ded):/usr/src/lib/libssl/src/ssl/ssl_lib.c:2347: undefined reference to `COMP_CTX_free'
/usr/lib/libssl.a(ssl_lib.o)(.text+0x30f2): In function `SSL_CTX_set_default_verify_paths':
/usr/src/lib/libssl/src/ssl/ssl_lib.c:2521: undefined reference to `X509_STORE_set_default_paths'
/usr/lib/libssl.a(ssl_lib.o)(.text+0x3106): In function `SSL_CTX_load_verify_locations':
/usr/src/lib/libssl/src/ssl/ssl_lib.c:2527: undefined reference to `X509_STORE_load_locations'
/usr/lib/libssl.a(ssl_sess.o)(.text+0x1131): In function `SSL_CTX_set_client_cert_engine':
/usr/src/lib/libssl/src/ssl/ssl_sess.c:884: undefined reference to `ENGINE_get_ssl_client_cert_function'
/usr/lib/libssl.a(s3_enc.o)(.text+0x2bd): In function `ssl3_change_cipher_state':
/usr/src/lib/libssl/src/ssl/s3_enc.c:239: undefined reference to `COMP_CTX_new'
/usr/lib/libssl.a(s3_enc.o)(.text+0x695):/usr/src/lib/libssl/src/ssl/s3_enc.c:234: undefined reference to `COMP_CTX_free'
/usr/lib/libssl.a(s3_enc.o)(.text+0x713):/usr/src/lib/libssl/src/ssl/s3_enc.c:275: undefined reference to `COMP_CTX_new'
/usr/lib/libssl.a(s3_enc.o)(.text+0x755):/usr/src/lib/libssl/src/ssl/s3_enc.c:270: undefined reference to `COMP_CTX_free'
/usr/lib/libssl.a(ssl_cert.o)(.text+0x966): In function `SSL_load_client_CA_file':
/usr/src/lib/libssl/src/ssl/ssl_cert.c:672: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(ssl_cert.o)(.text+0xb06): In function `SSL_add_file_cert_subjects_to_stack':
/usr/src/lib/libssl/src/ssl/ssl_cert.c:744: undefined reference to `PEM_read_bio_X509'
/usr/lib/libssl.a(ssl_cert.o)(.text+0xc1c): In function `SSL_add_dir_cert_subjects_to_stack':
/usr/src/lib/libssl/src/ssl/ssl_cert.c:811: undefined reference to `OPENSSL_DIR_read'
/usr/lib/libssl.a(ssl_cert.o)(.text+0xcf2):/usr/src/lib/libssl/src/ssl/ssl_cert.c:828: undefined reference to `OPENSSL_DIR_end'
/usr/lib/libssl.a(t1_enc.o)(.text+0x39a): In function `tls1_change_cipher_state':
/usr/src/lib/libssl/src/ssl/t1_enc.c:290: undefined reference to `COMP_CTX_new'
/usr/lib/libssl.a(t1_enc.o)(.text+0x869):/usr/src/lib/libssl/src/ssl/t1_enc.c:285: undefined reference to `COMP_CTX_free'
/usr/lib/libssl.a(t1_enc.o)(.text+0x8ed):/usr/src/lib/libssl/src/ssl/t1_enc.c:327: undefined reference to `COMP_CTX_new'
/usr/lib/libssl.a(t1_enc.o)(.text+0x935):/usr/src/lib/libssl/src/ssl/t1_enc.c:322: undefined reference to `COMP_CTX_free'
collect2: ld returned 1 exit status
*** Error code 1
Stop in /backup/temp/tor/src/or (line 310 of Makefile).
*** Error code 1
Stop in /backup/temp/tor/src (line 234 of Makefile).
*** Error code 1
Stop in /backup/temp/tor (line 283 of Makefile).
*** Error code 1
Stop in /backup/temp/tor (line 195 of Makefile).
$
So it seems to me something changed with 0.2.2.8-aplha which breaks compiling of a static binary on BSD.
Tas.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Tashttps://gitlab.torproject.org/tpo/core/tor/-/issues/1238Exit flag assigned can be assigned to nodes that don't really exit.2021-09-27T16:51:52ZSebastian HahnExit flag assigned can be assigned to nodes that don't really exit.The router b0red is flagged as Exit, even though its Exit policy doesn't allow any exits.
Discovered by "dun" on #tor.
This is currently part of the consensus:
```
r b0red WCi6nB/t0u9ZtGBcrrWFgpXdjlg w+3Dl7l2fnUc0JhSMLchCL7RcjU 2010-0...The router b0red is flagged as Exit, even though its Exit policy doesn't allow any exits.
Discovered by "dun" on #tor.
This is currently part of the consensus:
```
r b0red WCi6nB/t0u9ZtGBcrrWFgpXdjlg w+3Dl7l2fnUc0JhSMLchCL7RcjU 2010-02-02 00:21:48 80.190.250.90 443 80
s Exit Fast Guard HSDir Named Running Stable V2Dir Valid
v Tor 0.2.1.20
w Bandwidth=621
p reject 1-65535
```
descriptor:
```
@downloaded-at 2010-01-31 23:16:54
@source "194.109.206.212"
router b0red 80.190.250.90 443 0 80
platform Tor 0.2.1.20 on Linux i686
opt protocols Link 1 2 Circuit 1
published 2010-01-31 12:20:43
opt fingerprint 5828 BA9C 1FED D2EF 59B4 605C AEB5 8582 95DD 8E58
uptime 5097747
bandwidth 5242880 10485760 261098
opt extra-info-digest 535CE872B386F71E9DEA356B10E63E9D83789F57
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAM2wCZqUMEgPDdEsVrW1XfHrvqmOT1KYDMupz7h+DA5b56VMPOIyOG57
hKGliyW5gE7B/Qtt5EtasScqAFM+kV9BVXWVshFEF4tu2kWdFS8E4XKVks0NbTUU
2H/l0W/H2KdMy1bUuWyd7s1ftcuodb04Na3U/DS0t26Ta1kADWLZAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBANB7P5x+7SON1dd2RkuqjNZaPsSPKoGKIOuq1IwSNDJR8+Y7T7jijgWe
ZKzvieP82XK1eDxKTdXCJbWR1X+V5a5XExt8RNszeslK02bC+Q4wTUtlM7n3319Q
UQrLTp++dVLa0LuNvlbux39tqAqriyn0hWI2JVEbkrp32N4l28SFAgMBAAE=
-----END RSA PUBLIC KEY-----
opt hidden-service-dir
opt allow-single-hop-exits
contact xxoes <xxoes at b0red.de>
reject 0.0.0.0/8:*
reject 169.254.0.0/16:*
reject 127.0.0.0/8:*
reject 192.168.0.0/16:*
reject 10.0.0.0/8:*
reject 172.16.0.0/12:*
reject 80.190.250.90:*
reject *:1-65534
reject *:65535
accept *:*
router-signature
-----BEGIN SIGNATURE-----
SVmtJeKcTUVyaZO8PfKtd0E1yQUR+TffgNo5AAgPOGLdjqmbIpFA2RqsfFqXK2Re
PQ34TxbgMKGxfZKDVXAfeQFVVQgFny8KqAlzDfytFUxOGvdcthHsfg/FJwbPneNU
eiNdn4E+ug8JjOcAKJ7EdfhmIKaWRXAg2NKZKWbNnRQ=
-----END SIGNATURE-----
```https://gitlab.torproject.org/tpo/core/tor/-/issues/1240stop calling getsockname if accept returns a bad address2020-06-27T14:09:39ZSebastian Hahnstop calling getsockname if accept returns a bad addressr1eo| can anyone explain: 1) why connection_handle_listener_read() goes far
if getsockname() failed and do not return after such. 2) why
getsockname() called at all, what purpose for retrieve local addr and
put...r1eo| can anyone explain: 1) why connection_handle_listener_read() goes far
if getsockname() failed and do not return after such. 2) why
getsockname() called at all, what purpose for retrieve local addr and
put it as remote? at least fail of check_sockaddr() can be triggered
remotely in theory.
r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html it's
introduced getsockname(). but I have the same questions still. And one:
if accept() failed to return correct peer-address, then getpeername()
failing too? http://archives.neohapsis.com/archives/bind/2001/0025.html
http://www.mail-archive.com/freebsd-net@freebsd.org/msg00901.html
funny, but such accepted conn with zero addr is broken anyway. so if tor
filled it with self addr bug him. wonder if it exploitable for spoofing log
at least.
r1eo| someone nmap'ed moria in 2005.
r1eo| just for clear: nothing stops sending created cell and other for today even
if addr faked.
r1eo| http://archives.seul.org/or/cvs/Apr-2005/msg00100.html "This just
happened on moria2"
r1eo| http://paste.debian.net/58458/plain/58458 prevent fooling themself.
socket returned by accept() with zero addr, as result of scan and timing
issues in some kernels. such conn is broken.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1241routerlists read from torrc not concatenated2020-06-27T14:09:38ZTracrouterlists read from torrc not concatenated[ If a list of nodes is specified in the torrc like this:
ExcludeNodes $7360815c9f8471ba6a9335d00c1c1ef4e9c1162d
ExcludeNodes $73ecf797130872f13ccd2cc051bd98ba68a8c781
ExcludeNodes $2b560cda2b2faf392bec929aae7215f4e8c08af8
...[ If a list of nodes is specified in the torrc like this:
ExcludeNodes $7360815c9f8471ba6a9335d00c1c1ef4e9c1162d
ExcludeNodes $73ecf797130872f13ccd2cc051bd98ba68a8c781
ExcludeNodes $2b560cda2b2faf392bec929aae7215f4e8c08af8
ExcludeNodes $437492a449c407425b58ef530f4461d9ed9b28fa
only the last entry ends up in the final rotuerlist. It would be desirable
if subsequent lines were concatenated into the final list. ]
[ I've never been one for treating comments as 'authoritative', but... the
comment preceeding src\or\config.c:config_assign indicates several
behaviors, in particular this one occurs when ((use_defaults == 0) &&
(clear_first == 0)). ]
* Here are the use cases:
* 1. A non-empty AllowInvalid line in your torrc. Appends to current
* if linelist, replaces current if csv.
* 2. An empty AllowInvalid line in your torrc. Should clear it.
* 3. "RESETCONF AllowInvalid" sets it to default.
* 4. "SETCONF AllowInvalid" makes it NULL.
* 5. "SETCONF AllowInvalid=foo" clears it and sets it to "foo".
*
* Use_defaults Clear_first
* 0 0 "append"
* 1 0 undefined, don't use
* 0 1 "set to null first"
* 1 1 "set to defaults first"
* Return 0 on success, -1 on bad key, -2 on bad value.
src\or\config.c:config_assign_value:
case CONFIG_TYPE_ROUTERSET:
[ If there is already a routerset, delete it, and create a new, empty one to
fill in: ]
if (*(routerset_t**)lvalue) {
routerset_free(*(routerset_t**)lvalue);
}
*(routerset_t**)lvalue = routerset_new();
if (routerset_parse(*(routerset_t**)lvalue, c->value, c->key)<0) {
tor_snprintf(buf, sizeof(buf), "Invalid exit list '%s' for option '%s'",
c->value, c->key);
*msg = tor_strdup(buf);
return -1;
}
break;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovaTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1242src\or\rendclient.c:lookup_last_hid_serv_request: heap buffer overrun2020-06-27T14:09:38ZTracsrc\or\rendclient.c:lookup_last_hid_serv_request: heap buffer overrunsrc\or\rendclient.c:lookup_last_hid_serv_request:
lookup_last_hid_serv_request(routerstatus_t *hs_dir,
const char *desc_id_base32, time_t now, int set)
[ Allocate enough memory to hold a pointer to a time_t...src\or\rendclient.c:lookup_last_hid_serv_request:
lookup_last_hid_serv_request(routerstatus_t *hs_dir,
const char *desc_id_base32, time_t now, int set)
[ Allocate enough memory to hold a pointer to a time_t (4 bytes on a 32-bit box). ]
last_request_ptr = tor_malloc_zero(sizeof(time_t *));
[ Write a time_t (8 bytes) into that location; heap buffer overrun: ]
*last_request_ptr = now;
[ This might "work" if your allocator defaults to 8-byte or greater alignment of request; but such behavior is not reliable. ]
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: aakovahttps://gitlab.torproject.org/tpo/core/tor/-/issues/1243compliation errors on last git origin/master2020-06-27T14:09:38ZTraccompliation errors on last git origin/masterHello,
i have try to build Tor from last git commit : commit 30b6fe6e9b7cae25bd87d436eb4f78300313c94f and have a couple errors on compilation.
t -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id -Woverride-init -Wst...Hello,
i have try to build Tor from last git commit : commit 30b6fe6e9b7cae25bd87d436eb4f78300313c94f and have a couple errors on compilation.
t -Wold-style-definition -Waddress -Wmissing-noreturn -Wnormalized=id -Woverride-init -Wstrict-overflow=1 -Wextra -Warray-bounds -MT dns.o -MD -MP -MF .deps/dns.Tpo -c -o dns.o dns.c
dns.c: In function ‘configure_nameservers’:
dns.c:1246: error: too many arguments to function ‘evdns_base_set_option’
dns.c:1247: error: too many arguments to function ‘evdns_base_set_option’
dns.c:1249: error: too many arguments to function ‘evdns_base_set_option’
dns.c:1250: error: too many arguments to function ‘evdns_base_set_option’
dns.c:1254: error: too many arguments to function ‘evdns_base_set_option’
dns.c:1256: error: too many arguments to function ‘evdns_base_set_option’
make[2]: *** [dns.o] Erreur 1
make[2]: quittant le répertoire « /home/stars/tor/src/or »
make[1]: *** [install-recursive] Erreur 1
make[1]: quittant le répertoire « /home/stars/tor/src »
make: *** [install-recursive] Erreur 1
I run kubuntu Lucid alpha2 on x86 64 Linux KDELucidTest 2.6.32-12-generic legacy/trac#17-Ubuntu SMP Fri Feb 5 08:16:30 UTC 2010 x86_64 GNU/Linux
SwissTorExit
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: starshttps://gitlab.torproject.org/tpo/core/tor/-/issues/1244resolve_my_address: Assertion rent->h_length == 4. IPv6 issue?2020-06-27T14:09:38ZTracresolve_my_address: Assertion rent->h_length == 4. IPv6 issue?/etc/hosts
2001:XXX::Y cheako cheako.broker.freenet6.net cheako.local
hostname
cheako.broker.freenet6.net
/etc/tor/torrc
## Configuration file for a typical Tor user
## Last updated 12 April 2009 for Tor 0.2.1.14-rc.
## (May or may not.../etc/hosts
2001:XXX::Y cheako cheako.broker.freenet6.net cheako.local
hostname
cheako.broker.freenet6.net
/etc/tor/torrc
## Configuration file for a typical Tor user
## Last updated 12 April 2009 for Tor 0.2.1.14-rc.
## (May or may not work for much older or much newer versions of Tor.)
##
## Lines that begin with "## " try to explain what's going on. Lines
## that begin with just "#" are disabled commands: you can enable them
## by removing the "#" symbol.
##
## See 'man tor', or https://www.torproject.org/tor-manual.html,
## for more options you can use in this file.
##
## Tor will look for this file in various places based on your platform:
## https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#torrc
## Replace this with "SocksPort 0" if you plan to run Tor only as a
## relay, and not make any local application connections yourself.
SocksPort 9050 # what port to open for local application connections
SocksListenAddress 0.0.0.0 # listen on this IP:port also
## Entry policies to allow/deny SOCKS requests based on IP address.
## First entry that matches wins. If no SocksPolicy is set, we accept
## all (and only) requests from SocksListenAddress.
#SocksPolicy accept 192.168.0.0/16
#SocksPolicy reject *
## Logs go to stdout at level "notice" unless redirected by something
## else, like one of the below lines. You can have as many Log lines as
## you want.
##
## We advise using "notice" in most cases, since anything more verbose
## may provide sensitive information to an attacker who obtains the logs.
##
## Send all messages of level 'notice' or higher to /var/log/tor/notices.log
#Log notice file /var/log/tor/notices.log
## Send every possible message to /var/log/tor/debug.log
#Log debug file /var/log/tor/debug.log
## Use the system log instead of Tor's logfiles
#Log notice syslog
## To send all messages to stderr:
#Log debug stderr
## Uncomment this to start the process in the background... or use
## --runasdaemon 1 on the command line. This is ignored on Windows;
## see the FAQ entry if you want Tor to run as an NT service.
#RunAsDaemon 1
## The directory for keeping all the keys/etc. By default, we store
## things in $HOME/.tor on Unix, and in Application Data\tor on Windows.
#DataDirectory /var/lib/tor
## The port on which Tor will listen for local connections from Tor
## controller applications, as documented in control-spec.txt.
#ControlPort 9051
## If you enable the controlport, be sure to enable one of these
## authentication methods, to prevent attackers from accessing it.
#HashedControlPassword 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C
#CookieAuthentication 1
############### This section is just for location-hidden services ###
## Once you have configured a hidden service, you can look at the
## contents of the file ".../hidden_service/hostname" for the address
## to tell people.
##
## HiddenServicePort x y:z says to redirect requests on port x to the
## address y:z.
#HiddenServiceDir /var/lib/tor/hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServiceDir /var/lib/tor/other_hidden_service/
#HiddenServicePort 80 127.0.0.1:80
#HiddenServicePort 22 127.0.0.1:22
################ This section is just for relays #####################
#
## See https://www.torproject.org/docs/tor-doc-relay for details.
## Required: what port to advertise for incoming Tor connections.
ORPort 9001
## If you want to listen on a port other than the one advertised
## in ORPort (e.g. to advertise 443 but bind to 9090), uncomment the
## line below too. You'll need to do ipchains or other port forwarding
## yourself to make this work.
#ORListenAddress 0.0.0.0:9090
## A handle for your relay, so people don't have to refer to it by key.
Nickname ChappOik4
## The IP address or full DNS name for your relay. Leave commented out
## and Tor will guess.
#Address nyso.is-a-geek.org
## Define these to limit how much relayed traffic you will allow. Your
## own traffic is still unthrottled. Note that RelayBandwidthRate must
## be at least 20 KBytes.
RelayBandwidthRate 50 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 100 KBytes # But allow bursts up to 200KB/s (1600Kbps)
## Contact info to be published in the directory, so we can contact you
## if your relay is misconfigured or something else goes wrong. Google
## indexes this, so spammers might also collect it.
#ContactInfo Mike Mestnik <mmestnik@nagios.com>
## You might also include your PGP or GPG fingerprint if you have one:
ContactInfo 2048R/C1DA1FAA Mike Mestnik <mmestnik@nagios.com>
## Uncomment this to mirror directory information for others. Please do
## if you have enough bandwidth.
DirPort 9030 # what port to advertise for directory connections
## If you want to listen on a port other than the one advertised
## in DirPort (e.g. to advertise 80 but bind to 9091), uncomment the line
## below too. You'll need to do ipchains or other port forwarding yourself
## to make this work.
#DirListenAddress 0.0.0.0:9091
## Uncomment to return an arbitrary blob of html on your DirPort. Now you
## can explain what Tor is if anybody wonders why your IP address is
## contacting them. See contrib/tor-exit-notice.html for a sample.
DirPortFrontPage /etc/tor/exit-notice.html
## Uncomment this if you run more than one Tor relay, and add the identity
## key fingerprint of each Tor relay you control, even if they're on
## different networks. You declare it here so Tor clients can avoid
## using more than one of your relays in a single circuit. See
## https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#MultipleServers
#MyFamily $keyid,$keyid,...
## A comma-separated list of exit policies. They're considered first
## to last, and the first match wins. If you want to _replace_
## the default exit policy, end this with either a reject *:* or an
## accept *:*. Otherwise, you're _augmenting_ (prepending to) the
## default exit policy. Leave commented to just use the default, which is
## described in the man page or at
## https://www.torproject.org/documentation.html
##
## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses
## for issues you might encounter if you use the default exit policy.
##
## If certain IPs and ports are blocked externally, e.g. by your firewall,
## you should update your exit policy to reflect this -- otherwise Tor
## users will be told that those destinations are down.
##
#ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more
#ExitPolicy accept *:119 # accept nntp as well as default exit policy
#ExitPolicy reject *:* # no exits allowed
#
## Bridge relays (or "bridges") are Tor relays that aren't listed in the
## main directory. Since there is no complete public list of them, even if an
## ISP is filtering connections to all the known Tor relays, they probably
## won't be able to block all the bridges. Also, websites won't treat you
## differently because they won't know you're running Tor. If you can
## be a real relay, please do; but if not, be a bridge!
BridgeRelay 1
ExitPolicy reject *:*
DNSPort 9053
AutomapHostsOnResolve 1
ifconfig
br0 Link encap:Ethernet HWaddr 00:24:8c:67:34:60
inet addr:192.168.167.100 Bcast:192.168.167.255 Mask:255.255.255.0
inet6 addr: 2001:XXX::Y/64 Scope:Global
inet6 addr: fe80::224:8cff:fe67:3460/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2912290 errors:0 dropped:0 overruns:0 frame:0
TX packets:3056967 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1875328824 (1.7 GiB) TX bytes:2698210581 (2.5 GiB)
br1 Link encap:Ethernet HWaddr 00:24:8c:67:34:60
inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3077659 errors:0 dropped:0 overruns:0 frame:0
TX packets:3098061 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:2553730437 (2.3 GiB) TX bytes:2044123568 (1.9 GiB)
eth0 Link encap:Ethernet HWaddr 00:24:8c:67:34:60
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:6264318 errors:0 dropped:0 overruns:0 frame:0
TX packets:6444578 errors:0 dropped:0 overruns:0 carrier:2
collisions:0 txqueuelen:1000
RX bytes:456557751 (435.4 MiB) TX bytes:686818471 (655.0 MiB)
Interrupt:27
eth0.2 Link encap:Ethernet HWaddr 00:24:8c:67:34:60
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2912290 errors:0 dropped:0 overruns:0 frame:0
TX packets:3056969 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1875341897 (1.7 GiB) TX bytes:2698210749 (2.5 GiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:383043 errors:0 dropped:0 overruns:0 frame:0
TX packets:383043 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:748979643 (714.2 MiB) TX bytes:748979643 (714.2 MiB)
tun6 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: 2001:XXXX::YYYY/128 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:59701 errors:0 dropped:0 overruns:0 frame:0
TX packets:55738 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:28478989 (27.1 MiB) TX bytes:9009484 (8.5 MiB)
DSL modem ifconfig
br0 Link encap:Ethernet HWaddr 00:24:7B:55:D0:48
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:4906591 errors:0 dropped:0 overruns:0 frame:0
TX packets:4713527 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3363891567 (3208.0 Mb) TX bytes:3368580587 (3212.5 Mb)
br1 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
br2 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
br3 Link encap:Ethernet HWaddr 00:00:00:00:00:00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
eth0 Link encap:Ethernet HWaddr 00:24:7B:55:D0:48
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:2450062 errors:0 dropped:0 overruns:0 frame:0
TX packets:2286139 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1530282543 (1459.3 Mb) TX bytes:1826189017 (1741.5 Mb)
imq0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
UP RUNNING NOARP MTU:1500 Metric:1 ASYMMTU:1500
RX packets:2252586 errors:0 dropped:0 overruns:0 frame:0
TX packets:2252586 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1774849795 (1692.6 Mb) TX bytes:1774849795 (1692.6 Mb)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1 ASYMMTU:0
RX packets:88 errors:0 dropped:0 overruns:0 frame:0
TX packets:88 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:27856 (27.2 kb) TX bytes:27856 (27.2 kb)
nas0 Link encap:Ethernet HWaddr 00:24:7B:55:D0:49
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:2456555 errors:0 dropped:0 overruns:0 frame:0
TX packets:2427381 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1833617196 (1748.6 Mb) TX bytes:1566664920 (1494.0 Mb)
ppp0 Link encap:Point-Point Protocol
inet addr:174.X.Y.Z P-t-P:207.225.140.218 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 ASYMMTU:1500
RX packets:2433773 errors:0 dropped:0 overruns:0 frame:0
TX packets:2404731 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:1778703990 (1696.3 Mb) TX bytes:1488739597 (1419.7 Mb)
usb0 Link encap:Ethernet HWaddr 00:24:7B:55:D0:4A
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 ASYMMTU:1500
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cheakohttps://gitlab.torproject.org/tpo/core/tor/-/issues/1245circuit_build_times_add_time: Assertion time <= BUILD_TIME_MAX failed2020-06-27T14:09:38ZRoger Dingledinecircuit_build_times_add_time: Assertion time <= BUILD_TIME_MAX failedFeb 09 09:31:15.047 [Notice] Your system clock just jumped 26715 seconds
forward; assuming established circuits no longer work.
Feb 09 09:31:13.982 [Error] circuit_build_times_add_time(): Bug:
circuitbuild.c:191: circuit_build_times_add_...Feb 09 09:31:15.047 [Notice] Your system clock just jumped 26715 seconds
forward; assuming established circuits no longer work.
Feb 09 09:31:13.982 [Error] circuit_build_times_add_time(): Bug:
circuitbuild.c:191: circuit_build_times_add_time: Assertion time <=
BUILD_TIME_MAX failed; aborting.
I hibernated my laptop last night, and when I turned it back on, Tor
I guess was in the middle of building a circuit. It decided to time it
out, since it had been building all night (while the machine was off).
#0 0xb7f09424 in __kernel_vsyscall ()
#1 0xb7bb0640 in raise () from /lib/i686/cmov/libc.so.6
legacy/trac#2 0xb7bb2018 in abort () from /lib/i686/cmov/libc.so.6
legacy/trac#3 0x0809b6a9 in circuit_build_times_add_time (cbt=0x815b100, time=4294966199)
at circuitbuild.c:191
legacy/trac#4 0x0809f1a7 in circuit_send_next_onion_skin (circ=0x89f4b60)
at circuitbuild.c:1493
legacy/trac#5 0x08061b8c in connection_edge_process_relay_cell (cell=0xbfe02a98,
circ=0x89f4b60, conn=0x0, layer_hint=0x87ee400) at relay.c:1159
legacy/trac#6 0x08062879 in circuit_receive_relay_cell (cell=0xbfe02a98, circ=0x89f4b60,
cell_direction=CELL_DIRECTION_IN) at relay.c:200
legacy/trac#7 0x080aba46 in command_process_cell (cell=0xbfe02a98, conn=0x884fe58)
at command.c:417
legacy/trac#8 0x080c98f1 in connection_or_process_cells_from_inbuf (conn=0x884fe58)
at connection_or.c:1247
legacy/trac#9 0x080ba62c in connection_process_inbuf (conn=0x884fe58, package_partial=6)
at connection.c:3181
legacy/trac#10 0x080bf0b1 in connection_handle_read (conn=0x884fe58) at connection.c:2370
legacy/trac#11 0x08052980 in conn_read_callback (fd=15, event=2, _conn=0x884fe58)
at main.c:479
legacy/trac#12 0xb7e9d9e2 in event_base_loop () from /usr/lib/libevent-1.3e.so.1
legacy/trac#13 0x080524ba in do_main_loop () at main.c:1512
legacy/trac#14 0x08052795 in tor_main (argc=9, argv=0xbfe030d4) at main.c:2137
legacy/trac#3 0x0809b6a9 in circuit_build_times_add_time (cbt=0x815b100, time=4294966199)
at circuitbuild.c:191
191 tor_assert(time <= BUILD_TIME_MAX);
(gdb) print time
$1 = 4294966199
(gdb) up
legacy/trac#4 0x0809f1a7 in circuit_send_next_onion_skin (circ=0x89f4b60)
at circuitbuild.c:1493
1493 circuit_build_times_add_time(&circ_times, (build_time_t)timediff);
(gdb) print timediff
$2 = 0
(gdb) up
legacy/trac#5 0x08061b8c in connection_edge_process_relay_cell (cell=0xbfe02a98,
circ=0x89f4b60, conn=0x0, layer_hint=0x87ee400) at relay.c:1159
1159 if ((reason=circuit_send_next_onion_skin(TO_ORIGIN_CIRCUIT(circ)))<0) {
(gdb) print *circ
$3 = {magic = 892424771, n_conn_cells = {head = 0x0, tail = 0x0, n = 0,
insertion_times = 0x0}, n_conn = 0x884fe58, n_circ_id = 47247,
n_hop = 0x0, streams_blocked_on_n_conn = 0, streams_blocked_on_p_conn = 0,
state = 3 '\003', purpose = 5 '\005', package_window = 1000,
deliver_window = 1000, n_conn_onionskin = 0x0,
timestamp_created = 1265725875, timestamp_dirty = 0, highres_created = {
tv_sec = 1265725875, tv_usec = 58412}, marked_for_close = 0,
marked_for_close_file = 0x0, next_active_on_n_conn = 0x0,
prev_active_on_n_conn = 0x0, next = 0x8b4c290, dirreq_id = 0, n_cell_ewma = {
last_adjusted_tick = 126572587, cell_count = 0, is_for_p_conn = 0,
heap_index = -1}}
[Automatically added by flyspray2trac: Operating System: All]0.2.2.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1247bootstrap hickups when network is down2020-07-24T12:20:45Zanonymbootstrap hickups when network is downIn short, if the network is down when tor starts for the very first time
the bootstrapping process might take a very long time (or never finish)
even if the network is connected just shortly after tor starts and finds
out that it's offli...In short, if the network is down when tor starts for the very first time
the bootstrapping process might take a very long time (or never finish)
even if the network is connected just shortly after tor starts and finds
out that it's offline.
This has been a major issue in live distributions like Incognito and amnesia
for years becase:
1) they use a system-wide tor process that starts before xorg, and since
they use NetworkManager, the network isn't up until they xorg has started.
2) they have an empty tor data directory, so they must bootstrap each
time they start.
That windows of 10-20 seconds or so of no network can make tor take
anything from no time to hours to days to finally realise that the
network is there and it can finish bootstrapping and start working. The
time it takes seems extremely random, but usually it's done within 10
minutes or so, but that's still very bad.
The only thing that seems to speed this up is to restart tor when the
network is up (which admittedly is quite easy to automate with something
like if-up.d or NetworkManagers event dispatcher). When that is done,
tor immediately bootstraps and is usable within 10 seconds.
It would of course be preferable if tor could handle it cleanly and fast
itself, or if it could be "prodded" somehow. For instance, I hoped
sending tor a SIGHUP would make it re-try getting in touch with the
directories, but it doesn't. Having an application use tor (so that it
"optimistically will try to fetch a directory") doesn't help either. To
me it seems that if tor is stuck with getting dir info, any external
prodding to get it to do it again is ignored.
I can easily reproduce this problem the following way:
1) start amnesia in virtualbox and let it get into an X session.
2) stop the tor process and disconnects the network.
3) clear the tor data directory and start tor.
4) wait one minute, then connect the network.
5) check the logs for how long it takes until tor bootstraps since
the network was connected.
I'll attach a debug level log of how this looks for me.
My desired result woulb be that the time measured in step 5
would be at most 10 seconds. Optimally tor should be able to detect
that the network is up again completely on its own, but I'm
equally happy if it could be "prodded" to check for the net again,
like seding tor a SIGHUP, application request, control port command
or anything that can be easily scripted.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1248Tor bridges log their fingerprint during startup2020-06-27T14:09:38ZSebastian HahnTor bridges log their fingerprint during startupI think that behaviour should be changed to use safelogging here, because when
people share their notice level log, they reveal their bridge's fingerprint otherwise.
Will make a patch if people agree. Nick, Roger?
[Automatically added ...I think that behaviour should be changed to use safelogging here, because when
people share their notice level log, they reveal their bridge's fingerprint otherwise.
Will make a patch if people agree. Nick, Roger?
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1250strange SOCKS error code when connecting to a hidden service using the wrong ...2020-06-27T14:09:37ZTracstrange SOCKS error code when connecting to a hidden service using the wrong portI set up two distinct hidden services, HTTP(80) and SSH(22) on my machine
(since I didn't know you could put multiple records under a single service).
Today I made the mistake of connecting to the HTTP service using port 22
(took the HT...I set up two distinct hidden services, HTTP(80) and SSH(22) on my machine
(since I didn't know you could put multiple records under a single service).
Today I made the mistake of connecting to the HTTP service using port 22
(took the HTTP service's url, stripped the http part, entered into PuTTY).
The returned error code was 0x02 = connection not allowed by ruleset.
This message made me very confused, since it somehow implies that my SOCKS
settings were somehow blocking the connection. But that was not the case.
What happened on the TOR back-end was, my request got received, the remote
TOR server found that my port was not on the list of ports associated with
that particular onion hostname, and rejected the connection attempt.
Finally, my TOR client, trying to be as clever as informative as possible,
returned that specific error code.
While the error code does in some sense describe what happened internally,
I do not think that 0x02 is appropriate for this scenario. I did not study
the SOCKS specification, however I'm assuming that "ruleset" refers to the
access control rules implemented on the daemon that's providing the tunnel,
and not on the remote endpoint (the target machine is oblivious to SOCKS
and just sees an incoming TCP connection, so it can't react in any way).
My proposal is to change this error code to reduce confusion and help users
identify the cause of the problem (between keyboard and chair in my case :).
Which one to use? I suggest 0x05 = connection refused by destination host.
"Connection refused" is what you normally get if the destination machine has
nothing running on the requested port (and there's no firewall to hide that).
Visualize a single hidden service as a physical machine running somewhere
on the internet, with stuff listening only on ports associated with that HS.
In that case, connecting to a wrong port would give TCP "connection refused".
And TOR hidden service isolation seems to be making virtual servers like this.
So why shouldn't it be returning this error code instead?
PS: Also think of SOCKS client software that might get confused by this error code.
PS2: You could test the effectiveness of this change by taking a group of people,
giving them a setup like mine, asking them to troubleshoot the issue and timing them.
Whichever group can figure out what the problem is faster has the better error code.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ultramageTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/12520.2.1.23 deb can't do tls renegotiation2020-06-27T14:09:37ZRoger Dingledine0.2.1.23 deb can't do tls renegotiationzzz_> Hello, I am using Debian Sid with Tor 0.2.1.23 and Vidalia 0.2.7. When
I try to connect to the Tor network, Vidalia shows this error: [Warning] TLS
error: unexpected close while renegotiating. Is this is a known problem?
> zzz_: a...zzz_> Hello, I am using Debian Sid with Tor 0.2.1.23 and Vidalia 0.2.7. When
I try to connect to the Tor network, Vidalia shows this error: [Warning] TLS
error: unexpected close while renegotiating. Is this is a known problem?
> zzz_: are you using tor as a client, and it's failing?
zzz_> arma: Yes, I am running as a client only. It has started to give this
error very recently.
zzz_> arma: Actually the Debian changelog might give us a hint:
http://packages.debian.org/changelogs/pool/main/t/tor/tor_0.2.1.23-1/changelog
See also http://archives.seul.org/or/talk/Feb-2010/msg00159.html which is another
person reporting this problem.
[Automatically added by flyspray2trac: Operating System: All]weasel (Peter Palfrader)weasel (Peter Palfrader)https://gitlab.torproject.org/tpo/core/tor/-/issues/1253Identify nodes by hostname to avoid proxy IP blocking2020-06-27T14:09:37ZTracIdentify nodes by hostname to avoid proxy IP blockingTor use IP addresses for connection to other relays at the moment.
Sometimes all IP addresses is blocked on proxy servers and allowed DNS names only.
It would be good if tor have an option to go by DNS instead of IP.
[Automatically adde...Tor use IP addresses for connection to other relays at the moment.
Sometimes all IP addresses is blocked on proxy servers and allowed DNS names only.
It would be good if tor have an option to go by DNS instead of IP.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ginerTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1254supply correct type to sizeof2020-06-27T14:09:37ZTracsupply correct type to sizeofin aes.c
271c271
< memset(cipher, 0, sizeof(cipher));
---
> memset(cipher, 0, sizeof(aes_cnt_cipher_t));
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ekirin aes.c
271c271
< memset(cipher, 0, sizeof(cipher));
---
> memset(cipher, 0, sizeof(aes_cnt_cipher_t));
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ekirhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1255correct NULL check on desc in rend_encode_v2_descriptors2020-06-27T14:09:37ZTraccorrect NULL check on desc in rend_encode_v2_descriptorsdesc is dereferenced with desc->pk, and then checked for NULL.
rendcommon.c:459,469
crypto_pk_env_t *service_key = auth_type == REND_STEALTH_AUTH ?
client_key : desc->pk;
tor_assert(service_key);
if...desc is dereferenced with desc->pk, and then checked for NULL.
rendcommon.c:459,469
crypto_pk_env_t *service_key = auth_type == REND_STEALTH_AUTH ?
client_key : desc->pk;
tor_assert(service_key);
if (auth_type == REND_STEALTH_AUTH) {
descriptor_cookie = smartlist_get(client_cookies, 0);
tor_assert(descriptor_cookie);
}
if (!desc) {
log_warn(LD_REND, "Could not encode v2 descriptor: No desc given.");
return -1;
}
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ekirhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1256Check for NULL before referencing hop->extend_info, not after2020-06-27T14:09:37ZTracCheck for NULL before referencing hop->extend_info, not afterDereference before checking for NULL.
circuitbuild.c:1112,1118
if (!hop)
break;
id = hop->extend_info->identity_digest;
if (!verbose && hop->state != CPATH_STATE_OPEN)
break;
if (!hop->extend_info)
break;
[Automatica...Dereference before checking for NULL.
circuitbuild.c:1112,1118
if (!hop)
break;
id = hop->extend_info->identity_digest;
if (!verbose && hop->state != CPATH_STATE_OPEN)
break;
if (!hop->extend_info)
break;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ekirhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1257signed_descriptor_get_body_impl doesn't guarantee null-terminated string2020-06-27T14:09:37ZSebastian Hahnsigned_descriptor_get_body_impl doesn't guarantee null-terminated stringWe're using strings returned from signed_descriptor_get_body_impl()
as if they were null-terminated in two places, but its documentation
states that this isn't guaranteed. The two places I found are:
in signed_desc_append_to_journal(), ...We're using strings returned from signed_descriptor_get_body_impl()
as if they were null-terminated in two places, but its documentation
states that this isn't guaranteed. The two places I found are:
in signed_desc_append_to_journal(), we call strlen on it
in routerlist_reparse_old(), we call router_parse_entry_from_string() on
it, and further down the chain we use strstr
A sidecomment by rieo from a while back made me look at this.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/1258Tor allows non-ASCII chars in contact line2020-06-27T14:09:37ZKarsten LoesingTor allows non-ASCII chars in contact lineTor allows non-ASCII chars in the contact line of router descriptors which
a) breaks tools parsing descriptors and
b) doesn't conform to dir-spec.txt.
Should we disallow non-ASCII chars in the future by being more strict when
verifyin...Tor allows non-ASCII chars in the contact line of router descriptors which
a) breaks tools parsing descriptors and
b) doesn't conform to dir-spec.txt.
Should we disallow non-ASCII chars in the future by being more strict when
verifying torrc and when uploading descriptors to the directory authorities?
Or should we change dir-spec.txt to allow more characters in the contact line?
Or did I miss something?
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1259FTP seems broken2020-06-27T14:09:36ZMike PerryFTP seems brokenDespite the fact that we tell Firefox to use SOCKS for FTP, it appears as if it is broken. This probably is a
firefox bug, but filing it anyway to remind myself to look deeper into it later. I should test this with an
ssh socks proxy and...Despite the fact that we tell Firefox to use SOCKS for FTP, it appears as if it is broken. This probably is a
firefox bug, but filing it anyway to remind myself to look deeper into it later. I should test this with an
ssh socks proxy and see what happens.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1263ICMP and DNS problems under load2020-06-27T14:09:36ZTracICMP and DNS problems under loadOS: gentoo linux up to date
File Edit Options Buffers Tools Help
when Tor does not run, the OS and the network is r...OS: gentoo linux up to date
File Edit Options Buffers Tools Help
when Tor does not run, the OS and the network is running as
expected. When Tor runs with 256kBps and 512kBps burst, after
about 15minutes after the available bw to Tor is fully used, some
network capabilities of the system are degraded:
* ping -f 8.8.8.8 reports more than 70% of packet loss
* traceroutes don't finish (stars for every nodes)
* DNS requests (w/ dig) fail to query _any_ DNS server 9 times
over 10
All that is fully functional when Tor is not running.
Moreover, with that setup, Tor reports the following lines in the
logs:
00:39:26 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:39:26 [WARN] eventdns: All nameservers have failed
00:33:25 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:33:25 [WARN] eventdns: All nameservers have failed
00:32:59 [NOTICE] eventdns: Nameserver 8.8.4.4 is back up
00:32:59 [WARN] eventdns: All nameservers have failed
00:29:54 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:29:54 [WARN] eventdns: All nameservers have failed
00:26:43 [NOTICE] eventdns: Nameserver 8.8.8.8 is back up
00:26:42 [WARN] eventdns: All nameservers have failed
load of the system is near 0, there is no memory problems.
If I set the available bw to Tor to 2MBps, Tor uses only about
400kBps. I have no logs like above, and the dig command can reach
the servers 9 times over 10. The traceroute command also perform
nearly as well as without Tor.
I can't assess right now if the ISP has kind of traffic
filtering. Checks about that are ongoing.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: grumpy3Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1266failure creating directory with accented letters2020-06-27T14:09:36ZTracfailure creating directory with accented lettersI get an error which involves tor trying to create a directory with accented letters.
This keeps tor from working at all, so it's a high severity bug.
(I changed the directory name below for security purposes, but kept the same style).
...I get an error which involves tor trying to create a directory with accented letters.
This keeps tor from working at all, so it's a high severity bug.
(I changed the directory name below for security purposes, but kept the same style).
fev 28 13:26:40.909 [Warning] Error creating directory "C:\\Users\\Abra\343o Lima\\AppData\\Roaming\\tor": Invalid argument
fev 28 13:26:40.909 [Warning] Failed to parse/validate config: Couldn't access/create private data directory ""C:\\Users\\Abra\343o Lima\\AppData\\Roaming\\tor""
fev 28 13:26:40.909 [Error] Reading config failed--see warnings above.
I then tried to fix the directory in the advanced config of vidalia to:
C:\Users\Abraão Lima\AppData\Roaming\Tor
but that too didn't work with the following error msgs in the log:
fev 28 14:11:44.360 [Warning] Error creating directory "C:\\Users\\Abraão Lima\\AppData\\Roaming\\tor": Invalid argument
fev 28 14:11:44.360 [Warning] Failed to parse/validate config: Couldn't access/create private data directory ""C:\\Users\\Abraão Lima\\AppData\\Roaming\\tor""
fev 28 14:11:44.360 [Error] Reading config failed--see warnings above.
[Automatically added by flyspray2trac: Operating System: Windows 7]
**Trac**:
**Username**: toruserTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/1267assertion failed in unit test2020-06-27T14:09:36ZTracassertion failed in unit testWhen running 'make check' with tor-0.1.2.24 on Linux x86_64 I get the following (in util):
File test.c: line 1300 (test_util): assertion failed: (tv_udiff(&start, &end) >=
-5000)
[Automatically added by flyspray2trac: Operating System:...When running 'make check' with tor-0.1.2.24 on Linux x86_64 I get the following (in util):
File test.c: line 1300 (test_util): assertion failed: (tv_udiff(&start, &end) >=
-5000)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Athabahttps://gitlab.torproject.org/tpo/core/tor/-/issues/1268bug in the latest update 0.2.1.24 - windows2020-06-27T14:09:36ZTracbug in the latest update 0.2.1.24 - windows
I just updated to the latest Tor. The following is a bug notice i got the first time it was fired up.
Mar 02 08:46:40.968 [Warning] router_orport_found_reachable(): Bug: ORPort found reachable, but I have no routerinfo yet. Failing t...
I just updated to the latest Tor. The following is a bug notice i got the first time it was fired up.
Mar 02 08:46:40.968 [Warning] router_orport_found_reachable(): Bug: ORPort found reachable, but I have no routerinfo yet. Failing to inform controller of success.
it appars that it took 13 hrs before it corrected and started working properly. Not sure reason why.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: jon2020