BOHICASETI 2005-09-28 21:19:30 | What is this message that comes across whenever my machines attempt to upload results? Probably been happening for a while now, I just now noticed. Saw the other day that my CPU usage was at 0% and got to wondering if Muon and shut down somehow. When I opened up the taskmanager it was still loaded though so I figured that it was busy uploading results, no big deal. But after about 10 minutes of waiting I noticed that it still wasn't using my CPU at all so I decided to run the command line version on a couple of my computers and take a look at the readout when it hit one of these points of non-action. That's when I saw the "500 RT not understood" & "500 'RT': command not understood." messages that it sorta hangs at when trying to upload. I'm running the latest version of muon on all my machines and noticed that I have several files with the extention of TXT and BIN with my user name at the end (assuming these are results that it's having trouble sending or something) just sitting in the directory. Are these results actually getting to a server and then being sent again later thinking that it wasn't able to make it the first time or are these results sitting on my machine that havn't made it up yet? This is all very curious to me as I have witnessed countless times when my stats totals drop randomly (as I have posted elsewhere)and also when I have uploaded large amounts of results (after hording them for a few days before sending) and not seeing any reflection to my stats at all it seems. Is there a problem with how some of the result FTP servers are set up? If so then the issue should be resolved or the troublesome FTP servers shut down. Or maybe it's a problem with the muon clients uploading ability? Whatever it is I'm pretty sure it's not on my end cause out of 5 computers in my house, 5 of them are doing exact same thing with this 500 RT not understood stuff. As I've typed this message I've watched my client try to upload the results 6 times to 6 different servers with the same end result. |
Stephen Brooks 2005-10-31 08:35:14 | Other people don't have this problem, so far as I know, so it could be a question of your ISP or firewall settings. (I have Muon1 running at home, which has effectively been going for weeks without any irregularities with uploading). The oddly-named results files can be renamed back to results.txt one at a time and sent with manualsend.bat (once you've found a location from which they actually will send). |
BOHICASETI 2005-12-03 13:35:48 | Any chance I can just email you my results every week or so Stephen? I mean around half of the time that my machines try to send in results it wastes around 30 minutes slowly going through 10 attempts to upload. And part of the time I watch it as it uploads my results to the random FTP server and then it attepts to grab some type of test file and gets an error on that part of it and then retries all over again. This is where the duplicate results are comming from I believe. As after I watched this happen it had uploaded a couple of the results twice on a couple of my machines and then the next day on the stats page I noticed I lost some of my points (which I should have due to the duped uploads). But seeing this in action has given me a breath of fresh air as I was worried before that you might have had some kind of digital muon point eating monster on your side. But it does bother me that my machines will sit here idle for quite a bit of time without doing anything other than trying to re-upload results because of FTP errors. My machines range from Windows 2000 to Win XP Pro 64bit, and like I said sometimes they go through just fine and other times they hang or give an error of RT 500 command not understood, or that test file upload thing that it does spits out a digital explitive. Somehow I'm thinking you need to fine-tune or completely redo the method of uploading results. At first I thought it might be specific servers and so I manually changed the servers.csv to only list 1 server (tried with several FTP servers including yours)and got the same activity no matter what server I went to. Hope this information helps some. |
BOHICASETI 2005-12-03 13:40:00 | Here's a huge block of spam of copied text of the command prompt Muon on this machine. You can see on the 5th attempt where it has uploaded the results but still hasn't declared itself happy with everything and decides to try some more.
|
wmikrut 2005-12-03 17:28:59 | I've been having that same problem too with autosend. Even the manual send is having the same problems. |
Stephen Brooks 2005-12-05 06:28:16 | I looked up the error on the internet http://www.google.com/search?q=FTP+error+500+%22RT+not+understood%22 and the only useful comment I found on it so far was Other applications (e.g. FrontPage) seem to have this problem at times. One or two of the servers in the long printout above look like they're not quite configured properly (e.g. no testfiles directory so the program can't confirm it's sent properly). |
Stephen Brooks 2005-12-05 06:35:59 | Since this problem only surfaced recently and I haven't changed the upload method for a long time, I'm beginning to suspect a bad Windows patch or firewall update is responsible. The uploads would fail before, but this RT error is new and much more frequent. [edit] Another thought - are you using a home router, and if so, which brand? |
wmikrut 2005-12-05 07:34:01 | I am using a Linux machine as my gateway for internet access for my internal network. Interestingly, I cannot use the auto/manual send as the FTP script continues to fail with Illegal Port Command issues across multiple servers for MUON1... even in passive mode. Now, if I fire up an FTP client (SmartFTP), I can connect to the site in question manually and drop off the .bin file with no trouble. I did have one machine at still another region that seemed to be functioning normally to this day. Autosend was working without problems. The only difference between that machine and all the others is that it is not subject to Windows Automatic Updates. All the others are... or at least the consoles for each group. I will try to roll back the updates that have been applied to my machine here over the past week and see if that resolves any problems. If not, I can capture and analyze the TCP traffic to see if I can pinpoint what's going wrong with the communication. |
Stephen Brooks 2005-12-05 08:18:54 | Yes, it would be useful to know if, for example, one automatic update corrupted the Windows default FTP program. If so, I could bundle the older version with Muon1. Incidentally, have you noticed in config.txt there's an option to change the commandline used in invoking the FTP script? So if you download another scriptable FTP client, that might also be a workaround. Also, the above printout showed one or two other configuration issues with a couple of the servers, which I've e-mailed their owners about |
wmikrut 2005-12-05 21:14:24 | I was able to solve the problem and I am happy to report is was not a Windows problem at all. To make a long story short, I have been using a Linux server as my firewall and gateway for years. Apparently, a little hiccup in the NAT configuration was causing the process to fail. Once I corrected the NAT problem, the script ran with no errors in passive mode. |
Stephen Brooks 2005-12-06 02:12:03 | I think dodgy NAT setups are rather common - I recall in university there was a system over which half the applications wouldn't work due to such a thing. Was what you fixed something that other people could likely have got wrong? |
wmikrut 2005-12-06 06:48:44 | I can only guess that I never noticed the NAT problem on my end because I considered it a minor annoyance and found a way to work around it. My firewall script was missing a few key modules that were needed to make the NAT function properly when it comes to ftp. Here is what the revised module list look like on my machine (2.4 kernel) relating to NAT: /sbin/modprobe ip_tables /sbin/modprobe ip_conntrack /sbin/modprobe ip_conntrack_ftp <-- Was missing /sbin/modprobe ip_conntrack_irc <-- Was missing /sbin/modprobe iptable_nat /sbin/modprobe ip_nat_ftp <-- Was missing /sbin/modprobe iptable_filter /sbin/modprobe iptable_mangle I also revised the NAT code at the end of the script to look like this: /sbin/iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT /sbin/iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT /sbin/iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE /sbin/iptables --append FORWARD --in-interface eth1 -j ACCEPT /sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE /sbin/iptables -A FORWARD -j ACCEPT Perhaps there is some redundancy there... but it does work. |
BOHICASETI 2005-12-07 23:04:40 | I ended up setting up a virtual WinXP box with VMware and just left it at a generic install with no updates. I move my result files to here and use the manualsend to upload my results now. Seems to have worked flawlessly so far. I guess that one of the previous MicroSoft updates in the last month or 2 must have pumped in a snafu that's just too obscure to really catch. Considering it would sometimes work and sometimes not work leads me think it might be a while before it gets figured out. ( I just don't see many people using the built-in FTP client in Windows enough to justify Microsoft trying to figure out what might be buggy or not). But in the end I'm content to just leave the Autosend Option turned off and just move the result.txt files over the network and manually send them every few days or so. Thanks again Stephen. |
Stephen Brooks 2005-12-09 02:11:37 | Any chance you could e-mail me the ftp.exe from the un-patched machine? Or even better just upload it to this board, so you and others can try seeing what happens when you replace the "updated" ftp.exe by the older one. |