herbalist

Tor-Vidalia with KeX on Win 9x/ME

36 posts in this topic

The present stable Tor/Vidalia bundle works with KEX as a client. I'm not sure how well it will work long term as a relay or bridge. At the very least, it will require raising the default MaxConnections settings. It is a fairly heavy load on RAM and resources. RP9 recommended. Tor does complain about running on 98.

From message log:

Mar 29 18:49:48.320 [Warning] Tor is running as a server, but you are running Windows 98 SE (A); this probably won't work. See http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS for details.

I'm going to keep Tor (bridge mode) and 98 running until one or the other fails in order to determine if 98 can be an asset to Tor.

0

Share this post


Link to post
Share on other sites

Once I corrected a network error that was causing Tor to lose connectivity, I switched it to relay/exit port mode, where it's been for the last 3 days. Both are stable. Available resources and memory staying constant. Except for Tor complaining that "you are running Windows 98 SE (A); this probably won't work", there have been no other problems. Anyone know if that specific message can be turned off?

Regarding KEX database, it might be a good idea to wait until the apps compatibility and stability are verified by several people before adding it to the database. This thread will work for that.

0

Share this post


Link to post
Share on other sites

A quick update. The current stable Tor/Vidalia bundle has been running flawlessly as a relay/exit node for the last 2 weeks on 98SE. The WSAENOBUFS 10055 error that affects most non-server versions of Windows from 98 thru Win-7 when running Tor has not materialized. Either I've been very lucky or the KEX and RP9 upgrades have somehow mitigated this bug. Tihiy, Xeno, your work is nothing short of amazing!

0

Share this post


Link to post
Share on other sites

My 98SE Tor relay locked up on the evening of April 22. Total uptime 19 days 2 hours. No error messages, no warnings, just locked up. It's quite possible that this lockup is my own fault. A time sync program I use wasn't connecting to the time server, so I clicked on "connect" multiple times, not thinking that each click launched a new connection attempt. During the last few days before this crash, my system clock had started losing time, about 2 and a half minutes in 3 days. Not sure why that was happening.

This was a bit disappointing but not bad for a first run. When compared to a lot of non-server versions of XP/Vista/Win-7, with uptimes measured in hours instead of days, this is very encouraging. I'm going to make a few changes and run the test again.

Rick

0

Share this post


Link to post
Share on other sites

Have begun Tor test number 2, with the following changes.

My ISP had given me a slight speed increase (1184/448 up from 864/160) so I re-optimized my TCP stack using DrTCP, based on the tweak tester results at DSL Reports. Raised Rwin to 37752 from 20440, based on calculations from this page. Their tweak tester says this is too high but transfer efficiency stayed at 100% and I did get a slight speed increase with this setting as compared to their recommended setting. I'm getting 82-85% of the rated speed, according to their tests (according to their java speed tests to various servers). It's possible that Smoothwall (installed on a very old PC, P5-133MHZ) might be restricting the speed as well. Checking that will have to wait til I have more time.

These settings are unchanged from the Tor first test run. I've included them here as several of them are not the default settings for 98SE. All of these are at: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP

DefaultTTL 64

MaxConnections 512

TcpTimedWaitDelay 30

While examining the first run logs from Tor, I found several instances where Tor appeared to intermittently lose tract of my internet IP and started using 192.168.xxx.xxx (network card IP) instead. This was causing Tor to internittently lose connection to other relays.

From the Tor manual:

Address address

The IP address or fully qualified domain name of this server (e.g. moria.mit.edu). You can leave this unset, and Tor will guess your IP address.

KeepalivePeriod NUM

To keep firewalls from expiring connections, send a padding keepalive cell every NUM seconds on open connections that are in use. If the connection has no open circuits, it will instead be closed after NUM seconds of idleness. (Default: 5 minutes)

I added the following to torrc in an attempt to correct this problem:

Address (my real IP)

KeepalivePeriod 90

It's far too early to tell if these have made any real difference, but so far I haven't seen less than 6 open connections to/from tor and there has been over 20 established connections at times, which is more than I saw during the first test..

One negative finding I neglected to mention during the first test. The Tor network map menus and traffic graph are very unresponsive when the Black Mesa theme is selected in RP9. As much as I like that theme, I've switched back to the classic theme for the remainder of the testing.

0

Share this post


Link to post
Share on other sites

