Troubleshooting Network Problems

From Unofficial BOINC Wiki

The BOINC Wiki is looking for editors to edit pages for readability. If you think you can help, propose your changes on the discussion page. If you recieve no objections, implement the changes. This page needs your help.

Contents 1 General 2 First Things First 3 General Outline of Testing 4 Testing Fundamental Connectivity 4.1 Browser Test 4.2 Master Page Test 5 Automated Test For Microsoft Windows® 6 Ping Test 7 Checking ipconfig 8 Checking Trace-Route 8.1 Trace-Route Apple OS-X 8.2 Trace-Route/Trace-Path Linux 8.3 Trace-Route MicroSoft Windows 9 "Black Hole" Routers 10 Checking Firewall Settings 10.1 Firewall Settings for Microsoft Windows® 10.2 Firewall Settings for Apple OS-X 10.3 Firewall Settings for Linux 11 Inability To Connect To Project Servers – Some Or All Of The Update, Upload, or Download Actions Result in Error Code 500 11.1 Things That Can Be Done To Overcome Problems 12 It still does not work?

[edit] General

Connectivity problems do arise from time to time. These can be caused by many factors and experience suggests most are not connected with the projects to which you are attached. With the exception of the project being down for maintenance (or catching up after maintenance) or a known and publicized project fault it is normally some part of the connection between you and the project that is faulty.

In this guide we will try to assist you in the isolation of networking issues that are preventing your computer and the Project's Servers from communicating with each other. To the greatest extent possible we will try to simplify this complex topic by giving you step-by-step instructions with details of exactly what you must do, for each and every step, and what you should expect to see as a result of the instructions.

Keep in mind, that although we will try to make this as complete and accurate as possible, it may require that you perform some or all of these tests and then solicit assistance from the other Participants using the Forums.

[edit] First Things First

This first "test" is the simplest, but most often skipped test. Reboot your computer. That is it. Try this first. I had a case where all the computers at home were connecting to the Projects, except my PowerMac.

What fixed it? A re-boot ... Why? Who knows!

Try this first. Reboot the machine. If you have any Routers or Voice Over IP (VoIP) interfaces in the network they may need to be rebooted also. Check with your owner's manual for your specific device for instructions on rebooting these devices.

[edit] General Outline of Testing

From experience, the likely areas where things go wrong are summarized below. It may be worth your time to check these things out:

1. Check the Project’s front web page to see if the project is indeed up and running.
2. Check the project's "Questions & Problems" Forum and "Number Crunching" Forum to see if other Participants are seeing a problem connecting or communicating with the Project's Servers.
3. Check you are connected as you are supposed to be or you think you are – it is plugged in, powered up, you have other network services running etc.
4. Check to see if your systems security settings have changed – e.g. firewall on PC or at your gateway to the {WP:|Internet}}.
5. If you are having problems with a work or school computer, have the organisation’s security settings changed?
6. Could it be that the proxy you have been using is no longer available or that the passwords have changed?
7. Could your ISP be having problems at the moment and is unable to pass your data or is preventing you from connecting to the Project?
8. Could another ISP en-route to the Project be having problems and cannot pass your data?
9. An ISP is running with faults and cannot pass all the data sent and received and is dropping data in order to survive. Only partial data is getting through?
10. ISPs etc that carry traffic have argued and fallen out. This has caused them to de-peer and traffic is being lost as there is no route?
11. Name server changes have not propagated yet and the project name to address mapping you are getting is not yet up to date?
12. The project’s firewall (or that of the organization of which they are part) has changed and won’t pass you data any more?
13. Badly configured or malfunctioning PC or LAN equipment?
14. Project software bugs are causing some people some problems?
15. Badly configured equipment en-route is preventing needed warning messages from being sent and/or received and responded too by other devices. This is causing the loss of messages to and from projects?

All the areas above can cause connection problems in some way. Try and check them out as best you can as it is a 99.9% likelihood that one of these issues is the one that is giving you your problem.

[edit] Testing Fundamental Connectivity

[edit] Browser Test

In this series of tests we are trying to see if your home network and systems can even access the Internet.

