logs archiveIRC Archive / Oftc / #tor / 2010 / January / 20 / 1
houdini
looks like I can get to libevent 1.4.13-stable-1 pretty easily
arma
does the nameservers line show up consistently? or just that once
houdini
I don't know
I just upgraded to a reasonable version of tor
silly me, I assumed the package that Debian gave me would be up to date
(where did I get that idea?)
looks like I saw it in November as well
which is probably the last time the server was started
arma
which was your tor version?
houdini
0.2.0.35 ?
arma
(you know about deb.torproject.org right?)
houdini
yeah, that's what I'm using now
arma
at some point we might put some libevent2 debs there too
that might be smart
or it might increase the odds of dependency hell
houdini
well
tor is the only thing using libevent on this machine, at least
brb
         

chrisd
there's a flyspray entry for this libevent bug?
arma
yep. i'll track it down, standby
hmmmm. i may be wrong.
https://bugs.torproject.org/flyspray/index.php?do=details&id=917 looks related but is not it.
maybe it is time to make a flyspray entry.
or perhaps there was one, and somebody closed it due to "what the fu*k might as well close it"
houdini
back
there's http://www.mail-archive.com/or-talk@freehaven.net/msg10989.html
which isn't flyspray
arma: if you managed to make the libevent debs coexist happily with the 1.x ones that come with Debian, I don't think anyone would even notice
(except for those of us using Tor)
chrisd
houdini: so tor starts and instantly prints "all nameservers have failed" ?
houdini
f.s.v.o. "instant", yeah
Jan 19 14:40:50.561 [notice] Tor 0.2.1.21 opening log file.
(30 lines of status output)
Jan 19 14:43:49.606 [warn] eventdns: All nameservers have failed
arma
how far away from your server are your nameservers?
houdini
the "status output" in question is about, for instance, bootstrapping
arma: 127.0.0.1 :)
arma
and there's only one in /etc/resolv.conf ?
houdini
clanspum:~# cat /etc/resolv.conf
domain clanspum.net
search clanspum.net
nameserver 127.0.0.1
arma
i think this might be a timeout problem. we ask a question, your nameservers says "wait while i look that up", after a few ms we say "screw this" and mark it down. then 'all' of them are down.
houdini
it's possible, but I'd be surprised
unless tor is really impatient :)
arma
let us know if it happens with the newer libevent
or did it just happen
houdini
though, now that you mention that, the response time of my upstream DNS providers sucks (~100ms)
but that's not that slow
weasel
which nameserver do you use?
houdini
do you mean which package?
or, what IP?
weasel
which softwar.e
houdini
Bind
chrisd
looks like eventdns waits 5 seconds before timing out a request
houdini
hm
clanspum:~# ldd /usr/sbin/tor | grep event libevent-1.3e.so.1 => /usr/lib/libevent-1.3e.so.1 (0x00007f4ef3e48000)
(that's on two lines. pretend my copy/paste didn't fail)
that's after installing libevent-1.4.13-stable-1
nsa
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:30:52 [tor/maint-0.2.1]: weight guard choice by bandwidth; discard old guards
         

