Opened 11 years ago
Last modified 7 years ago
#907 closed defect (Fixed)
HardwareAccel isn't used
Reported by: | udo | Owned by: | |
---|---|---|---|
Priority: | Low | Milestone: | |
Component: | Core Tor/Tor | Version: | 0.2.0.32 |
Severity: | Keywords: | ||
Cc: | udo, arma, nickm | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
Log shows me:
[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
but crypto.c says:
if (useAccel < 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");
}
if (useAccel > 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
if (!ENGINE_register_all_complete())
return -1;
So no HardwareAccel even though torrc says:
HardwareAccel 1
This is Fedora 10 on VIA EK8000. Tor 0.2.0.32, built with source and spec from tor.eff site.
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
Child Tickets
Change History (17)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
I can't for the life of me figure out what is calling tor_tls_init before crypto_global_init() gets called. I've
tried to reproduce this on 0.2.0.32-dev, 0.2.0.32, and trunk, and had no luck. crypto_global_init() was called from
tor_init each time.
Can you use gdb to set a breakpoint inside crypto_global_init(), run Tor, and check the stack trace to see the first
place where crypto_global_init() is called for you?
Posting your torrc might be useful too.
comment:3 Changed 11 years ago by
torrc:
SocksPort 9050 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
DataDirectory /var/lib/tor
ControlPort 9051
HashedControlPassword blabla
Nickname blabla
Address blabla
ContactInfo Random Person blabla
ORPort 9001
ExitPolicy reject *:* # middleman only -- no exits allowed
BandwidthRate 20 KB
BandwidthBurst 21000
HardwareAccel 1
AccountingStart day 12:21
AccountingMax 2 GB
User _tor
Is there a quick gdb howto for the asked breakpoint test or is it very easy to figure out?
comment:4 Changed 11 years ago by
Start gdb with "gdb path/to/tor"
Then say "break crypto.c:180", where instead of 180, you say the line where you want to put a breakpoint.
Then say "run". If you start Tor with command-line arguments, give them after this "run".
GDB will stop when it hits the breakpoint. When this happens, say "bt" to get a stack trace.
comment:5 Changed 11 years ago by
(gdb) run -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
Starting program: /usr/bin/tor -f /etc/tor/torrc --pidfile /var/run/tor/tor.pid
[Thread debugging using libthread_db enabled]
Jan 21 16:10:07.640 [notice] Tor v0.2.0.32 (r17346). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Jan 21 16:10:07.648 [notice] Initialized libevent version 1.4.5-stable using method epoll. Good.
Jan 21 16:10:07.652 [notice] Opening OR listener on 0.0.0.0:9001
Jan 21 16:10:07.656 [notice] Opening Socks listener on 127.0.0.1:9050
Jan 21 16:10:07.659 [notice] Opening Control listener on 127.0.0.1:9051
[New Thread 0xb7ff1a40 (LWP 585)]
Breakpoint 1, crypto_global_init (useAccel=-1) at crypto.c:180
180 _crypto_global_initialized = 1;
(gdb) bt
#0 crypto_global_init (useAccel=-1) at crypto.c:180
#1 0x080d95bc in tor_tls_init () at tortls.c:304
#2 0x080d9972 in tor_tls_context_new (identity=0x811e618, key_lifetime=7200) at tortls.c:530
#3 0x080b104f in init_keys () at router.c:515
#4 0x08094f6b in accounting_set_wakeup_time () at hibernate.c:462
#5 configure_accounting (now=1232550607) at hibernate.c:361
#6 0x080641ea in options_act () at config.c:1227
#7 set_options (new_val=0x8115530, msg=0xbffff6a4) at config.c:753
#8 0x08064e10 in options_init_from_torrc (argc=5, argv=0xbffff8d4) at config.c:3704
#9 0x0809632d in tor_init (argc=5, argv=0xbffff8d4) at main.c:1802
#10 0x080994e7 in tor_main (argc=5, argv=0xbffff8d4) at main.c:1985
#11 0x080c6fe7 in main (argc=1, argv=0x8000) at tor_main.c:29
comment:7 Changed 11 years ago by
Where can I see that patch/diff so I can test the change?
Thanks in advance for the info.
(full tree of 2.0.32 with patch is also OK)
comment:8 Changed 11 years ago by
You could check out the latest revision from subversion:
http://www.torproject.org/documentation#Developers
This patch hasn't been backported to the stable branch yet, since we're trying to do a stable release today, and this
needs more testing.
comment:9 Changed 11 years ago by
I suspect what you're looking for is here:
http://archives.seul.org/or/cvs/Jan-2009/threads.html
specifically,
http://archives.seul.org/or/cvs/Jan-2009/msg00373.html
comment:10 Changed 11 years ago by
Thanks!
Unfortunately the patch doesn't work right away; after some fiddling I run into issues with crypto_seed_rng that was changed after 2.0.32 was released (I guess).
I think I'll have to wait for tor 2.0.33. (with hopefully this fix)
comment:11 Changed 11 years ago by
No, the fix for this one will have to go into 0.2.0.34; 0.2.0.33 is coming out today, and there isn't time to test
this fix enough.
comment:13 Changed 11 years ago by
Correct. I don't think we're going to backport it to 0.2.0 after all, since
we're trying to reduce the number of changes we make to the 'stable' release.
0.2.1.12-alpha has your fix though.
comment:14 Changed 11 years ago by
How stable is 0.2.1.12 if that isn't a stable
release?
In other words, with respect for the decision, what will I get?
comment:15 Changed 11 years ago by
Alpha releases come with all the guarantees that the stable series does, which is to say: "no guarantees at all". ;) We
try hard to make sure they all work, but the fact that alphas often have new features or complex fixes (like this one)
means that they are likelier to have new bugs than releases in the stable series.
That said, I run the alphas, and they works for me, usually. If they don't work for you, it should be easy to move
back to 0.2.0.x until the next version of 0.2.1.x comes out.
comment:17 Changed 7 years ago by
Component: | Tor Client → Tor |
---|
# openssl engine
(padlock) VIA PadLock (no-RNG, ACE)
(dynamic) Dynamic engine loading support
Patched openssl, of course.