works ok here. i installed tor-0.4.7.13 on my 7.2 home gateway, no special setup. i have not done any fiddling with login.conf.
maybe you can set "Log debug syslog" and see what comes out? fugu$ uname -a OpenBSD fugu.offblast.org 7.2 GENERIC.MP#6 amd64 fugu$ grep '^[A-Z]' /etc/tor/torrc Log notice syslog RunAsDaemon 1 DataDirectory /var/tor User _tor fugu$ curl --silent --socks5-hostname localhost:9050 https://check.torproject.org | grep Congratulations Congratulations. This browser is configured to use Tor. Congratulations. This browser is configured to use Tor. fugu$ grep -i tor /var/log/daemon Mar 14 00:05:12 fugu Tor[84209]: Tor 0.4.7.13 running on OpenBSD with Libevent 2.1.12-stable, OpenSSL LibreSSL 3.6.0, Zlib 1.2.12, Liblzma N/A, Libzstd N/A and Unknown N/A as libc. Mar 14 00:05:12 fugu Tor[84209]: Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/ Mar 14 00:05:12 fugu Tor[84209]: Read configuration file "/etc/tor/torrc". Mar 14 00:05:12 fugu Tor[84209]: Opening Socks listener on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Opened Socks listener connection (ready) on 127.0.0.1:9050 Mar 14 00:05:12 fugu Tor[84209]: Parsing GEOIP IPv4 file /usr/local/share/tor/geoip. Mar 14 00:05:13 fugu Tor[84209]: Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6. Mar 14 00:05:13 fugu Tor[84209]: We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. Mar 14 00:05:13 fugu Tor[84209]: Bootstrapped 0% (starting): Starting Mar 14 00:05:13 fugu Tor[84209]: Starting with guard context "default" Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 5% (conn): Connecting to a relay Mar 14 00:05:14 fugu Tor[84209]: Bootstrapped 10% (conn_done): Connected to a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 14% (handshake): Handshaking with a relay Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 15% (handshake_done): Handshake with a relay done Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 25% (requesting_status): Asking for networkstatus consensus Mar 14 00:05:15 fugu Tor[84209]: Bootstrapped 30% (loading_status): Loading networkstatus consensus Mar 14 00:05:19 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We have no usable consensus. Mar 14 00:05:19 fugu Tor[84209]: Bootstrapped 40% (loading_keys): Loading authority key certs Mar 14 00:05:20 fugu Tor[84209]: The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services. Mar 14 00:05:20 fugu Tor[84209]: Bootstrapped 45% (requesting_descriptors): Asking for relay descriptors Mar 14 00:05:20 fugu Tor[84209]: I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/6489, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) Mar 14 00:05:21 fugu Tor[84209]: Bootstrapped 50% (loading_descriptors): Loading relay descriptors Mar 14 00:05:26 fugu Tor[84209]: The current consensus contains exit nodes. Tor can build exit and internal paths. Mar 14 00:05:34 fugu Tor[84209]: Bootstrapped 56% (loading_descriptors): Loading relay descriptors Mar 14 00:05:36 fugu Tor[84209]: Bootstrapped 63% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 68% (loading_descriptors): Loading relay descriptors Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits Mar 14 00:05:38 fugu Tor[84209]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit Mar 14 00:05:39 fugu Tor[84209]: Bootstrapped 100% (done): Done On Mon, Mar 13, 2023 at 4:35 AM Matt Wehowsky <wehow...@airmail.cc> wrote: > > On 2023-03-12 09:53 AM, Stuart Henderson wrote: > > I don't think the problem you're seeing is related to login.conf but a > > few comments on that, > > > > ... > > > > I suggest removing login.conf.db (it is not created by default) and not > > using cap_mkdb, to avoid any problems with the db file getting out of > > sync after other changes. You probably want to override openfiles-cur as > > well, not just -max. > > Done. Thanks for the insight, Stuart. > > > Note any daemon-specific config here will only be used automatically if > > you're running it via rcctl or the rc.d script. (If you run it "by hand" > > you can set the login class with su -c or sudo -c). > > I’m aware of that, but thank you for clarification nonetheless. > > > It doesn't help your problem with obfs4proxy but snowflake_proxy is for > > providing access to others; you want snowflake_client (it's in -current > > but was not built in the package until after 7.2-release). > > Thank you for the heads up! That was quite a revelation to me that this > particular package gets shipped with three binaries for different > purposes—should’ve taken advantage of pkg_info’s -L option, my bad. > > I’ve just upgraded to 7.3-beta and updated the snowflake_proxy package > to version 2.5.1; here’s the updated contents of my torrc file: > > $ grep '^[A-Z]' /etc/tor/torrc > Log notice syslog > RunAsDaemon 1 > DataDirectory /var/tor > User _tor > UseBridges 1 > ClientTransportPlugin snowflake exec /usr/local/bin/snowflake_client > Bridge snowflake 192.0.2.3:1 > url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ > front=cdn.sstatic.net > ice=stun:stun.l.google.com:19302,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 > > Tor keeps spewing logs of the same kind, however. Nothing has changed. I > have no idea as to what else can be done to make Tor start building > circuits. > > I would’ve posted on Tor mailing lists if I had experienced the same > issues on my GNU/Linux machine as well as on my Android device, but > things appear to be working there just fine. Can you or anybody else > reading this message give me some insight into ways of finding the root > of the problem? I’m at a loss here. Many thanks in advance.
