[herbalist]

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:

Quote

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....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.

[herbalist]

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.

[herbalist]

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!

[herbalist]

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

[herbalist]

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:

Quote

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.

[herbalist]

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.

[dencorso]

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.

[herbalist]

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.
 Tor traffic.gif (31.77K)
Number of downloads: 17  Tor connections.gif (70.2K)
Number of downloads: 12

[herbalist]

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.

[herbalist]

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.

[herbalist]

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.
 Tor exit policies.gif (66.02K)
Number of downloads: 5
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.

[herbalist]

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).

This post has been edited by herbalist: 01 November 2011 - 06:22 PM

[herbalist]

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.

• Find Kex settings that will make Vidalia stable in the long run. If it can be done, it's the most desirable option.
  
• 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".
  
• 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.

[rloew]

herbalist, on 13 November 2011 - 02:39 PM, said:

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.

[herbalist]

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.

[rloew]

herbalist, on 13 November 2011 - 05:11 PM, said:

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.

I think the problem may be more related to Interrupt latency than CPU usage.

An APP would be required, but it may be sufficient to read the CMOS Clock rather than reaching out to a time server.

[herbalist]

ATS has worked well for me, after I found an easy to contact time server, but I would prefer to eliminate the problem instead of constantly correcting the clock. Is there any realistic way to prevent it? I'm monitoring processor usage via Process Explorer, resource usage with the built in meter, and memory usage with MemLoad 2.0. ATS is checking server time every 10 minutes but is not correcting the system clock. Is there something else I should be monitoring in order to track this down? Is there an app that can read the CMOS clock and correct the system clock?


After the last restart, I installed a bandwidth monitor and changed the Tor configuration file to log to file instead of sending the output to Vidalia. For now, I've stopped using Vidalia entirely. With the bandwidth monitor and Tor logging to file, Vidalia doesn't serve much purpose. The relay has been back up for a bit over 4 hours, but the traffic level and number of connections are not yet up to their earlier levels. That will probably take a day or so. So far, the system clock has lost no time. During the previous Tor trials, I restricted the usage of this PC to light tasks like web browsing, light CD work, etc. While I want it to be a stable Tor exit that contributes to the network, I can't limit it to that role. It is my primary PC so I will not be limiting its usage during the current test run. So far, it seems able to run Tor and Virtual PC at the same time, but it's only been a bit over 5 hours since it was restarted.

[jumper]

herbalist, on 13 November 2011 - 09:14 PM, said:

Is there an app that can read the CMOS clock and correct the system clock?

tad -s seems to work correctly, but in a DOS box.
ClockMon is for NT, might work in 9x, but uses 'giveio.sys' helper driver.
Both come with source code.

[herbalist]

Thanks for the links. ClockMon works great on 98. It doesn't appear to need Kex. I didn't need to do anything with the driver. Just unzip and go. My CMOS clock has been within a second of the time retrieved by ATS. It has been Windows losing time. Running without Vidalia has lessened the time loss by at least 75%.

When I ran µTorrent on its default settings to download a rather large file (approx 600MB) from multiple sources, Tor crashed, according to its log "unknown errors". The Tor traffic was fairly heavy at the time and both apps had established a large number of connections. I don't know exactly how many total connections there were, at least 2 full status screens on Kerio, estimating around 150. 98 was stalling and becoming intermittently unresponsive just before Tor crashed. It appears that the maximum number of allowed connections is set too high, presently at 512. The number of allowed connections for µTorrent definitely needs to be restricted. Other than trial and error, is there a realistic way to determine what the maximum number of connections is that an individual PC can handle?

Except for the connections issue from using Tor and µTorrent together, everything else has performed well and been stable with Tor running. After making a full backup of the existing system, I updated Kex to the latest version. Going to see what else this new version makes possible and make sure that it's compatible with the rest of the apps I use. I'm interested to see how well SeaMonkey 2.4 works on my system and how it compares to 2.0.14. Tor is restarted, running with the same settings. I have no immediate tests planned for it other than its effect the long term stability of the PC during normal usage.

[herbalist]

A quick update. Real life issues have kept me from giving this and other projects/experiments the time they deserve. For the most part, I've kept Tor updated and left it running as an exit node. On January 7, I updated Tor-Vidalia to the current version, 0.2.2.35-0.2.15-1. I'm no longer using Vidalia to start or monitor Tor, choosing to start Tor directly. I assigned a set password and use Vidalia just for controlled shutdowns of Tor. I haven't been able to make Vidalia stable on 98 for an extended time. On my system, the Vidalia network map works inconsistently to start, then not at all after a couple days. NetMeter has proven to be an excellent replacement for Vidalia's traffic monitor. I've changed torrc to log events to file instead of relying on the Vidalia message log. ClockMon has solved the problem of the Windows time clock losing time, making it unnecessary to use Time Sync. The present version of Tor has been running for 12 and 1/2 days. The previous version ran for 5 before I shut it down and updated. All total, this 98 unit has been running as an exit node for almost 18 days now. TorStatus changed its status yesterday, listing it as a stable relay, after which the traffic volume tripled. Except for some minor graphics issues with the browser when it's maximized, there have been no observable problems, save being slow when the Tor traffic load is heavy.

A couple entries in the Tor log caught my attention and are the main reason I'm adding this update. On the morning of January 18, before my exit node status was changed to stable, I saw the WSAENOBUFS error for the first time. The entry appears twice in the log:

Jan 18 06:33:53.890 [warn] write() failed: WSAENOBUFS. Not enough ram?
Jan 18 06:43:48.450 [warn] write() failed: WSAENOBUFS. Not enough ram?

MemLoad showed I had 280MB of RAM available. The swap file hasn't been used. Both instances took place while I had a large download in process and had several tabs open in SeaMonkey.
Neither Tor or Windows crashed and neither showed any problems afterwards. Unless I've misunderstood the Tor bugtrak pages regarding this error, I was under the impression that this was terminal to Tor, causing it to crash and required a reboot of Windows to fix, none of which happened. My understanding of this error and the underlying system is quite limited. Could someone more knowledgeable look at these Torproject pages and tell me if I've got it wrong or have the upgrades made it possible for 98 to recover from a normally terminal error and continue to function?
https://trac.torproj...sBufferProblems
https://trac.torproj...t/98#comment:74