• Open your favorite Web Browser to your normal "Home Page".
  • Did the page open?
    • If the page opened, Check the date and time. Are they correct?
      • If the date and time of your normal "Home Page" are correct, go to the Master Page Test
  • If the page did not open, then ...
    • Check to see if the switch, router, and modem status lights are indicating an error.
  • If the page appeared to open, but the data and time are not correct, try connecting to another site.
    • If you cannot seem to connect to the Internet, your problem is likely between your computer and the Internet access point.
    • If you can connect to the Internet, we now need to look at issues related to the connection of the BOINC Client Software to the Internet.

[edit] Master Page Test

Using the table below, click on the link for the specific BOINC Powered Project with which you are having a connection problem.

Project
Climateprediction.net (CPDN)
BURP
Einstein@Home
The Lattice Project
LHC@Home
Predictor@Home
SETI@Home

• If the Project's Master Page opened, is there a note in the "News" indicating an outage?
  • If there is an known outage, you just have to wait until the Project comes back up.
  • If the Project's Master Page opened, and there is no announced outage, check the Project's status.

Note:

Some Projects will not have a "status" page, others will have a summary on the Project's Master Page (The "home" page of the Project) only.

Note:

In all cases, the page may not be up-to-date, you can check the last updated indication. However, keep in mind, the Servers may be "up" but there is no connection to the Internet from the Servers themselves.

Project
Climateprediction.net
BURP
Einstein@Home
The Lattice Project
LHC@Home
Predictor@Home
SETI@Home

• If the page did not open:
  • In the case of SETI@Home:

"Cricket" Graph

Check the Cricket Network Graph, to see if the network link is down. The graph in the upper left corner shows the bits being sent into and out from the Servers at Berkeley. Looking at the example we have here, you can see the effect of the downloads of a new SETI@Home Science Application (Version 4.18), as the data rate out of UCB is peaked at ~90mbits/sec (on the left side). Then it trails down to the more normal ~60 mbits/sec.

When one of the Data Servers (for either SETI@Home Classic or SETI@Home Powered by BOINC) goes down, the data rate drops to ~30 mbits/sec.

When both Projects are not delivering data, the data rate drops to near 0. This can be either that the Servers are down, or there is an internal problem at the Space Science Laboratory (the "home" of SETI@Home), or the Cogent link is down.

Was the connection made?

• Using the same table, can you connect to another BOINC Powered Project?

[edit] Automated Test For Microsoft Windows®

Ian Tighe developed this automated test program for use with Microsoft Windows®.

• Download this file: Batch Program for Microsoft Windows®
• Copy the contents of this zip archive into a temporary directory.
• Double-Click on the file "boinctrace.bat".

The program should run and as it is running give you status messages. If there are failures, the program will halt and indicate where the test failed. The output log file "boinc_trace_log.txt" will contain the information about which tests passed and which ones failed.

Note:

There may be a problem with some Linksys routers, notably the model BEFSX41, where the router does a "cold start" during the "trace route" tests. The cause of this is unknown at this time but has been reported to Linksys.

[edit] Ping Test

In this test, we want to see if you can find other computers including other computers on your home network (if any).

Note:

There seems to be a buglet in Microsoft Windows® where the systems do not properly resolve when pinged. Even when you have respond to ping "On". If your machines are not responding, make sure that there is at least one "shared" folder visible to the other computers. This one caused me NO END of trouble trying to figure out why I could not get one or two computers to respond to a "ping".

[edit] Checking ipconfig

Run the program ipconfig in a separate command prompt window. Your output should look like the example here.

ipconfig:
IP-address - 192.168.0.101 (no DHCP)
Subnetmask - 255.255.255.0
Standardgateway - 192.168.0.1

[edit] Checking Trace-Route

In this test we are going to try to determine if you can make a connection to the Project Servers.

The most important thing in this test are the asterisks ("*") on the end line which mean that the machine doesn't answer. So there must be a network problem at Berkeley or the machine is off-line or is failing to respond due to other reasons.

Solution: Look at the Server Status page (for SETI@Home: Status). If there is something red or orange, wait until it is green again and then retry. If not, keep watching it from time to time. Actually you can't do anything on your own...

[edit] Trace-Route Apple OS-X

The command is traceroute and will be entered into a terminal session.

• Open the "Utilities" folder
• Double click on the "Terminal" icon.
• In the terminal window that opens, type (or select the text and copy paste it into the window):

Project	Command
Climateprediction.net	traceroute
BURP	traceroute
Einstein@Home	traceroute
The Lattice Project	traceroute
LHC@Home	traceroute
Predictor@Home	traceroute
SETI@Home	traceroute setiweb.ssl.berkeley.edu

