Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:19:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/24779Investigate Windows 11(?) AF_UNIX support2020-06-13T15:19:44ZteorInvestigate Windows 11(?) AF_UNIX supportWindows has added AF_UNIX to their developer builds:
https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/
We should make sure this doesn't cause any security issues in Tor.
And maybe we should support it eve...Windows has added AF_UNIX to their developer builds:
https://blogs.msdn.microsoft.com/commandline/2017/12/19/af_unix-comes-to-windows/
We should make sure this doesn't cause any security issues in Tor.
And maybe we should support it eventually.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/14989While bootstrapping: (Sandbox) Caught a bad syscall attempt (syscall socket),...2020-06-13T14:43:30ZcypherpunksWhile bootstrapping: (Sandbox) Caught a bad syscall attempt (syscall socket), then exits.Sandbox 1
RunAsDaemon 1
DataDirectory ####
TransPort #### IsolateClientAddr IsolateClientProtocol
DNSPort #### IsolateClientAddr
SocksPort 0
ControlPort ####
AutomapHostsOnResolve 1
VirtualAddrNetwork 172.16.0.0/12
[notice] Tor v0.2.6.3...Sandbox 1
RunAsDaemon 1
DataDirectory ####
TransPort #### IsolateClientAddr IsolateClientProtocol
DNSPort #### IsolateClientAddr
SocksPort 0
ControlPort ####
AutomapHostsOnResolve 1
VirtualAddrNetwork 172.16.0.0/12
[notice] Tor v0.2.6.3-alpha (git-69ecf672321755c0) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.8.
[notice] Opening DNS listener on ####
[notice] Opening Transparent pf/netfilter listener on ####
[notice] Opening Control listener on ####
[warn] You are running Tor as root. You don't need to, and you probably shouldn't.
[notice] Bootstrapped 0%: Starting
[notice] We now have enough directory information to build circuits.
[notice] Bootstrapped 80%: Connecting to the Tor network # reaches 80% only using remnants from previously running 0.2.6.2
[debug] connection_connect(): Connecting to [scrubbed]:9001 # is directly followed by:
(Sandbox) Caught a bad syscall attempt (syscall socket)
/usr/bin/tor(+0x12f2ba)[0x7fdd4bedb2ba]
/lib64/libc.so.6(socket+0x7)[0x7fdd4a2c9d07]
/lib64/libc.so.6(socket+0x7)[0x7fdd4a2c9d07]
/usr/bin/tor(tor_open_socket_with_extensions+0x52)[0x7fdd4bec6472]
/usr/bin/tor(+0xc9ea8)[0x7fdd4be75ea8]
/usr/bin/tor(connection_connect+0x10a)[0x7fdd4be77a1a]
/usr/bin/tor(connection_or_connect+0x129)[0x7fdd4be89a69]
/usr/bin/tor(channel_tls_connect+0x88)[0x7fdd4be48898]
/usr/bin/tor(circuit_handle_first_hop+0x1b8)[0x7fdd4be51b28]
/usr/bin/tor(circuit_establish_circuit+0x384)[0x7fdd4be52194]
/usr/bin/tor(circuit_launch_by_extend_info+0xe1)[0x7fdd4be63231]
/usr/bin/tor(circuit_build_needed_circs+0x30f)[0x7fdd4be6376f]
/usr/bin/tor(+0x37d30)[0x7fdd4bde3d30]
/lib64/libevent-2.0.so.5(event_base_loop+0x774)[0x7fdd4b435a44]
/usr/bin/tor(do_main_loop+0x195)[0x7fdd4bde4965]
/usr/bin/tor(tor_main+0x16b5)[0x7fdd4bde7735]
/lib64/libc.so.6(_#_libc_start_main+0xf5)[0x7fdd4a1f5d65] # remove '#'
/usr/bin/tor(+0x3506d)[0x7fdd4bde106d
and exits. This does not occur whatsoever with identically configured 0.2.6.2. Hope this helps.Tor: 0.2.6.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/9716Don't hardcode listen() backlog2020-06-13T14:31:51ZTracDon't hardcode listen() backlogWhile investigating Ticket #9708, I also found a lot of kernel messages along the lines of:
- sonewconn: pcb 0xfffffe005b7af000: Listen queue overflow: 193 already in queue awaiting acceptance
This despite the fact that "kern.somaxcon...While investigating Ticket #9708, I also found a lot of kernel messages along the lines of:
- sonewconn: pcb 0xfffffe005b7af000: Listen queue overflow: 193 already in queue awaiting acceptance
This despite the fact that "kern.somaxconn", which controls the length of the listen queue, was set to 4096.
Reading through the code, I found two instances of "listen(s,SOMAXCONN)" in src/or/connection.c. I think using SOMAXCONN as backlog is wrong. I think the correct backlog parameter is -1 -- which tells the kernel to accept as many connections as it's configured to accept, rather than a hardcoded constant (which happens to be the default the kernel will accept -- if not configured diferently).
SOMAXCONN is defined to 128 in <sys/socket.h> and is the default for kern.somaxconn. I'm not sure why it's exposed to userland. Possibly hysterical raisins?
Setting the backlog to -1 will allow tor to accept more connections faster if kern.somaxconn > SOMAXCONN (ie > 128).
This is true for FreeBSD (viz solisten_proto() in sys/kern/uipc_socket.) I've not tested Linux, but looking at the code (SYSCALL_DEFINE2(listen, int, fd, int, backlog) in net/socket.c) it should behave the same if I'm reading that cast correctly. On Linux, the moral equivalent of kern.somaxconn is configured with /proc/sys/net/core/somaxconn. It's also set to 128 by default. If raised to something huge, and listen() given a backlog of -1, it will also accept more connections.
**Trac**:
**Username**: philipTor: 0.2.4.x-finalhttps://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/5045Vidalia cannot authenticate Tor, control socket not connected2012-02-15T18:05:01ZTracVidalia cannot authenticate Tor, control socket not connectedI use the latest Tor Bundle under XP (SP3). When starting Vidalia, I get the message: "Vidalia was unable to authenticate to Tor (control socket is not connected) Please check your port authentication settings." In the message log of Vid...I use the latest Tor Bundle under XP (SP3). When starting Vidalia, I get the message: "Vidalia was unable to authenticate to Tor (control socket is not connected) Please check your port authentication settings." In the message log of Vidalia, it says "Tor software is not running". I have checked the FAQ and googled this, but nothing worked, neither changing the control port nor installing SP3 again. I have an old version of Tor, this has the same error, but it was working before. The computer is running fine, no probs with the web or anything else, device manager looks fine, no errors. The files are where they have to be (tor.exe and torrc). When starting Tor directly through the tor.exe, it connects and says circuit could have been built, the task manager shows it is running. Is this a XP error? Help is very much appreciated.
**Trac**:
**Username**: frank21Tomas ToucedaTomas Touceda