I've reached a point where I'm unsure how to proceed. Tor and Vidalia run quite well for as long as I let them. At one point, I had problems with the Tor executable using 100% of the processor. Disabling KernelEX for the Tor executable seems to have solved it. Vidalia on the other hand, needs KernelEX. I think the 100% processor usage was responsible for my system clock losing time. Since Tor requires accurate system time, I've left AnalogX's Atomic Time Sync running and have it set to synchronize every 2 hours. So far, so good. According to Shields Up and Tor's own self tests, both the directory and OR ports are reachable. My firewall (Kerio) shows a highly variable number of both inbound and outbound connections, ranging from none to well over 20. Everything I'm seeing here says Tor is working properly. Tor's test sites show me to be properly anonymized when I browse with it.

Although I'm set up to work as a relay and exit node, traffic volumes have been extremely low, and my IP has never shown up in the list of active relays or exit nodes. So far, I can't determine why, especially when both Tor and my firewall are showing it to be connected all over the world. I'm starting to think my system is not being accepted as a valid relay because it's running on 98, but have no idea on how to verify if this is the case. I did try to get some advice and help thru their IRC rooms. As soon as they saw I was using 98, all useful discussion ended. It would be a sad situation if this proves out to be the case.

The only way I can think of to determine if this is the case would be to set up a Linux system on this PC, equip it with Tor, configure it in the exact same manner, then compare the results. For me, Linux is like a foreign language. I could probably manage to install one and get Grub figured out. Trying to figure out which one to install gives me a headache. I don't know what the differences are or which ones would be fairly easy to install Tor on. I've never installed anything on Linux, so I'm not sure that I could build a proper Linux with Tor for comparison. I'm open to suggestions on both fronts, determining why my existing Tor setup isn't seeing the traffic and building a properly equipped Linux system for comparison.

0

Share this post


