BarkerJr: please break barkerjrparis again so we can debug?
BarkerJr: let me know when you're done
Apr 12 21:41:38.100 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
yay you broke it
BarkerJr: can you unbreak it?
(is this a lot of work for you?)
(I want you to unbreak it so I can get the debug log for comparison with the working relay. Too bad I didn't save it last time)
if it is a lot of work I'll try hard to recreate your setup and do the work
nah, it's not bad
yum downgrade httpd mod_ssl openssl openssl-devel; kill -TERM `pidof tor`
then it restarts a minute later
let me know when you're done
I have a minutely cron job that starts tor if it's not running
BarkerJr: What Tor package is that?
My current theory is that there's some binary compatibility issue, and that if you were to build Tor from source to link against openssl-1.0.0 it would work fine, but for some reason Tors build with older openssls don't work when linked with openssl-1.0.0
I could be wrong, but if I'm right, this will be easy to debug by "try and find out" methods, and hard to debug by looking at logs.
Because this is a very hard bug to figure out by tracing through the source (since it involves Tor thinking that it's using one version of the openssl data structures when it's really using another), I'd really like to rule it out if possible.
I tried that a few days ago (and noted that in the bug), but I could try again if you want to see what you get in debug logs
don't remember when I compiled it
what did you try?
I downloaded and compiled tor-0.2.1.25.tar.gz on friday with ./configure --enable-openbsd-malloc --disable-asciidoc
I can't imagine those configure options would cause it, though, cause the packages don't use them, right?
I think that might mean that you compiled against an earlier version of openssl
can you compile it against 1.0.0 and see what happens then?
the new version was released 1.5 weeks ago
so you're saying you did compile against the latest version?
ok. hm. now my head explodes.
0.9.8e-12.el5_4.1 is the one that works
do you know how to get a diff between them?
or: [tor/master] 2010-04-12 22:12:49 Nick Mathewson <firstname.lastname@example.org>: Log bandwidth_weight_rule_t as a string, not an integer.
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/openssl-0.9.8e-12.el5_4.6.src.rpm and ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Client/en/os/SRPMS/openssl-0.9.8e-12.el5_4.1.src.rpm
(Action) tries to rember flags to rpmbuild
I guess that takes care of nickm's abi incompatibility
or: [tor/maint-0.2.1] 2010-04-12 22:10:56 Peter Palfrader <email@example.com>: testsuite: Prevent the main thread from starving the worker threads
or: [tor/maint-0.2.1] 2010-04-12 20:49:58 Peter Palfrader <firstname.lastname@example.org>: testsuite: Only free the main mutex when and if all the worker threads are done
I also wonder if something was backported from openssl 1.0.0.
diffs of diffs are confusing.
nickm: haven't read everything, but I am using gentoo here
after the update to 0.9.8m, it stopped working for me
or: [tor/master] 2010-04-12 22:22:06 Nick Mathewson <email@example.com>: Merge commit 'origin/maint-0.2.1'
or: [tor/master] 2010-04-12 20:49:58 Peter Palfrader <firstname.lastname@example.org>: testsuite: Only free the main mutex when and if all the worker threads are done
or: [tor/master] 2010-04-12 22:10:56 Peter Palfrader <email@example.com>: testsuite: Prevent the main thread from starving the worker threads
data: and when you recompile against that new openssl version, you get breakage too?
Sebastian: so when people recompile against openssl 1.0.0, they fail, but when you try a private network using openssl 1.0.0, it works?
I haven't tried openssl 1.0.0 myself
but reading what data and murb write, it might not be openssl 1.0.0 only
oh; I thought you had.
see their version numbers
sure, but one thing at a time
I'm just now fetching 0.9.8n
trying that first, because that is what data uses
I wonder if they broke renegotiation again, harder.
i mistyped, btw. it's n that is not working
yeah, last time was a lot of fun with all my client certificates...
nickm: so they did implement rfc something
first version they implemented it was m
is there a document where the negotiation used in tor is being described?
hm. I wonder if there's an option we need to twiddle to tell it, "it's okay if the other side doesn't do stuff the rfc5746 way!"
or if that's just the same option as before.
Hm.. SSL_OP_LEGACY_SERVER_CONNECT . I wonder if we need to mess with this.
maybe http://kbase.redhat.com/faq/docs/DOC-20491 helps?
section "Updates adding RFC 5746 support"
i guess we might need to use the source
(Action) needs to take a break before trying to read openssl source again
Sebastian: I just rebuild and restarted
Your Tor server's identity key fingerprint is 'CompSciR0x 6598FCA0B3ADF12DD6B11838812BDCC81C293852'
ooh, from the openssl 0.9.8m changelog: 'If client attempts to renegotiate and doesn't support RI respond with a no_renegotiation alert as required by RFC5746. Some renegotiating TLS clients will continue a connection gracefully when they receive the alert. Unfortunately OpenSSL mishandled this alert and would hang waiting for a server hello which it will never receive. Now we treat a received no_renegotiation alert as a fatal error. This is because applications requ
oops, bigger than I thought.
data: got an ip and port for me?
that looks kind of relevant :)
Now checking whether ORPort 188.8.131.52:443 and DirPort 184.108.40.206:80
btw. I jumped from l to n
so it might be changes in m or n
data: works for me now.
i did a link check with revdep-rebuild, but it found nothing
data: otoh, I did update my openssl to 0.9.8n now
BarkerJr: is your relay currently broken?
Sebastian: how are you testing?
trying to use your relay as a bridge
ah no, that's not it. I'm still using 0.0.8l
didn't you tell me to file duplicate tickets today? :)
I meant "please file one bug with both issues" :)
I didn't word it so well.
why would you want one bug for two issues?
then you are forced to fix both at in the same version
anyway, should be broken now: Apr 12 23:03:47.170 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
it's still broken for me. good.
Sebastian: it really seems like I fixed it by recompiling
This is just getting way over my head. ugh.
BarkerJr: did you try compiling it by hand?
he did that from the start :/
now that I try to use openssl 0.9.8n, Tor doesn't compile for me
In file included from torgzip.c:19:
/opt/local//include/zlib.h:1568:32: error: "_FILE_OFFSET_BITS" is not defined
I'm not sure why Tor would use zlib from macports. I only told it to use openssl
or: [debian-tor/debian-0.2.1] 2010-04-12 22:25:27 Peter Palfrader <firstname.lastname@example.org>: Minor bugfixes to make the testsuite work on our new Octeon machines
yeah, tor is definitely working again. already at 2k connections
and when Tor started it told you you were using the newest version?
erm, the new openssl version
where would it say such a thing?
Apr 13 00:57:22.501 [notice] OpenSSL OpenSSL 0.9.8l 5 Nov 2009 looks like version 0.9.8l; I will try SSL3_FLAGS to enable renegotation.
this is in the log, right?
nah, this is too early to be in the logfile
it should be in your stdout
I get it in the log
Apr 12 23:03:44.536 [notice] Parsing GEOIP file.
Apr 12 23:03:44.674 [notice] OpenSSL OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 [90802f] looks like it's older than 0.9.8l, but some vendors have backported 0.9.8l's renegotiation code to earlier versions. I'll set SSL3_FLAGS just to be safe.
hm. Then I lied. Bad Sebastian.
my zlib issue seems to be an upstream problem with gcc warnings.
hah, now I get a libevent error
wow. This past month almost convinced me that whenever I touch any bugs in Tor, I screw up in a weird way.
can I refix my relay now?
BarkerJr: if you don't mind, keep it broken until tomorrow evening?
think this impacts bridges, too?
do you think it's working for some people?
cause my server is still burning 5mbit each way
that might mean that authorities don't like it, but others who still have my relay cached can use it fine
possibly others who have upgraded openssl?
hm, problems with OpenSSL 1.0.0? my bridge works fine with it, as far as I can tell
running 9 days now, on FreeBSD
was running with OpenSSL 0.9.8n before, also no problems
arma: seen my answer for resisting censorship?
i am thinkin about writing implementation detail also
weasel: do you provide a .deb that is compiled with --enable-openbsd-malloc?
Has anyone had any success in torifying the Evolution mail client?
or: pootle committed revision 22173 (/projects/gettor/i18n): updated files from pootle
or: pootle committed revision 22174 (/translation/trunk/projects/torbutton): updated files from pootle
or: pootle committed revision 22175 (/translation/trunk/projects/torcheck/ja): updated files from pootle
or: pootle committed revision 22176 (/translation/trunk/projects/website): updated files from pootle
or: runa committed revision 22177 (/website/trunk): updated translations for the website
micah: no, not anymore.
or: runa committed revision 22178 (/translation/trunk/projects/website): updated po files for pootle
It looks like two versions of Tor Weather is running now. I got two mails about a relay.
I like that one of them include the header List-Unsubscribe and sent the message in the body. The other mail sent the message as an attachment and does not have the header.
But it did use TLS to send the mail which the first mailserver did not do, null.lostinthenoise.net.
or: runa committed revision 22179 (/website/trunk/en): added p-tag
or: runa committed revision 22180 (/website/trunk/fr): updated translation for the website
or: runa committed revision 22181 (/website/trunk/torbrowser/en): i is not li
or: runa committed revision 22182 (/translation/trunk/projects/website): updated files for pootle
BarkerJr: big thanks for letting your relay remain in broken state for now. I have a good idea what's going on, I think.
Please keep it like that for now as we run more tests
hey, now that i am back up running, i also have my old problem back: [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy.
But I have MaxAdvertisedBandwidth down to 1000KBytes already
this is with a email@example.comGhz and 2 Gigs of ram
can you limit it even more?
Just to see what happens. 1000KBytes is still a lot
data: have you tried ti use "NumCpus 2" ?
SwissTorExit: no, did not know that, will try. Thanks
you are welcome, maybe can help
If that helped, that'd be quite good to learn. unfortunately, Tor doesn't do multithreading well yet. But maybe you'll still have some luck.
yeah, i will try this first
i mean, i am not even an exit
Sebastian: how can you see if it run well or not with multi core ?
i.e i was always running with 4 cores and always look working well after 1 year
SwissTorExit: No, I think you misunderstood what I was trying to say
i see that it use almost no ressource on 4 cores , that's all