Jack, one of the problems we saw earlier with a handful of people was pretty much just like Leos' problem. Could traceroute with seti or other projects, could get work from other projects, just not seti. Adjusting the MTU size worked for some. There's a theory about fragmentation and the berkeley server. I felt it worth giving it a shot.

Since I enabled "Black Hole detection", I have one of 39 "stuck" workunits downloading from Seti to a client that is devoid of Seti workunits. It is slow, 650 bits / sec., but running.
I read the links from Wander's post, and decided to keep poking...
Ok, it finished, but it was the only one to download. Patience, patience...

---

For dialup you don't need a higher MTU than 576.

Between all the MTU changes, you did reboot your computer? For DrTCP will write to the registry.

I also saw this bit you wrote:
Dr TCP only wants to work with my ethernet connection, not my dialup one. ... is it not recognized by DrTCP? There should be a drop down window in DrTCP with which you can choose which TCP connection you want to change.

All the changes on MTU you made on your LAN card don't matter for the dialup connection. They will only slow down/speed up your network connection, not your internet connection.

If DrTCP doesn't want to work with you, use this page.

---

For dialup you don't need a higher MTU than 576.

Good advice.

Now that we know you are using Dial-up. This was not clear before as you kept talking about your network, so it is assumed you have a DSL/Cable connection and was using an MTU of 1500 (the default).

What is still not clear to me, are you dialing up from each system and having failures, or are you running Internet Connection Sharing (ICS) on one system and using the wi-fi router as a switch off of it to provide Internet access to the other systems. I am going to assume you are running ICS on one of your systems.

If ICS, is the system with the dial-up the one that is working, and the rest of them the ones having trouble? Also, if you are running ICS, and have a Wi-Fi router, depending on its setup, that might explain the "Redirects hit maximum amount" error. Are the wi-fi attached systems the ones with a problem?

Being dial-up, MTU will not be an issue as long as the dial-up adapter's MTU is set to 576. I think XP forces this setting. Windows 9x does not, but is the default. There may be a problem with the TCP Receive Window setting also which you have not posted. So time to clean house and start over. Go through each of your systems using DrTCP and under Adapter Setting, set the Dial-Up Adapter to MTU= 576 and the NIC(s) all to 1500. For all of them, set the "Path MTU Discovery" to Yes, and "Black Hole Detection" to No. For an Internet connection using Dial-up and and MTU of 576, there is no such thing as a Black Hole router, it would be called a "broken router" and would be quickly fixed or replaced. Black Hole detection also slows the connections down too much.

In addition, you want to set the TCP Receive Window to 5,360 on all systems for now. This will limit the amount of data that web servers try to send at one time, to 10 packets. This may slow Internet access down a little, but the objective is to get it working, later try upping it to 10,720. After setting each system, reboot them.

Next, go into the router and set its Max MTU to 1500 or AUTO (I know of no wi-fi enabled routers that have MTU Auto setting problems). As you have MTU path discovery enabled in the system, the router will pass what ever comes through with out trying to fragment it. This will allow your systems to talk to each other, and not have problems when connecting through the dial-up. As the dial-up ICS will be limited to MTU of 576, Path discovery on each system will automatically drop down to that size of packet.

When Berkeley's servers do Path Discovery and hit your ICS server, they will drop to 576 also, so everything should work as far as MTU is concerned.

TCP Receive Window = 5,360
Window Scaling = NO
Time Stamping = No
Selective Acks = Yes

Path MTU Discovery = Yes
Black Hole Detection = No
Max. Duplicate ACKs = 3
TTL = 64

Dial-Up Adapter MTU = 576
NIC adapters MTU = 1500

The ICS MTU should be blank and grayed out on all systems except the one running ICS if you are using it. This setting should be left blank and if not blank should be set to 576.

This should get your systems all to a fixed standard configuration, so that the remaining concerns have to do with delays in the path. It looks like your dial-up and ICS is causing the high time= values. Do the ping's from the dial-up system and see if they are that high, it should have the lowest times.