When that command completes you should see an output like the following:

G5a:~ paulbuck$ traceroute setiweb.ssl.berkeley.edu
traceroute to klaatu.ssl.berkeley.edu (128.32.18.152), 64 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  1.811 ms  0.448 ms  0.425 ms
 2  12.244.16.145 (12.244.16.145)  10.070 ms  10.321 ms  11.848 ms
 3  12.244.69.185 (12.244.69.185)  27.848 ms  9.718 ms  7.921 ms
 4  12.127.32.85 (12.127.32.85)  50.887 ms  16.581 ms  28.110 ms
 5  tbr2-p013701.sffca.ip.att.net (12.123.13.177)  14.888 ms  17.656 ms  18.087 ms
 6  12.122.80.57 (12.122.80.57)  14.499 ms  31.840 ms  16.169 ms
 7  so-8-1.car3.sanjose1.level3.net (209.0.227.29)  18.117 ms  32.643 ms  17.176 ms
 8  ge-8-1.hsa1.sanjose1.level3.net (4.68.123.72)  17.038 ms  15.014 ms  16.128 ms
 9  cenic.hsa1.level3.net (209.247.159.110)  19.356 ms  19.280 ms  19.621 ms
10  inet-ucb--svl-isp.cenic.net (137.164.24.106)  25.071 ms  19.026 ms  22.242 ms
11  vlan193.inr-201-eva.berkeley.edu (128.32.0.74)  34.683 ms  22.937 ms  23.445 ms
12  g1-1.inr-230-spr.berkeley.edu (128.32.255.110)  19.041 ms  20.653 ms  20.926 ms

or, if it fails:

G5a:~ paulbuck$ traceroute setiweb.ssl.berkeley.edu
traceroute to klaatu.ssl.berkeley.edu (128.32.18.152), 64 hops max, 40 byte packets
 1  192.168.1.1 (192.168.1.1)  0.915 ms  0.444 ms  0.423 ms
 2  12.244.16.145 (12.244.16.145)  10.965 ms  42.233 ms  8.325 ms
 3  12.244.69.185 (12.244.69.185)  8.338 ms  10.823 ms  7.817 ms
 4  12.127.32.85 (12.127.32.85)  12.895 ms  17.438 ms  15.077 ms
 5  tbr1-p012301.sffca.ip.att.net (12.123.13.173)  25.495 ms  15.571 ms  16.703 ms
 6  12.122.80.66 (12.122.80.66)  41.204 ms  24.241 ms  213.890 ms
 7  att-gw.sea.level3.net (192.205.32.206)  14.918 ms  15.674 ms  16.017 ms
 8  ge-8-1.hsa1.sanjose1.level3.net (4.68.123.72)  16.894 ms  17.018 ms  15.112 ms
 9  cenic.hsa1.level3.net (209.247.159.110)  18.593 ms  20.221 ms  19.422 ms
10  inet-ucb--svl-isp.cenic.net (137.164.24.106)  21.033 ms  21.918 ms  19.888 ms
11  vlan193.inr-201-eva.berkeley.edu (128.32.0.74)  20.068 ms  19.973 ms  19.350 ms
12  g1-1.inr-230-spr.berkeley.edu (128.32.255.110)  24.740 ms  19.044 ms  20.449 ms
13  * * *
14  * * *
15  * *^C
G5a:~ paulbuck$

Note:

You should kill the program with a CTRL-C when asterisks ("*") begin to appear, as the final stage of the trace-route is failing. This means that the server in the last stage failed to respond.

[edit] Trace-Route/Trace-Path Linux

Depending on the configuration of the installation of Linux, you may have either traceroute or tracepath installed. In some cases you may have neither installed and will have to install the program from the distribution disks.

The command is tracepath (or traceroute) and will be entered into a terminal session.

Project	Command	Alternate Command
Climateprediction.net	tracepath	traceroute
BURP	tracepath	traceroute
Einstein@Home	tracepath	traceroute
The Lattice Project	tracepath	traceroute
LHC@Home	tracepath	traceroute
Predictor@Home	tracepath	traceroute
SETI@Home	tracepath setiweb.ssl.berkeley.edu	traceroute setiweb.ssl.berkeley.edu

