Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:57:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/369Bad GETINFO "accounting/bytes-left" data2020-06-13T13:57:17ZTracBad GETINFO "accounting/bytes-left" data# uname -a
OpenBSD fgsfds.local 4.0 GENERIC#0 i386
# tor -h
Dec 14 18:20:18.888 [notice] Tor v0.1.1.25. This is experimental software. Do not rely on it for strong anonymity.
Copyright 2001-2005 Roger Dingledine, Nick Mathewson.
torrc ...# uname -a
OpenBSD fgsfds.local 4.0 GENERIC#0 i386
# tor -h
Dec 14 18:20:18.888 [notice] Tor v0.1.1.25. This is experimental software. Do not rely on it for strong anonymity.
Copyright 2001-2005 Roger Dingledine, Nick Mathewson.
torrc excerpt:
SocksPort 9050
SocksListenAddress 0.0.0.0
SocksPolicy accept 192.168.15.0/24
SocksPolicy reject *
Log notice syslog
Log info file /etc/tor/private/debug.log
RunAsDaemon 1
DataDirectory /etc/tor/private
ControlPort 9051
ORPort 9001
PublishServerDescriptor 1
AccountingMax 300MB
AccountingStart day 00:00
ExitPolicy reject *:*
User _tor
Group _tor
BandwidthRate 50KB
PidFile /etc/tor/tor.pid
SafeLogging 1
# grep hibernate debug.log
...
debug.log:Dec 14 00:00:00.683 [notice] hibernate_end(): Hibernation period ended. Resuming normal activity.
debug.log:Dec 14 12:25:54.369 [notice] consider_hibernation(): Bandwidth soft limit reached; commencing hibernation.
debug.log:Dec 14 12:25:54.371 [info] hibernate_begin(): Closing listener type 3
debug.log:Dec 14 12:25:54.372 [info] hibernate_begin(): Closing listener type 6
debug.log:Dec 14 12:36:32.850 [notice] hibernate_go_dormant(): Going dormant. Blowing away remaining connections.
debug.log:Dec 14 12:36:32.852 [info] hibernate_go_dormant(): Closing conn type 4
...
# telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
authenticate
250 OK
getinfo accounting/hibernating
250-accounting/hibernating=hard
250 OK
getinfo accounting/bytes
250-accounting/bytes=316021088 308635003
250 OK
getinfo accounting/bytes-left
250-accounting/bytes-left=18446744073708103328 5937797 <--- wrong
250 OK
quit
250 closing connection
Connection closed by foreign host.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: guesthttps://gitlab.torproject.org/legacy/trac/-/issues/364DNS lookup problems2020-06-13T13:57:14ZTracDNS lookup problemsI am still, even with 1.1.25, getting DNS resolutions like:
stbmac:/Library/Tor Michael$ tor-resolve en.wikipedia.org
127.0.0.1
There doesn't seem to be any way to find out which host is supplying these
bad references (so that they ca...I am still, even with 1.1.25, getting DNS resolutions like:
stbmac:/Library/Tor Michael$ tor-resolve en.wikipedia.org
127.0.0.1
There doesn't seem to be any way to find out which host is supplying these
bad references (so that they can be added to ExcludeHosts), nor does there
seem to be any sort of double checking on DNS data returned.
Normal DNS relies on being able to trust the roots, and then eventually being
able to trust the systems that they claim are reliable, to track down
authoritative answers. Tor's resolution seems to ignore that -- anyone's
answer is accepted.
To make matters worse, even after turning off tor, Firefox (1.8) still
caches the output page from Privoxy that claims that the address cannot
be resolved, and trying to reload returns the same page. (I know, that
one's not your department.)
Current configuration:
All requests go through privoxy.
Privoxy's config has lines:
# Tor:
##
## forward-socks4a / localhost:9050 .
forward-socks4a .onion localhost:9050 .
# Do not torrify these (high volume/speed concerns):
forward .vidalia-project.net .
forward 127.0.0.1 .
That first line (with the "## ") is toggled to turn tor on/off. When turned on,
I still get complaints about 127.0.0.1 and the "reloading server list /
determining server location" function of vidalia still takes forever and
occasionally logs in the console.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: keybounce0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/363Refuse to start if /etc/resolv.conf cannot be read/parsed2020-06-13T13:57:13ZTracRefuse to start if /etc/resolv.conf cannot be read/parsedTor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task #362), I t...Tor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task #362), I think tor should refuse to start (or at least log a
warning/error to stderr) if this is the case. Of course, this does not solve all DNS issues, as
invalid DNS servers could still easily exist in /etc/resolv.conf, but it will at least act as a
basic "dummy proofing" for those chrooting/jailing their tor exit nodes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Orum0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/362Tor crashes after numerous failed name resolutions.2020-06-13T13:57:13ZTracTor crashes after numerous failed name resolutions.If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having ...If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having the exact output, as I have fixed the issue and no longer have the
core (and would like to not break it again).
However, should you be confirming this, the easiest way to replicate this is by setting up a
tor exit node with a relatively unrestricted exit policy (the default should do). Make sure
that tor does *not* query a valid nameserver by modifying your /etc/resolv.conf (easiest way
to do this without breaking DNS on the host machine is to run tor in a chroot(8) or jail(8)
environment) to point to an invalid nameserver. After a few hours (maybe less on high band-
width nodes) tor will crash, dropping it's core.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Orum