At this point, I am thinking there might be something wrong with the system running ICS and hosting the Dial-up. Its settings might be off. It might be a slow machine, or there might be something running in the background slowing it down, or the ICS priority settings are wrong. If you have trux's Client (or have had it installed) and played with the priority setting of BOINC and the application, that would cause problems with ICS and slow it down. You might not be able to run BOINC on a machine running ICS. As a test, completely shutdown BOINC on the machine running ICS and see if the other machines can connect and if it improves their ping time. If that solves the problem, you will have to shut BOINC on that system down when the other need to connect, until all of this is sorted out.

There could also be a problem with LibcURL when running through an ICS host and going through a wi-fi link that has problems. I suspect that some of your problems might be related to wi-fi connection problems. The only way to tell is to see if there is a difference between wired connections and wi-fi connections.

First get to a known MTU configuration, post the ping times, and let us know if you are using ICS on one system doing the dial-up. That could be important.

One test that can be done, if you can, is take one of the other systems and hook it up to a modem and phone line and make a dial-up connection with just that system, and see if it can connect and upload/download by itself, not going through the network or ICS. Check the ping times on it. This would tell us if it is a problem with your ISP and/or BOINC, or a problem with your network and ICS delays. BOINC on the system with the dial-up and ICS still has to go through ICS. Trying to decide if having you install Ethereal on one of the systems would gather useful information, just not yet.

Oh Persons! (PC version of Oh Man!)
I don't even remember my chain of thought when I came up with this, it had to do with ping from inside the network or something. Anyway, I have been using the AnalogX software proxy server for I don't remember how long. It does HTTP proxy on port 6588. It has worked since I remember. End of that point. I never used Microsoft ICS. I got a copy of FreeProxy, it does HTTP proxy on port 8080. As soon as I set the proxy server settings on all the clients using Boincview to point to port 8080 on the same system that I have been using from the start, all downloads have resumed. I am currently down to 23 files that need downloading, down from 40 last night.

---

Oh Persons! (PC version of Oh Man!)
I don't even remember my chain of thought when I came up with this, it had to do with ping from inside the network or something. Anyway, I have been using the AnalogX software proxy server for I don't remember how long. It does HTTP proxy on port 6588. It has worked since I remember. End of that point. I never used Microsoft ICS. I got a copy of FreeProxy, it does HTTP proxy on port 8080. As soon as I set the proxy server settings on all the clients using Boincview to point to port 8080 on the same system that I have been using from the start, all downloads have resumed. I am currently down to 23 files that need downloading, down from 40 last night.

Ok, all workunits are now done downloading. I am still wondering what happened that forced the incompatability between Seti Berkeley and AnalogX proxy? All I ended up doing was changing the proxy server to fix this problem, the only difference that I can see is that the port numbers that the software proxy servers use are different. The AnalogX proxy worked for half of the systems when I was having the problem, which was why I didn't suspect it to be the source, and I hadn't had any system problems on any of the systems, at all. If a system had hiccupped or burped or exhibited any sign of a problem, that would have pointed me in a different direction, but it never happened. I certainly appreciate all the time all of you spent in trying to help me sort this one out. I really got into more of the settings for all this stuff than I normally would have, it hasn't been too difficult to make it all work up until now. Like most people, when something new comes out, I tend to take my time warming up to it, especially when what I have gotten accustomed to using was working well for me (Classic).

---

Hi Wander,
Yes, that was sort of what I lamented when I started this part out tonight. Make a change, document what was done, reboot. Start up the apps. Check and test. Make more changes, try again. Then you show me the shortcut. Maybe someone could put together a master troubleshooting page. That would have saved me some time. But I had to try to get updates on the systems that haven't been able to since the last outage, and that took some time also. Maybe this thing will get popped open soon, and I can finish out of Einstein, and back to Seti.

Hi Leo,

Paul Buck has such a page in his Boinc-Wiki site. It covers most common connectivity problems, but I think you already seen it. Other than that, there are several users around here with similar simptoms, but unfortunately each resolution is different. Sometimes is a firmware update, an obscure firewall setting, or registry tweak that does the trick. The only thing we can do is keep trying like you did.

Regards,
Wander

---