houdini
bummer
arma
chrisd: are there some requests that could legitimately take 5 seconds? what do we do once we've timed out on it?
houdini
the debian package relies on libevent1
which isn't updated past 1.3
chrisd
arma: im not a dns expert, but i don't see how a dns query would take more than 5 seconds..
coderman
wifi
houdini
that's some pretty poor wifi
coderman
some wifi is pretty poor indeed
jr_
depends on the range
houdini
oh, ignore what I said about the package. I suck at Debian
chrisd
looks like it tries the request three times before giving up, though
arma
chrisd: right. i guess the big question is, what does libevent do when it has timed out
houdini
ok. just updated to libevent-1.4.13, tor 0.2.1.21
same error
~90 seconds after service is started
weasel
(Action) notes that "tor 0.2.1.21" is not a debian version.
coderman
is there really a nameserver at 127.0.0.1 or are you relying on WINS or something unknowingly?
houdini
(Action) sighs
clanspum:~# aptitude show tor | grep Version
Version: 0.2.1.21-1
coderman: it's really a Bind server
weasel
(policy is better than show)
coderman
doh, teach me to read
houdini
clanspum:~# aptitude policy tor
Unknown command "policy"
weasel
apt-cache policy tor | grep Inst
chrisd
well after marking a nameserver as failed it looks like it tries to probe it. if the probe suceeds, then it's marked up again
houdini
Installed: 0.2.1.21-1
weasel
show so you got the package from testing/unstable. ok.
s/show//
chrisd
sends a probe to www.google.com ..
houdini
yep
because the stable one explicitly linked against libevent1, which is stuck at version 1.3
chrisd: for the record, "dig www.google.com @localhost" works
chrisd
how long does your dig take?
houdini
clanspum:~# time dig www.google.com @localhost +short > /dev/null
real 0m0.140s
user 0m0.010s
sys 0m0.000s
this is a "real server", as opposed to a home machine
if that matters
weasel
dig www.google.com @localhost | grep SERV
houdini
clanspum:~# dig www.google.com @localhost | grep SERV
;; SERVER: 127.0.0.1#53(127.0.0.1)
coderman
weird
houdini
I suspect the problem isn't response time of DNS
coderman
i'm tempted to ask for a uname -a and dpkg -l to try and reproduce
houdini
sure
coderman
pastbin it plz, not here :)
houdini
of course :)
murb
i occastionally see [warn] eventdns: All nameservers have failed
i'mrunning pdns-recusor on that machine
weasel
previously it was bind.
ah no, that was houdini .
houdini
coderman: you sure you want all of this?
coderman
sure
you've got quite a weird scenario here
weasel
I wonder if localhost is allowed to recurse (in addition to just query the cache)
houdini
weasel: hit me with a domain I probably haven't gone to before
I'll look it up
murb
bratislava.danu.be
houdini
clanspum:~# dig bratislava.danu.be @localhost +short
web.yuri.org.uk.
78.47.151.105
coderman: I /msg'd it to you. if I should post it in here instead, I can do that
coderman
got it
houdini
I understand that you need to be sure, but I think you can assume the DNS server isn't the problem. It works for a lot of users, doing a lot of things
it serves something like 50 domains, is a local recursor, etc etc
coderman
hopefully you'll resolve this issue, but if not, i'll try and reproduce in a vm later this evening
nsa
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:52:52 [tor/maint-0.2.1]: spread guard rotation out throughout the month
houdini
coderman: it's entirely possible that I'm still moving bits, ignoring that message
I'm not sure
nsa
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:54:41 [tor/master]: Merge branch 'maint-0.2.1'
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:30:52 [tor/master]: weight guard choice by bandwidth; discard old guards
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:52:52 [tor/master]: spread guard rotation out throughout the month
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:55:54 [tor/master]: note the two new fixes are in 0.2.2.7-alpha too
houdini
anyway, let me know if you need more debugging information
I know some C and whatnot, so I might be able to be useful there
nickm
an info-level log from Tor here might help, just in case evdns is saying anything else
houdini
ok. how do I get that?
"Log info /some/where" ?
(in the config, kick it afterwards, etc etc)
Sebastian
Log info file /some/where
in the config
houdini
ok. I'll do that now
Sebastian
then kill -HUP `pidof tor`
arma
more generally, https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#Logs
nsa
or: Roger Dingledine <arma@torproject.org>: 2010-01-19 22:59:33 [tor/master]: bump to 0.2.2.7-alpha
houdini
ok, generating that file now
Jan 19 17:02:29.927 [info] eventdns: Nameserver 127.0.0.1 has failed: Bad response 5 (refused)
I'd bet that's important? :)
that gets logged right before the "eventdns: All nameservers have failed"
Sebastian
that does look curious
so awesome to finally find someone
who sticks around.
arma
houdini
so, should I upload that info.log somewhere?
arma
"does it build for you?"
nickm
the refused thing means that either your bind is saying REFUSED, or eventdns erroneously _thinks_ your bind is saying refused
houdini
(Action) nods
I _think_ it's the latter. mostly because I don't see why it would be the former
nickm
It would be neat to see what kind of request it's refusing.
weasel
nickm: what does tor use as source ip address?
Sebastian
arma: Jan 20 00:06:07.627 [notice] Entry guard 'hasselbach' (4403B0DD5A96C27932D4C0DD290DC227595D6707) was selected without regard for guard bandwidth. (Version="0.2.1.22".) Replacing it.
weasel
nickm: 127.0.0.1, or its public ip address?
Sebastian
so yes.
houdini
I can su to debian-tor (the user it's running as) and do some lookups, they work
Sebastian
:)
weasel
(or whatever linux gives it?)
houdini
arma: builds here. not running it right now, but it builds :)
nickm
weasel: unless he has outboundbindaddress set, it uses whatever linux gives it
houdini
..
*@#$
OutboundBindAddress 74.208.184.107
nickm
Happy happy! Joy joy!
weasel
(Action) bows, exit stage left
nickm
looks like we found it.
houdini
think it's using that for queries to 127.0.0.1 ?
I guess it would
hm
nickm
the solution is probably either for you to have bind accept that address...
houdini
how do I even test that?
nickm
...or for tor to not change the addr source address for requests to 127.0.0.1
big fun
bbiab
weasel
The -b option sets the source IP address of the query to address. This
houdini
of course
nickm
baby is crying; irc is laggy
houdini
(Action) HUPs tor
[notice] eventdns: Nameserver 127.0.0.1 is back up
good call
I wonder why nothing else on this machine has that problem?
weasel
because you don't force other things to connect from 74.208.184.107
houdini
well
I bind postfix to a different IP
which also wasn't allowed to do lookups
but it works fine
hm. it probably just uses that IP for incoming mail, not everything
arma
huh. so the answer to the next person with this problem is "perhaps your config is screwed up, and your nameserver and/or tor can't hear queries / responses."
weasel
houdini: your bind ACL probably should include the 'localhost' word for allow-recurse
« prev 1 2 3 4 next »