Dear tor-talk and tor-relays experts:
Hi,
The solution to my problems is probably obvious: "well, downgrade" (or
perhaps, if skilled or daring, try compiling the latest code), however:
I'd like to report that the current obfsproxy bridge bundle for Windows
seems to be essentially unusable on my system. Windows 7 Ultimate x64,
first gen i3/2 core/4 thread mobile system.
I think this is the first Windows obfsproxy bridge bundle released.
Previously I used the 0.2.4.11 pyobfsproxy browser bundle and simply
reconfigured it as a bridge, which seemed to work fine and be very stable.
My initial difficulties were all my own: configuration file changes between
the two versions and filename changes (pyobfsproxy -> obfsproxy). Solved
them, to my knowledge.
1) Then, Tor always crashed on startup, which may have been a timing issue
as this was mostly/only observed with Vidalia configured to startup with the
system/login. This "fixed itself" (more evidence it may have been a timing
issue with differing startup/login timing). However, I think this is a bug,
as startup with the system should just work (I had no problems with
0.2.4.11).
2) Then, although Tor didn't crash on startup anymore, there were numerous
error messages (unfortunately, I don't recall them) in the Tor log when
starting with the system, and I think it was not fully working anyway.
3) Maybe a showstopper: in between 20 minutes and and an hour, Vidalia
either lost communication with Tor, or Tor was failing in some way. Vidalia
did not know it had lost communication, but there were no more log messages,
and all the other information tabs either reported nothing, or in the case
of the network map -- mapped nothing but showed some connections. Nothing
happened if I tried to terminate connections from the interface. Clicking
the "Stop Tor" button and then "Start Tor" resolved the issue -- for 20-60
minutes. My solution: stop using Vidalia, and just run Tor directly. I
made a hardlink to the torrc file in Vidalia's appdata folder, from Tor's so
they could both find it (there is probably a command-line switch or two I
could have used :) -- I didn't check!)
4) Now, things were better. Next problem: periodically, usually after some
hours of running fine, the Tor log began showing errors re. the
cached-microdescs file. First, a permission/file access error, and then
hundreds of other errors related to building the micro descriptor cache
would be generated every some minutes. Actually---I also observed this
problem the first time, even running under Vidalia, that Tor ran without
crashing on startup. My solution attempt: delete the file. It was locked.
When I closed Tor --- the lock was released [Tor was tied to the file lock]
and I could delete the file. I restarted Tor and it worked fine for some
hours before repeating this behavior. Once this happens, my node goes down.
I think it has to do more bootstrapping work on restart when this file is
lost, if I understand correctly.
5) Sometimes, problem #4 never occurs: Tor simply stops generating log
messages and I dissappear from the consensus (onionoo status=down). This
also takes some hours. This is the state at this moment as I write this
message, and looking at the log, there is nothing unusual reported
(level=notice/warning) (if beneficial, I can learn how to have Tor generate
a full debug log when run directly without Vidalia). Tor is still
functioning as a client -- without log messages to the terminal, at least
for a longstanding existing connection.
6-sort of) I'll note in passing---in the off-chance it might be an issue on
the Tor end, and in the other off-chance that an issue on "my end" is adding
to Tor's instability. I suppose in both cases it might be called a Tor bug
if in deed relevant at all, as I would expect Tor to handle it gracefully:
I have my OR address specified using a DNS name (a dynamic DNS name). I run
a dynamic DNS updater that either polls for changes every 5 minutes, or else
Tor does a lookup every 5 minutes, because Tor is reporting IP address
changes sometimes as frequently as every 5 minutes, between my real IP
(which has not changed) and an IP on an entirely different network owned by
an unaffiliated ISP!. This gererates frequent ORPort reachablity tests,
which are always done, for some reason, on the correct IP address. The
incorrect address has a long tracert to another state before it dwindles off
to no-reporting private network routers, and a reverse nslookup indicates it
is on a cellular address block. --- I will have to study this issue on my
own, most likely (bug in updater, my dynamic dns service, etc. - it may be
the last known address on one of the configured interfaces on my coputer -
which is down -- for when I use my phone's connection on occasion.) I can
simply try returning to my old batch file that worked great as a dynamic ip
updater, and can the fancy but possibly buggy executable in the system tray.
7) Minor issue: ORPort reachability tests do not always succeed in the 20
minutes alotted (but I can perform a telnet test from a foreign server to
the port and get a connection). The tests are repeated and eventually
succeed. On the other hand, sometimes the test succeeds within seconds. I
have trouble understanding why they would fail (or why they would take more
than 30 seconds) unless it is an issue where other nodes refuse to
cooperate in reachability testing or make it a low priority. This is
probably not a version-specific issue, but might be a design issue.
8) This issue comes chronologically early in the sequence of problems I
experienced: Some controls in the Vidalia 0.2.4.12-0.3.3 Settings dialog
that I tried didn't save the values, So I relied on manually editing the
config files.
--------------
If you've read this far, thanks!
I will soon--time permitting--and lacking other advice--try the
non-obfsproxy bridge bundle (0.2.4.12-alpha-0.2.21) supplemented with the
obfsproxy executable from alpha 0.3.3.
If that fails, I will go back to the 0.2.4.11 browser bundle configured as a
bridge.
When I achieve a stable combination, I might try a tool for installing
anything as a service and try to run the Tor executable as a service. Seems
like Vidalia should be able to talk to it, but I might have to overcome
automatic Vidalia behavior like trying to start Tor itself and exiting if
the Tor process is killed, etc.
----------------
There are many great minds here, so if anyone has any pointers or links o a
page with the info I need, that would be great.
Otherwise, consider this a bug report and let me kow if I can aid in
debugging. I want to support the Tor network in such ways as I can.
Thanks,
Asa
