Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2016-04-08T08:17:30Zhttps://gitlab.torproject.org/legacy/trac/-/issues/5955orbot getting stuck till the yellow bar and showing "waiting"2016-04-08T08:17:30ZTracorbot getting stuck till the yellow bar and showing "waiting"I'm really tired of searching forums to get to work orbot but with no success
Plz help
Model number HTC desire hd
Rom : android revolution hd 6.3.2
Android version :2.3.5
Sence version : 3.0
Kernel : 2..6.35.14_rcmixed3d_acs_ace_ncr_v11...I'm really tired of searching forums to get to work orbot but with no success
Plz help
Model number HTC desire hd
Rom : android revolution hd 6.3.2
Android version :2.3.5
Sence version : 3.0
Kernel : 2..6.35.14_rcmixed3d_acs_ace_ncr_v11.1-ge213fe7-dirtyken@klquicksall #12
Baseband : 12.56.69.25u_26.10.04.03_m
Thanks in advAnce
**Trac**:
**Username**: nazzzzzNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5890500 Internal Privoxy Error2016-04-07T11:24:20ZTrac500 Internal Privoxy ErrorI sonetimes get 500 Internal Privoxy Error with Could not load file forwarding-failed or something like that.
**Trac**:
**Username**: mattiI sonetimes get 500 Internal Privoxy Error with Could not load file forwarding-failed or something like that.
**Trac**:
**Username**: mattiNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5888Orbot does not start at boot in Android 2.3.42013-10-16T18:58:40ZTracOrbot does not start at boot in Android 2.3.4Orbot does start at boot in Android 2.3.4 Samsung Galaxy Mini even though I selected such an option. The phone is not rooted.
**Trac**:
**Username**: mattiOrbot does start at boot in Android 2.3.4 Samsung Galaxy Mini even though I selected such an option. The phone is not rooted.
**Trac**:
**Username**: mattiNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5469Orbot: can't specify node restrictions2020-06-13T01:02:26ZTracOrbot: can't specify node restrictionsI'm using Orbot (v0.2.3.10-alpha-1.0.7-FINAL, on Android ICS v4.0.1) and I can't seem to get the exit node I request.
In the Exit and Entrance Node fields I have "{us}" entered, yet sometimes I get IP's outside the US. Yesterday I got a ...I'm using Orbot (v0.2.3.10-alpha-1.0.7-FINAL, on Android ICS v4.0.1) and I can't seem to get the exit node I request.
In the Exit and Entrance Node fields I have "{us}" entered, yet sometimes I get IP's outside the US. Yesterday I got a UK ip.
Also, at random (usually after 30 minutes or so) I seem to lose connection to the Tor network without Orbot notifying me. I'm using Pandora from Canada.
**Trac**:
**Username**: dvdwsnNathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5393orbot relay bug - orbot is not setting the relay values into torrc properly c...2020-06-13T01:00:46ZTracorbot relay bug - orbot is not setting the relay values into torrc properly causing orbot to not work when set as relayThis is about the bug discussed with 'n8fr8' on #guardianproject at freenode.
So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones.
I checked with the orbot version '0.2.3.10-alpha-orbot-1.0.7-...This is about the bug discussed with 'n8fr8' on #guardianproject at freenode.
So, the relay functionality you said was broken and needs to be fixed for 'orbot' on smartphones.
I checked with the orbot version '0.2.3.10-alpha-orbot-1.0.7-FINAL' and you have checked with the 'dev branch of the code' as you said (i suppose that means you have checked with latest version of code by compiling and running the latest updated version from git; i will do it too and let you know again). But none seemed to work. In fact, you said you were getting a more significant crash, when you enabled relaying on smartphone for dev branch of code.
You also thought if the problem is: whether the Relay conflict is with transproxying/root or with Tor client connection in general. But, i'm not sure if it later seemed not to be the problem.
Then, you told me to change the torrc file on my android phone, as you said that orbot is not setting the relay values properly which might be the reason for orbot not working as a relay on smartphone.
So, I will do that and let you know about it. I will also keep checking 'https://guardianproject.info/builds/Orbot/' to see if any new dev/debug release is posted.
Thankyou so very much for all your help, Mr.Nathan.
**Trac**:
**Username**: ruki_Nathan FreitasNathan Freitashttps://gitlab.torproject.org/legacy/trac/-/issues/5086"Control socket is not connected" when starting TOR/Vidalia2012-02-11T17:54:50ZTrac"Control socket is not connected" when starting TOR/VidaliaI don't know why. But TOR/Vidalia just stopped working for me. I've never had any problem with it. Just installed and launched without any error messages.
Still, this message pops up:
http://i.imgur.com/Jponv.jpg
"Vidalia was unable to...I don't know why. But TOR/Vidalia just stopped working for me. I've never had any problem with it. Just installed and launched without any error messages.
Still, this message pops up:
http://i.imgur.com/Jponv.jpg
"Vidalia was unable to authenticate to the Tor software. (Control socket is not connected).
Please check your control port authentication settings"
**?!?!?!?! **
Googled for it without any success. Reinstalled Vidalia/TOR **x** times, installed the latest version (Alpha), etc etc. Why won't it work anymore? I havent change any setting at all. Anywhere.
Version: vidalia-bundle-**0.2.3.10-alpha-0.2.15-1**.exe
Windows XP
Please, help.
Thanks in advance,
/K
**Trac**:
**Username**: kalenderTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/4875router_new_address_suggestion is not IPv6 aware2020-06-13T14:16:44ZDavid Fifielddcf@torproject.orgrouter_new_address_suggestion is not IPv6 awareI see this in the debug log when using an IPv6 bridge. I censored the addresses but they are well-formed IPv6 addresses in the log.
```
Jan 08 12:49:16.000 [debug] connection_dir_client_reached_eof(): Received response from directory se...I see this in the debug log when using an IPv6 bridge. I censored the addresses but they are well-formed IPv6 addresses in the log.
```
Jan 08 12:49:16.000 [debug] connection_dir_client_reached_eof(): Received response from directory server '2600:3c01::...:9001': 200 "
OK" (purpose: 6)
Jan 08 12:49:16.000 [debug] router_new_address_suggestion(): Malformed X-Your-Address-Is header "2001:470::...". Ignoring.
```Tor: 0.2.3.x-finalLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/4873[Error] connection_or_handle_event_cb(): Bug: connection_or.c:1281: connectio...2020-06-13T14:16:43ZTrac[Error] connection_or_handle_event_cb(): Bug: connection_or.c:1281: connection_or_handle_event_cb: Assertion handshakes >= 2 failed; aborting.Hi ,
From a couple days, i can't anymore finish the bootstrap with my relay.
I running kubuntu Oneric 64 bits Linux 3.0.0-15-server #25-Ubuntu SMP Mon Jan 2 19:14:55 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
OpenSSL 1.0.1-beta1 03 Jan 2...Hi ,
From a couple days, i can't anymore finish the bootstrap with my relay.
I running kubuntu Oneric 64 bits Linux 3.0.0-15-server #25-Ubuntu SMP Mon Jan 2 19:14:55 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
OpenSSL 1.0.1-beta1 03 Jan 2012
Tor: janv. 08 14:55:34.841 [Notice] Tor v0.2.3.10-alpha-dev (git-59d0a5ae693efe93) (with bufferevents) running on Linux x86_64.
Initialized libevent version 2.1.0-alpha-dev using method epoll (with changelist). Good. tested with release-2.0.15-stable
janv. 08 14:56:07.127 [Warning] TLS error while handshaking (with bufferevent) with [scrubbed]: wrong cipher returned (in SSL routines:SSL3_GET_SERVER_HELLO:SSLv3 read server hello B)
janv. 08 14:56:07.767 [Warning] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 33; recommendation warn)
janv. 08 14:56:07.768 [Warning] 33 connections have failed:
janv. 08 14:56:07.768 [Warning] 33 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B
janv. 08 14:56:08.135 [Warning] TLS error while handshaking (with bufferevent) with [scrubbed]: wrong cipher returned (in SSL routines:SSL3_GET_SERVER_HELLO:SSLv3 read server hello B)
janv. 08 14:56:08.607 [Warning] Problem bootstrapping. Stuck at 85%: Finishing handshake with first hop. (DONE; DONE; count 34; recommendation warn)
janv. 08 14:56:08.607 [Warning] 34 connections have failed:
janv. 08 14:56:08.608 [Warning] 34 connections died in state handshaking (TLS) with SSL state SSLv3 read server hello B
janv. 08 14:56:08.936 [Warning] tor_tls_finish_handshake(): Bug: For some reason, wasV2Handshake didn't get set. Fixing that.
janv. 08 14:56:08.937 [Error] connection_or_handle_event_cb(): Bug: connection_or.c:1281: connection_or_handle_event_cb: Assertion handshakes >= 2 failed; aborting
**Trac**:
**Username**: starsTor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4847Fix IPv6 bridges with a private/dynamic IPv4 address2020-06-13T15:15:42ZLinus Nordberglinus@torproject.orgFix IPv6 bridges with a private/dynamic IPv4 addressA bridge not listening to an IPv4 address looks OK (bootstraps 100%) but leaves the client hanging at 50%.
Workaround: Specify an ORPort on an IPv4 address in addition to the IPv6 address.
An idea is that it's related to the self testi...A bridge not listening to an IPv4 address looks OK (bootstraps 100%) but leaves the client hanging at 50%.
Workaround: Specify an ORPort on an IPv4 address in addition to the IPv6 address.
An idea is that it's related to the self testing that the bridge is
supposed to perform. (Setting AssumeReachable 1 hasn't changed
anything in my tests though.)Tor: unspecifiedLinus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/4838A directory cache will never purge some old descriptors2020-06-13T14:16:33ZTracA directory cache will never purge some old descriptorsBy default, caches don't try to download v2 statuses so have_enough_v2 in routerlist_remove_old_routers() is always false. This is similar to #3543.
I've come up with this modification to check whether we do v2 at all:
```
+ const or_o...By default, caches don't try to download v2 statuses so have_enough_v2 in routerlist_remove_old_routers() is always false. This is similar to #3543.
I've come up with this modification to check whether we do v2 at all:
```
+ const or_options_t *options = get_options();
have_enough_v2 = !caches ||
+ !(authdir_mode_any_main(options) || options->FetchV2Networkstatus) ||
(networkstatus_v2_list &&
smartlist_len(networkstatus_v2_list) > get_n_v2_authorities() / 2);
```
**Trac**:
**Username**: fermenthorTor: 0.2.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4796circuitlist.c:1222: _circuit_mark_for_close: Assertion ocirc->rend_data faile...2020-06-13T14:16:23ZRobert Ransomcircuitlist.c:1222: _circuit_mark_for_close: Assertion ocirc->rend_data failed; abortingmurb reports the following error message in 0.2.3.10-alpha:
```
Dec 28 15:59:37.000 [err] _circuit_mark_for_close(): Bug: circuitlist.c:1222: _circuit_mark_for_close: Assertion ocirc->rend_data failed; aborting
```
There were no relevan...murb reports the following error message in 0.2.3.10-alpha:
```
Dec 28 15:59:37.000 [err] _circuit_mark_for_close(): Bug: circuitlist.c:1222: _circuit_mark_for_close: Assertion ocirc->rend_data failed; aborting
```
There were no relevant notices or warnings before this message.
I see several code paths which can set a circuit's purpose to `CIRCUIT_PURPOSE_C_INTRODUCING`, then mark it for close before its `rend_data` field is set; there's no way we can get rid of those paths. Time to remove this assertion.Tor: 0.2.3.x-finalRobert RansomRobert Ransomhttps://gitlab.torproject.org/legacy/trac/-/issues/4792Network throughput on tor relay stalls2020-06-13T14:16:23ZTracNetwork throughput on tor relay stallsIm am running the torland relay family. On one of my servers I experience sudden network outages. The relays normally pump at a rate of 450-550 MBit/s. When the outage happens, within minutes the rate goes down below about 5Mit/s. In thi...Im am running the torland relay family. On one of my servers I experience sudden network outages. The relays normally pump at a rate of 450-550 MBit/s. When the outage happens, within minutes the rate goes down below about 5Mit/s. In this case it is difficult to connect to the server via ssh or to access the webserver with the traffic stats.
I checked the logs but found nothing in there. During the outage the CPU runs at a pretty low level, so CPU is not the root cause of this issue. Doing a traceroute to the server showed that the server indeed was the point where packet loss happened. I also contacted the ISP and asked them to check their network but they found nothing.
For me it looks as if the network stack on the machine runs at some point on some kind of lock which slows done throughout. Because the processes doing real work are tor processes (all are consuming nearly 100% CPU) I suppose tor is causing the outage. Are there any log options for tor I can use to investigate the cause of this issue?
Fingerprints of the relays are:
D223399907113A1F216AAA64997BC1D4CFA8E1AC
945CBBA599808018749DDC4EBB592168F2858C1B
09C0C5800177BF3A11A78A98A1CAFD8E7AD2EA02
Just to visualize I attach a screen shot of network usage when the issue happens: http://goo.gl/vSe32
Any hint is appreciated.
**Trac**:
**Username**: torlandTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/4760"ORPort [::]:9001" sometimes listens to both IPv4 and IPv6, sometimes to IPv4...2020-06-13T14:35:13ZDavid Fifielddcf@torproject.org"ORPort [::]:9001" sometimes listens to both IPv4 and IPv6, sometimes to IPv4 only.On some operating systems, an AF_INET6 socket listening on :: can also receive IPv4 connections, but whether it does by default is OS-dependent. It depends whether the IPV6_V6ONLY socket option is set.
You may want to set this socket op...On some operating systems, an AF_INET6 socket listening on :: can also receive IPv4 connections, but whether it does by default is OS-dependent. It depends whether the IPV6_V6ONLY socket option is set.
You may want to set this socket option on all sockets resulting from an IPv6 Bridge line, for uniformity and to avoid accidentally listening on IPv4 when you don't intend to. Linux by default has this option set; Windows and FreeBSD apparently do not.
An observable effect of this phenomenon is that this configuration fails on Linux:
```
ORPort 9001
ORPort [::]:9001
```
The problem is that "ORPort 9001" binds to IPv4, and "ORPort [::]:9001" tries to bind to both IPv4 and IPv6.
```
Dec 22 05:58:48.104 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 22 05:58:48.104 [notice] Opening OR listener on 0.0.0.0:9001
Dec 22 05:58:48.104 [notice] Opening OR listener on :::9001
Dec 22 05:58:48.104 [warn] Could not bind to :::9001: Address already in use. Is Tor already running?
Dec 22 05:58:48.104 [notice] Closing partially-constructed listener Socks listener on 127.0.0.1:9050
Dec 22 05:58:48.104 [notice] Closing partially-constructed listener OR listener on 0.0.0.0:9001
Dec 22 05:58:48.104 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Dec 22 05:58:48.104 [err] Reading config failed--see warnings above.
```
http://tools.ietf.org/html/rfc3493#section-5.3 describes the IPV6_V6ONLY option.https://gitlab.torproject.org/legacy/trac/-/issues/4748--defaults-torrc is not documented in manpage2020-06-13T14:16:12Zweasel (Peter Palfrader)--defaults-torrc is not documented in manpageTor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4733test suite fails on the hurd2020-06-13T14:16:07Zweasel (Peter Palfrader)test suite fails on the hurd```
util/spawn_background_ok: OK
util/spawn_background_fail:
FAIL test_util.c:1417: assert(stdout_buf == expected_out): <ERR: Failed to spawn background process - code 9/40000002
> vs <ERR: Failed to spawn background process - code ...```
util/spawn_background_ok: OK
util/spawn_background_fail:
FAIL test_util.c:1417: assert(stdout_buf == expected_out): <ERR: Failed to spawn background process - code 9/40000002
> vs <ERR: Failed to spawn background process - code 9/2
>
[spawn_background_fail FAILED]
util/spawn_background_partial_read: OK
```
ERRNO is not 2 everywhere.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/4345Bug: closing wedged cpuworker.2020-06-13T14:14:11ZTracBug: closing wedged cpuworker.The relay DFRI0 running version 0.2.2.34 on FreeBSD 8.2-RELEASE-p4 amd64, OpenSSL OpenSSL 0.9.8q 2 Dec 2010 got this error:
```
Oct 29 00:10:32.013 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the...The relay DFRI0 running version 0.2.2.34 on FreeBSD 8.2-RELEASE-p4 amd64, OpenSSL OpenSSL 0.9.8q 2 Dec 2010 got this error:
```
Oct 29 00:10:32.013 [notice] cull_wedged_cpuworkers(): Bug: closing wedged cpuworker. Can somebody find the bug?
Oct 29 00:10:32.024 [err] cpuworker_main(): Bug: writing response buf failed. Exiting.
```
**Trac**:
**Username**: jnhttps://gitlab.torproject.org/legacy/trac/-/issues/3056surprising dns responses received from hosts that aren't our resolver2020-06-13T14:10:16ZTracsurprising dns responses received from hosts that aren't our resolverThis is my first ticket, so bear with me pls. On IRC "Sebastian" asked me to file a bug report
I'm using tor 2.2.25-alpha, vidalia 0.2.12
debian squeeze/wheezy, Linux kernel 2.6.38-2-686
I run a relay and allow all exit policies normal...This is my first ticket, so bear with me pls. On IRC "Sebastian" asked me to file a bug report
I'm using tor 2.2.25-alpha, vidalia 0.2.12
debian squeeze/wheezy, Linux kernel 2.6.38-2-686
I run a relay and allow all exit policies normally.
Run from residential cable modem, timewarner/brighthouse/roadrunner.
iptables and guarddog firewall with many recommended ports open.
this is my torrc:
# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it
ContactInfo xxx
ControlPort 9051
DirPort 9030
HashedControlPassword 16:C87CFFBB8A7A0E6C60762C632961A38C9528FF12E165B8D691F55BE104
Log notice stdout
Nickname freeeveryone4ever
ORPort 9001
RelayBandwidthBurst 393216
RelayBandwidthRate 196608
my error msgs:
"eventdns: Address mismatch on received DNS packet. Apparent source was 10.10.7.2xx:5300"
I also get this msg every 10-30 mins: "[Warning] eventdns: All nameservers have failed" they come backup within a min or 2
also get this, for what it's worth:
"DNS Hijacking Detected - Tor detected that your DNS provider is providing false responses for domains that do not exist. Some ISPs and other DNS providers, such as OpenDNS, are known to do this in order to display their own search or advertising pages."
Tor seems to keep working, I just thought you'd want to know about these messages.
Thanks, freeeveryone4ever (also my relay name)
ps. let me know if you need more info.
**Trac**:
**Username**: freeeveryone4everTor: 0.3.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1936"All nameservers have failed" eventdns message2020-06-13T14:06:33ZTrac"All nameservers have failed" eventdns messageThe symptom is messages appearing in the log after some uptime, usually several days:
Sep 11 10:42:30.665 [warn] eventdns: All nameservers have failed
Sep 11 10:42:39.684 [notice] eventdns: Nameserver 4.2.2.1 is back up
Sep 13 08:56:58....The symptom is messages appearing in the log after some uptime, usually several days:
Sep 11 10:42:30.665 [warn] eventdns: All nameservers have failed
Sep 11 10:42:39.684 [notice] eventdns: Nameserver 4.2.2.1 is back up
Sep 13 08:56:58.089 [warn] eventdns: All nameservers have failed
Sep 13 08:57:01.788 [notice] eventdns: Nameserver 4.2.2.1 is back up
Sep 13 08:57:03.089 [warn] eventdns: All nameservers have failed
Sep 13 08:57:12.396 [notice] eventdns: Nameserver 4.2.2.2 is back up
After that tor process usually terminates without warning.
There are numerous reports about this issue on the net, just if you try to google that log message.
**Trac**:
**Username**: varnavTor: unspecified