bash-2.05b# tracepath setiweb.ssl.berkeley.edu
 1: MegamanX.PuchNetworks (10.1.1.22) 0.165ms pmtu 1492
 1: 10.1.1.254 (10.1.1.254) 0.959ms
 2: inet-qro-corregidora-3-l0.uninet-ide.com.mx (148.235.78.109) 255.030ms
 3: inet-qro-corregidora-1-g5-0-0.uninet.net.mx (148.235.77.222) 67.242ms
 4: inet-gto-aztecas-6-pos2-1.uninet.net.mx (148.223.75.226) asymm 7 134.097ms
 5: bb-jal-ctg-8-pos7-2.uninet.net.mx (200.38.132.22) 129.539ms
 6: sl-gw29-ana-12-3.sprintlink.net (160.81.186.45) 151.723ms
 7: sl-bb25-ana-5-0.sprintlink.net (144.232.1.81) 159.574ms
 8: sl-bb22-ana-11-0.sprintlink.net (144.232.1.141) 155.905ms
 9: 144.232.9.238 (144.232.9.238) 165.500ms
10: bur-core-02.inet.qwest.net (205.171.13.49) asymm 11 157.181ms
11: svl-core-01.inet.qwest.net (205.171.8.242) asymm 16 117.480ms
12: svl-edge-09.inet.qwest.net (205.171.14.94) asymm 16 115.509ms
13: 65.115.65.58 (65.115.65.58) asymm 19 119.669ms
14: dc-svl-isp--sac-isp-t1.cenic.net (137.164.40.217) asymm 18 118.322ms
15: inet-ucb--svl-isp.cenic.net (137.164.24.106) asymm 18 119.655ms
16: vlan193.inr-201-eva.Berkeley.EDU (128.32.0.74) asymm 19 119.688ms
17: g1-1.inr-230-spr.Berkeley.EDU (128.32.255.110) asymm 20 119.955ms

or, if it fails:

prompt:~$ traceroute setiweb.ssl.berkeley.edu
traceroute to klaatu.ssl.berkeley.edu (128.32.18.152), 30 hops max, 38 byte packets
 1 ipcop (192.168.0.254) 0.558 ms 0.415 ms 0.384 ms
 2 217.0.116.146 (217.0.116.146) 56.500 ms 57.714 ms 59.890 ms
 3 217.0.74.26 (217.0.74.26) 55.952 ms 57.427 ms 57.772 ms
 4 k-ea1.K.DE.net.DTAG.DE (62.154.55.158) 57.101 ms 57.890 ms 58.165 ms
 5 nyc-e5.NYC.US.net.DTAG.DE (62.154.14.53) 142.412 ms 144.076 ms 143.045 ms
 6 65.59.192.5 (65.59.192.5) 151.621 ms 152.146 ms 151.182 ms
 7 ae-1-52.bbr2.NewYork1.Level3.net (4.68.97.33) 150.640 ms ae-1-54.bbr2.NewYork1.Level3.net (4.68.97.97) 151.013 ms 152.033 ms
 8 ae-0-0.bbr2.SanJose1.Level3.net (64.159.1.130) 222.329 ms as-0-0.bbr1.SanJose1.Level3.net (64.159.1.133) 222.241 ms ae-0-0.bbr2.SanJose1.Level3.net (64.159.1.130) 225.829 ms
 9 ge-8-2.hsa1.SanJose1.Level3.net (4.68.123.136) 221.804 ms ge-8-0.hsa1.SanJose1.Level3.net (4.68.123.8) 222.257 ms ge-9-0.hsa1.SanJose1.Level3.net (4.68.123.40) 222.487 ms
10 CENIC.hsa1.Level3.net (209.247.159.110) 222.332 ms 222.120 ms 221.911 ms
11 inet-ucb--svl-isp.cenic.net (137.164.24.106) 223.199 ms 223.579 ms 222.387 ms
12 vlan193.inr-201-eva.Berkeley.EDU (128.32.0.74) 223.410 ms 223.216 ms 221.902 ms
13 g1-1.inr-230-spr.Berkeley.EDU (128.32.255.110) 223.456 ms 220.140 ms 222.733 ms
14 * * *

Note:

You should kill the program with a CTRL-C when asterisks ("*") begin to appear, as the final stage of the trace-route is failing. This means that the server in the last stage failed to respond.