Link to post
Share on other sites
Tin Hat, to get acquainted, then probably Hardened Gentoo (there's a link to it, too, in the link I just gave), when and if you decide in favor of a less minimalist approach. If you want a more specilized thing, Tor-ramdisk is the way to go, though.
0

Share this post


Link to post
Share on other sites

After concluding that my low traffic levels were due to their not listing my PC as an active relay, I stopped testing running Tor as a relay. After several months and a few Tor version updates, I decided to try running Tor as a relay/exit node again, same settings, new name. After about 30 minutes running, I was listed on their active relay/exit node list for the first time. Because of this, I've seen almost as much traffic in the last 7 hours as I saw the last time in a full week. Several times Tor had 50 or more connections made, both in and out. Other than a couple of version updates to Tor (presently using 2.2.32), not much has changed on my end. Same basic PC and settings. I don't know what changed, but assuming it continues, it's finally giving me a change to test how well an upgraded 98 unit will serve as a Tor relay under a real load and how long it will hold up.

post-118612-0-59143600-1318211661_thumb. post-118612-0-54320200-1318211883_thumb.

0

Share this post


Link to post
Share on other sites

Some observations after running as a relay/exit node for almost 3 days. Tor has handled 2.5GB of combined inbound and outbound traffic. System and GDI resources have dropped slightly, still over 66%.

Processor usage stays low except for when Vidalia is updating the server listings, at which time it's 100%. My system clock loses time when this happens. Since Tor requires accurate system time, I had set Atomic Time Sync to update the clock. Originally the interval was daily but the time loss events are becoming more common and I've repeatedly shortened the synchronize interval, which is now at every 15 minutes.

According to Memload, the combined memory load for Tor and Vidalia is just under 30MB. So far, my system has not used the swap file and still has 222MB available of physical memory available out of a reported total of 917MB. This number seems to be slowly dropping, both as reported by Memload and by the system properties screen. My system normally reports 922MB total. I have no explanation for this drop. Memload also reports a substantial increase in memory usage by kernel32.dll. Normally the memory usage for kernel32.dll iis between 400 and 750k. It is now at 8.8MB. I'm not certain that this is due to the Tor/Vidalia load or if SocksCap is causing a problem. According to the properties screen, I'm using version 4.10.2226. It's MD5 is d8fc316196045f3cf4c348bd61fc4540

Are there any known memory leaks or other problems associated with this version? Is there a way to determine why kernel32.dll is using so much more memory than normal?

Right now, I'm seeing graphics errors with the browsers (SeaMonkey and K-Meleon), mixed up page elements, desktop items visible thru the browser window, and parts of the page not rendered at all. I'm suspecting a crash is close at hand. I just hate to shut Tor down and reboot since this is the only time my PC has been listed as a valid and active relay.

0

Share this post


Link to post
Share on other sites

The last Tor test has been cut short, not by 98 crashing but by a power failure here. The increased memory usage by kernel32.dll does appear to be caused by SocksCap. After I shut it off, the memory load for kernel32.dll dropped to 2.6MB. The browser graphics improved some but did not get back to normal. The browser wouldn't render properly at full screen. Overall, I was pleasantly surprised by 98s performance. It had handled nearly 4GB of traffic without any problems. I had to reduce the bandwidth settings for Tor as it consumed all of my DSL bandwidth at times and was interfering with the phone service's ability to function. I'm going to change some Kex settings for SocksCap and Vidalia, then start the test again. Hopefully I'll get listed as a valid relay again so I can get the traffic load.

0

Share this post


Link to post
Share on other sites

It seems that every time I try to get a long test run going, Tor updates and I have to choose between running an old version or starting the test over, but this time it's necessary to update. Tor has recently patched a vulnerability that allows an attacker to deanonymize users. More info here. The present stable Tor/Vidalia bundle is version 0.2.2.34-0.2.15, available here.

The Vidalia bundle remains compatible with Kex modified 98 systems. I ran the installer with the default Kex settings. Vidalia works with Kex on the default setting. On my PC, the Tor executable seems to work best with Kex disabled. Thankfully, the Tor network has been consistently accepting my system as a valid relay which greatly increases the traffic volume and allows me to test 98 under load. I'm running Tor as a somewhat limited exit node.

post-118612-0-01221400-1319900037_thumb.

I had to reduce the bandwidth settings for Tor 24 KB/s average and 32 KB/s maximum due to my low capacity DSL service, which is also my phone service via a separate VOIP modem. When the settings were higher, the bandwidth Tor consumed prevented me from receiving incoming calls. At these settings, both seem to work properly. I haven't changed anything with the old PC I'm using for Smoothwall. I don't have enough network cards to equip another PC for Smoothwall. Switching would require removing the cards from the existing unit, building the next one, then installing,testing and configuring Smoothwall. This would take down both my phone and internet service for an extended period. As far as I've been able to determine, it is not a limiting factor in my home networks performance.

The registry changes mentioned in post 5 are still in place. In the torrc config file, I've kept the address entry and removed the KeepAlive entry as it doesn't seem necessary.

I can confirm that SocksCap was responsible for the increasing memory usage by kernel32.dll and has also been responsible for a few system lockups. As time permits and as much as I can without shutting down the relay, I'll explore using different Kex settings for the SocksCap executables and into alternatives to using it. SeaMonkey itself is able to connect to Tor via socks but Proxomitron is not. I'm not convinced that SeaMonkey itself (with or without extensions) can be configured not to leak identifiable and trackable data without having Proxomitron filtering the content. Privoxy is a potential alternative to Proxomitron, and it is socks compatible but I'm not familiar with its filtering abilities and limitations. Another possibility would be to use Privoxy strictly for socks compatibility, using it as a substitute for SocksCap, eg SeaMonkey>Proxomitron>Privoxy>Tor. This would require very specific firewall rules and proxy settings in order to prevent javascript, java, flash, etc from bypassing the filtering and revealing your true IP and location. For most users, this isn't that big of a deal, depending on your usage, but in some countries (oppressive regimes) leaking your real IP could literally be a death sentence.

0

Share this post


Link to post
Share on other sites

A quick update. I've reached a bit of a dilemma regarding which way to go with the testing. This has become at least 3 separate but related tests.

1, Can 98 effectively serve as a Tor relay, for how long, and under what loads? As a client, there's no problems running Tor on 98.

2, Can Vidalia be made to run stable on 98 for an extended period?

3, Can SocksCap be made stable on 98 for an extended period? If not, what alternatives can replace it?

Tor itself is running very well as an exit node. At times, Kerio has displayed over 100 connections to it with the average number being around 40-50. According to TorStatus, it has reached the 4 day mark. At present, this is the only relay or exit node running Windows 98 listed there. That in itself is a tribute to all of those who worked on all the unofficial upgrade projects.

Vidalia is proving to be another matter. Starting last night, Vidalia has been gradually becoming dysfunctional. First, it stopped displaying the network status. This was followed by the traffic graph and the message log failing. Memload and the system resource meter showed the systems had plenty of both available. When Kerio no longer showed any connection between Vidalia and Tor, I terminated Vidalia via SSM. The graphics errors I described in the Oct 12 post, were beginning to appear again, but disappeared after I'd terminated Vidalia. Kex for Vidalia was set to default, which seemed to work good for the previous version. The default setting for Vidalia was to automatically generate a random password when it authenticates itself to Tor. Unfortunately, if Vidalia crashes or gets shut down and Tor continues to run, Vidalia is not able to reconnect to it when restarted. For all further testing, I'll assign a static password to avoid this problem.

At this moment, Tor is running and relaying traffic, but I have no ability to monitor its activity. Tor does not actually require Vidalia in order to work and will continue to function according to the torrc config file. The Tor "expert bundle" doesn't include it, but it is a very useful and handy interface. Any further testing of Vidalia would require me to terminate and restart Tor. Without Vidalia, I have no way to alert the other relays that my exit node would be shut down. For the present, I'm going to continue testing the ability of 98 to serve as a Tor relay until one or the other fails. Without Vidalia, I won't be able to get accurate traffic volume figures, but I can get a good indication from TorStatus and from Kerio's status screen. If/when one or the other fails, I will resume testing Vidalia and SocksCap with different Kex settings (and a fixed Vidalia password so I can restart it if needed).

Edited by herbalist
0

Share this post


Link to post
Share on other sites

After 15+ days and an unknown amount of traffic running as a Tor exit node, my system became unstable, forcing me to reboot. I was quite surprised when I compared the performance of this 98 exit node to the other exit nodes running Windows at the time. There were just 16 exit nodes running Windows that had remained up for an equal amount of time or longer, half of which were server versions. Out of a total of 2448 Tor relays, this is the only one running 98 and was listed as valid, named, fast and stable, a real tribute to the developers of Kex and RP9.

I'm fairly sure that the majority of the instability was due to Vidalia, which gives me 3 options.

  1. Find Kex settings that will make Vidalia stable in the long run. If it can be done, it's the most desirable option.
  2. Run Tor in expert mode without Vidalia. At the moment, this is my most stable option as Tor is stable on 98 on a long run but it does restrict my ability to monitor and control Tor "on the fly".
  3. Use Vidalia only to start and check on Tor and kill the process when it's not needed. A quick test using a fixed password shows that I can reconnect to Tor with Vidalia. Unfortunately, the traffic graphs and message logs reset each time. The network map also fails to function properly when used this way.

During the last run, I had to set Atomic Time Sync to adjust the system clock every 10 minutes. So far, I can't pinpoint what is causing the system to lose time.

I also need to determine if Tor itself is causing any of the long term instability or if it was all caused by Vidalia and/or SocksCap.

I need to test if this system can still perform other tasks heavier than web browsing while serving as a relay/exit node. Judging by the memory and resource usage, it should be able to, bit I'm suspecting that there's other limitations that Tor is taxing.

For the next run, I will modify the torrc config file, run Tor without Vidalia and try to determine if Tor itself is contributing to the system clock losing time. This will also help to determine if 98 can still perform the other heavier tasks like virtualization at the same time or if serving as a relay/exit node approaches the limits of 98.

0

Share this post


Link to post
Share on other sites

During the last run, I had to set Atomic Time Sync to adjust the system clock every 10 minutes. So far, I can't pinpoint what is causing the system to lose time.

For the next run, I will modify the torrc config file, run Tor without Vidalia and try to determine if Tor itself is contributing to the system clock losing time. This will also help to determine if 98 can still perform the other heavier tasks like virtualization at the same time or if serving as a relay/exit node approaches the limits of 98.

Heavy Internet usage oftens leads to missed Clock ticks. This will cause the System Clock to fall behind. Once started, Windows 9x does not reread the CMOS Clock.

0

Share this post


Link to post
Share on other sites

Is there any realistic way to prevent this or is an app like Atomic Time Sync the only real option? I have seen the system clock lose time when processor usage hits 100% for an extended period but I don't think that's happening here. Most of the time, I see very little processor usage.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.