[edit] Trace-Route MicroSoft Windows

The command is tracert and will be entered into a terminal session.

• Open the "Start" button
• Click on "Run".
• Type in "cmd"
• In the terminal window that opens, type (or select the text and copy paste it into the window):

Project	Command
Climateprediction.net	tracert
BURP	tracert
Einstein@Home	tracert
The Lattice Project	tracert
LHC@Home	tracert
Predictor@Home	tracert
SETI@Home	tracert setiweb.ssl.berkeley.edu

When that command completes you should see an output like the following:

(Note: For some reason I could not get a successful tracert from my network)

or, if it fails:

Microsoft Windows 2000 [Version 5.00.2195] (C) Copyright 1985-2000 Microsoft Corp.

C:\Documents and Settings\Jim Baize>tracert setiweb.ssl.berkeley.edu

Tracing route to klaatu.ssl.berkeley.edu [128.32.18.152] over a maximum of 30 hops:

 1     1 ms     1 ms     1 ms  192.168.0.1
 2     4 ms     7 ms     3 ms  24-171-84-119.dhcp.vinc.in.charter.com [24.171.84.119]
 3    16 ms    10 ms    11 ms  10.28.128.1
 4    13 ms    14 ms    13 ms  24-171-113-1.mgmt.vinc.in.charter.com [24.171.113.1]
 5     *        *        *     Request timed out.
 6     *        *        *     Request timed out.
 7     *        *        *     Request timed out.
 8  ^C

C:\Documents and Settings\Jim Baize>

Note:

You should kill the program with a CTRL-C when asterisks ("*") begin to appear, as the final stage of the trace-route is failing. This means that the server in the last stage failed to respond.

[edit] "Black Hole" Routers

There are cases where a router along the path between the BOINC Client Software and the Project's Servers can cause connectivity problems. The best suggestion we have is to try the Microsoft Knowledge Base article How to Troubleshoot Black Hole Router Issues for a solution.

[edit] Checking Firewall Settings

[edit] Firewall Settings for Microsoft Windows®

• The BOINC Manager (BoincMgr.exe) needs to be able to open outbound connections to either port 1043 or 31416.

• The BOINC Screensaver (Boinc.scr) needs to be able to open outbound connections to either 1043 or 31416.

• The BOINC Daemon (Boinc.exe) needs to open an inbound connection to either port 1043 or 31416, and an outbound connection to port 80 for downloads and uploads of Work Units, Results, and Science Applications, and an outbound connection on port 443 during the attach process to a BOINC Powered Project. Some projects in the future may also use port 443 for all communications (secure SSH).

If you use the boinccmd program, it should have the same access needs as the BOINC Manager (BoincMgr.exe).

[edit] Firewall Settings for Apple OS-X

[edit] Firewall Settings for Linux

For some distributions the standard configuration should work as follows:

Distribution	Changes Needed?
SuSe	No Changes
Debian	No Changes
ipcop	No Changes

Before we start, one very important thing, if you configure (or mor importantly mis-configure) your firewall, you must be VERY careful! If you do something wrong you will have rendered your firewall useless!

Linux most often uses iptables for firewall services.

If you see anything containing DROP or REJECTED and adresses of the Project's Servers {please add the important ones here, SINCE I DON'T use Linux, I have no idea what we need to put} in your firewall log (the logs are stored most often in the directories: /var/log/messages or /var/log/syslog) your problem is most likely the firewall..

To see all firewall rules, type

iptables -L

If you find anything like:

ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- anywhere anywhere state NEW

in a chain called something like "FORWARD" (if your firewall is not the computer, the BOINC Client Software runs on) or a chain called something like "OUTPUT" (if your firewall runs on the same computer as BOINC Client Software, then everything SHOULD be fine.

If it still does not work, try (WARNING: This disables your firewall completely!)

iptables -F

If BOINC Client Software gets connection after executing this command, you should try to find out, how your firewall is configured. SuSe Linux has a configuration tool using yast, other distributions might have something similar.

Also you can try reading Quick HOWTO : Ch14 : Linux Firewalls Using iptables , if you understand it, you can configure your firewall yourself.

What you actually need is the following:

Allow incoming packets from the Project's Servers to pass through to your computer, if they are of the state RELATED or ESTABLISHED, allow outgoing packets from your computer to pass through to the Project's Servers, if they are of the state NEW, RELATED or ESTABLISHED,

Since the configuration can be very complex (e.g. there are huge differences between the configuration of an gateway firewall and a firewall on your computer) it is hard to get it pinned down here.

[edit] Inability To Connect To Project Servers – Some Or All Of The Update, Upload, or Download Actions Result in Error Code 500

A problem that has emerged in all projects has been the “error 500” message. This error is not actually representing just one problem. Rather it is a set of problems that have been reported with a single error code. In recent versions the message text has emerged as “http error” or “error -182” in addition to “error 500”. This set of messages point to the fact that your system cannot successfully connect to your project. There may be many reasons as described elsewhere but the error 500 set seems to emanate from at least the following:

• HTTP protocol errors arising out of BOINC Software coding.
• Long transaction times brought about by slow responses (sometimes distance related) across the Internet or slow responses from a project’s servers.
• Inability by some part of the Internet (including your own router) to pass date properly

[edit] Things That Can Be Done To Overcome Problems

Firstly it is always worth making sure you have the latest stable release of the BOINC Client Software. Errors in this area may be caused by a bug which is now largely corrected.

Microsoft Windows® users should run the automated test - other users will need to carry out the equivalent individual tests. This test will provide needed information on the state of your connection. The log file produced will help you understand what may or may not be happening. In respect of the “error 500” type problems check carefully in the log that the reply from pinging looking for black holes does indeed get a “Reply from” set of messages - if not then the following may be a fix for you:

First a layman’s explanation.

When Microsoft Windows® sends data it, by default, says take this chunk of data and get it to the server and do not break it up into smaller fragments on the way. Now on the way to the server there may be a device that cannot handle the chunk as big as it is and therefore drops the data as it cannot process it. Often this device will signal back to say send smaller chunks but this message is itself sometimes dropped and never gets back to Windows. In any event Microsoft Windows® is resolute and would say no. So we end up with a broken path that will not handle the data.

So what can be done – what are the options?

• You could choose to use a proxy that has a path to the server that does not fragment the chunks of data. Choose one close to your project servers and work back towards your own location until you find something that works for you. This is known to be a fix for some people and is quite straight forward to do.
• You could reduce the size of those data chunks to be as small as the smallest that can be handled over the route to the Project Servers.
• You could enable fragmentation and let the chunk you send be broken up and reassembled later.

OPTION 1:

You can find proxies by searching the web. Try some and see how you get on. This can work for some.

OPTION 2:

Essentially you need to ping the servers with small chunks of data and progressively increase the size until one fails. The last one to succeed is likely the one that will help you. Do not spend hours doing this using increments of one by the way. Start with 548 and then try 1472.

Ping setiboincdata.ssl.berkeley.edu –f –l 548

This should succeed and you get a “Reply from” message. If it does not then you have other connectivity issues that are not related to the error 500 set.

Now try

Ping setiboincdata.ssl.berkeley.edu –f –l 1472

This also may well fail.

Now try something in between those two numbers. The larger the number the better when it comes to efficiency so move up in increments of say 100 towards 1472.

Once you find the last value that works then this is the value needed to set your data chunk size. The proper name for the data chunk size is MTU by the way. You can use Dr TCP to make a change to your Windows settings. You can get this software from “here”.

OR

If you do not want to use Dr TCP you can also edit the registry. Great care must be taken when editing registry settings as getting wrong can be difficult to track down and fix. Always back up the registry before you start.

The method for this is taken from Microsoft’s web site:

1. Right-Click "Start", and then click "Control Panel".
2. Double-click "Network and Internet Connections", and then click to open the "Network Connections" folder.
3. If more than one network connection is listed, for each connection, double-click the connection and then click the "Support" tab of the Status interface that opens. The connection that shows a "Default Gateway" entry is probably the network connection that is used to connect to the Internet. Note the name of the connection (for example, "Local Area Connection 2").
4. Start Registry Editor (Regedit.exe).
5. Under the HKEY_LOCAL_MACHINE tree, go to the following key:
   SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}\
   Under that key are one or more keys that have numeric identifiers. Each of these keys has a Connection subkey. Examine each of the keys that look like this:
   D_for_Adapter\Connection
   The "Name" value in the "Connection" subkey provides the network connection name that is used in the "Network Connections" folder. When you find the one that matches the name that you found in step 3, make a note of the ID_for_Adapter that the network connection name is under.
6. Return to HKEY_LOCAL_MACHINE, and then locate the following key
   SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ID_for_Adapter
   where ID_for_Adapter is the number that you noted in step 6. When you highlight this key, several values appear on the right side of the screen, including DefaultGateway and EnableDHCP.
7. Right-click the right side of the screen, click New, and then click DWORD Value. Name the value MTU.
8. Double-click the value so that you can edit the value, change Base to Decimal, and then enter the largest acceptable MTU Size, which is the size that you identified by using the Ping tests.
9. Quit Registry Editor.

OPTION 3:

You can change your registry settings to allow fragmentation to take place. This can help but does not work for everyone. Great care must be taken when editing registry settings as getting wrong can be difficult to track down and fix. Always back up the registry before you start.

The method for this is taken from Microsoft’s web site:

Enable PMTU Black Hole Detection on the Windows-based hosts that will be communicating over a WAN connection. Follow these steps:

1. Start Registry Editor (Regedit.exe).
2. Locate the following key in the registry:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\tcpip\parameters
3. On the "Edit" menu, click "Add Value", and then add the following registry value:
   Value Name: EnablePMTUBHDetect
   Data Type: REG_DWORD
   Value: 1
4. Quit Registry Editor, and then restart the computer.

This will cause Windows not to demand that data is not fragmented. It may help.

In respect of options 2 and 3 it must be said, though, that it can make all your activities to and from other networks less efficient. More and smaller packets carry higher overheads which is a position most try and avoid. But then again if its the only way it can work for you then perhaps it has to be. It is not possible to say just how much extra traffic will be generated as MTU sizes will vary for different users potentially.

[edit] It still does not work?

Go back and check the list at the beginning on things to look out for. Make sure you have covered these off and things are working properly.

Run the Windows automatic script to test your connection again.

If all that still fails to fix the problem it may be time to take a trace and pass it to someone to look at.

• Download and install the product called Ethereal. It is free and safe to use.
• Start Ethereal. You should see a screen like this:
• Click the button with the caption “show the capture options”

You now select your interface card and set up the options thta you want. It suggested that you:

• Select the interface card you want to trace.
• Check Update list of packets in real time
• Check Automatic scrolling in live capture
• Check all 3 of the name resolution boxes at the botom right
• In the "Capture Filter" box enter "port 80 or port 8080" (without the quotes), port 80 is for regular web traffic (rather than capturing everything, you only need to capture web traffic) and 8080 is a common port used by proxy servers, if your proxy server uses a different port, replace 8080 with the port your proxy server uses. This information can usually be found in your browser, if not, ask your system/network administrator for the details.

Note: that your network card is unlikely to have the same name as the one shown so click and select yours from the drop down list. This shows you all the network cards, dial-up adaptors, tunnel drivers etc you have on your PC. If you have more than one card make sure you select the card used to access the Internet (you can select the default for Ethereal to use in the Preferences). Also note that you can run Ethereal on a gateway that you may have in use. For instance there is a *nix version too and you may care to download that and install it on your gateway and trace the traffic between your PC running the BOINC Client Software and the servers from there.
Now click “start” button and Ethereal will start capturing data.

Now Ethereal is running we need to collect some meaningful data so we cause Boinc activity to happen.

• Go to BOINC Manager or BoincView or whatever you are using.
• Cause your project to update or try and send your results up to the server.
• After you have got a failure shown in your log then go back to Ethereal and click stop button as shown on the right.

Try not to let Ethereal run for too long as the size of the capture file (containing the captured data) can quickly grow quite large, however it isn't critical, you're not going to run out of disk space in the space of a few minutes, especially if you use the suggested capture filter above to limit the capture to only web traffic. Equally be sure you have seen the update/up/down load takes place as its important to capture the whole transaction for it to be of use.

Now you need to save what has been captured to a file.

• Choose “file” and “save as” and you will see something like that on the right.
• Make sure all packets is checked
• Make sure the captured buttn is pressed and selected
• Select a save location folder
• Enter a suitable file name
• Click save.

Note this will save all traffic at the time of the trace across your network card. If you do not want to share all of the traffic in the trace then you must filter it before saving.

Now send this saved file to john_brown_gordon at ntlworld.com. An assessment will be made as soon as possible and results fed back to you..