Weird, I was running BOINC fine since about July then all of a sudden I couldn't connect anymore. Kept getting the "master file fetch failed" message. Couldn't even maintain a good connection to the web site. I'm running WinProxy NAT/Proxy software on my routers. Usually I use it as a straight NAT connection which was working fine for months. After fighting this issue for weeks I finally decided to channel everything through the HTTP proxy. Now everything works fine, including the website.

I'm confused... what changed?

Did your proxy software have a recent upgrade? This is what I am suspecting happened.

---

My movie https://vimeo.com/manage/videos/502242

Only if somebody broke into my apartment and upgraded it. A cable modem was changed out, but that's not when the problem started. I just checked a couple of other computers, one linux box and one XP. They were also stuck, but a simple "update" fixed them. I didn't have to switch to the proxy. On three other computers the proxy was needed to make the initial connection, but now I discover I can turn it off and they continue to connect. I'm more confused than ever now. I think I'll just relegate this to the "whatever" file.

Same here. I have a DSL connection through a NAT/Router/Firewall. Initially BOINC was able to connect normally through my LAN, then, one day, for no apparent reason it got stuck. No U/D or even connection to the project, even though the servers were up and running.

I was almost giving up when I found the proxy solution in one of these threads, and I've been using one ever since. But even the proxies presented some problems: at times, they worked fine for 2 or 3 days, then no connections again and I was forced to change to another proxy, but now I believe I found a "stable" one, even though it bottlenecks a great deal of my bandwidth, slowing down all U/D.

I had another machine connected to the project and it worked just fine w/o the need of a proxy. It used a similar DSL connection, from the same vendor and ISP, just a little slower.

I also gave up trying to make sense of it, but I welcome any thoughs about it.

Regards,
Wander

---

A fellow cruncher here and a VERY big helper was dealing with some other users in this same state. Works with proxy but not direct and sometimes not with proxy's. Users had DSL ISP's etc....

User's name is MMCIASTRO and you can look through all his posts here .

They were dealing with the MTU size and making some changes to the size do to some isp's fragmenting it. They WERE successful in making the changes to work. I'm going offline now and can't look for you.

This was all happening a couple of weeks ago.


Good Luck

---

Boinc....Boinc....Boinc....Boinc....

i had the problem with boinc 5.2.x to get downloads over my proxy
uploads and webbrowsing over my proxy working fine but my boincmanager dont want downloading wu's
after reinstalled the old version 4.45 all is working over my proxy upload, download
i wait now for the next update of boincmanager than i try again

maybe u will give the version 4.45 also a chance...it solved my problem

greetings
ralf

---

Boinc runs here on:
Intel i7-3770K + IntelHD4000
Android-Stick-ARM-Cotex-A17
Sony-Z5C-ARM-Cortex-A53/A57
Nvidia GT-630 / Nvidia GTX-750Ti

They were dealing with the MTU size and making some changes to the size do to some isp's fragmenting it. They WERE successful in making the changes to work. I'm going offline now and can't look for you.

I managed to locate the thread you mentioned, but there are over 150 messages posted there. It will take some time to sort it out. From what I gathered so far, it seems that the general conclusion is to reduce MTU size a little (down to 576) and see if it works. If it does, slowly increase it towards its original value.

It seems that reducing MTU size does have a negative impact on performance, a small one though. I'll look into it and I'll let you know, but this will have to wait at least until next year!

I'm off to the holidays as well. Thanks, a happy holidays to you all!!

---

Hi.
If it helps you will find proxy info here. http://www.iantighe.com/boincers.htm

---

Hi,

Well, although I'm a pretty decent software engineer, networking and protocols were never my strongest suit, so I took me awhile to go through all that was discussed in that MTU thread and some other material, particularly an article from Microsoft referenced by DSLReports that explains in detail the network connection problems associated with MTU size, and the so called "Black Hole routers", which are preventing some of us to connect BOINC directly, forcing the use of a public proxy.

The solution discussed in the thread mentioned above is also discussed in the article, but other articles pointed out that there are potential performance problems in simply reducing the MTU size to accomodate only one problematic route in the net.

Instead, I tryed the "Method 1" described in the article, which enables the Path Maximum Transfer Unit Black Hole Detection so TCP itself will try to find the optimum packet size for a given connection. By activating this feature "(...) TCP will try to send segments that do not have the Don't Fragment bit set. TCP will try to send these segments if several retransmissions of a segment go unacknowledged. If a segment is acknowledged, the maximum segment size (MSS) will be reduced and the Don't Fragment bit will be set in future packets on the connection."

I'm glad to report that now my machine is able to connect BOINC directly, w/o the need of a proxy. I tested all the common activities in BOINC: download, upload, contacting schedulers, project attachment and they all worked perfectly, and the U/D throughput returned to the levels they used to be before I started using the proxy.

Using the tools provided at DSLReports, I was able to verify that the performance of my connection remained pratically unchanged, so other activities like web, email, etc, remained unchanged.

Anyway, I'm keeping the IP address of the proxy I've been using safe in my notes, just in case... :-)

Thanks everybody for all the tips.

Regards,
Wander

---

Looks like Wander Saito has finally located the problem that has been plagueing many Boinc/Seti users for a long time. Better yet he has found the real solution for the problem. A big thanks to Wander Saito for this. Must have taken a great deal of time to put this all together.

Hopefully Paul Buck and mmciastro will see this and it makes it into the WIKI. A reference to the Microsoft Article should certainly be there!

Thanks again Mr. Saito! (I hope that's right)
Good Job!!

---

Boinc....Boinc....Boinc....Boinc....

Added to the Troubleshooting Network Problems "How-To" Guide. Not sure if that guide is as good as it can get still. But, maybe one of the network guys can look at it and suggest changes/additions ...

I see: "This page has been accessed 3,853 times"; so I guess some people are looking at it ... :)

---

Thanks guys. I'm really flattered, but all I did was gather the information so I could reach a conclusion about this problem. And I only did it because it was bugging me so much, like that itchy spot you just can't reach, you know? :-)

I hope this helps fellow users out there and I'm glad to contribute to the Boinc community. Thanks everybody for pointing me the right direction.

Cheers!

---

so here a other question
i have some pc's behind my proxy server
but i can run only the boinc version 4.45. if i use the version 5.2.12 or 5.2.13 i can only update but not download i get all time the error 500
with version 4.45 is all ok
the settings is in each versions the same
what is the difference about the upload in version 5.2.x to version 4.45?
have anyone a idea? it can not be my proxy because than the versin 4.45 also not work but it do
i tried the version 5.3.3 also with same result..update work but the download for new wu's not--> error 500
if i tried the other versions i installed every time in a new folder
greetings
ralf

---

Boinc runs here on:
Intel i7-3770K + IntelHD4000
Android-Stick-ARM-Cotex-A17
Sony-Z5C-ARM-Cortex-A53/A57
Nvidia GT-630 / Nvidia GTX-750Ti

Hi Ralf,

I only used v445 for a few weeks before upgrading to 5.2.x, and back then I haven't had the need to use a proxy. Anyway, I and several other SETI user began using public proxy servers due to this problem described below, and by the looks of it, you have your own proxy server set up in your LAN.

I can only speculate to the reasons why the order version works and the newer don't. In my experience using these public servers, many of them are blocked to restrict either some types of ativities, protocols or sites. I remember one that explicitly blocked contact to all servers under the Berkeley domain, generating an 500 error.

I used to have a proxy a long time ago, in my old AMD386 DX40 and it never gave me any trouble, working almost transparently in my LAN, with all sorts of apps. Granted, back then I didn't had a DSL line, or even BOINC for that matter, still...

Have you tryed to let the BOINC client detect the net connection on its own, w/o explicitly defining the proxy's address/port in the Options screen?

Sorry. I don't think I'm being of much help to you.

Regards,
Wander

---

Thanks guys. I'm really flattered, but all I did was gather the information so I could reach a conclusion about this problem. And I only did it because it was bugging me so much, like that itchy spot you just can't reach, you know? :-)

Actually, that isn't all you did. If you'd just done that the rest of us would still be puzzled, and what you'd done would be no better someone else filling in a crossword.

We are thanking you because, in addition to understadning it yourself you *also* took extra time to come back and tell us. It takes time to sort out ideas enough to explain them to others - and having sorted them out it takes time to make a posting about them.

When it's useful info that deserves thanks, regardless of why you did it. As does Paul, constantly, for project board hopping and collating all the stuff in one place. We know he enjoys doing it, but that won't stop me saying thanks to him too.

Have a good new year both of you
River~~

---

Its good to see someone get over their connection problems so congrats for that. The changing of MTU sizes is a fix for one of the many problems being seen with connections. Ned was promoting this last summer for some users and there has been some success; including this most recent one. Even though I really wish it were the case it is not the fix for everyone though so some will have to be patient yet and folks like me will have to keep searching. So keep trying the proxies if any one continues to have problems would be my advice.

It is great to see someone come back and explain fully what they did though so well done there!

---

Ned was promoting this last summer for some users and there has been some success; including this most recent one.

I know we're looking at several different problems, and lots of variables.

I'm reasonably convinced that somewhere inside Cogent's network there is a router that blocks all ICMP packets. It's a "black hole" as described in Wander's post.

If it happens to be on your particular path to SETI, you'll have MTU issues.

That's why it works sometimes, and not others -- the problem isn't always MTU.

---

Tigher,
I notice that your ISP is NTL, I'm also on there but have not suffered any of the problems you are seeing.

So is there anything I can do to see where there are differences in our route(s) to Berkeley.

---

Tigher,
I notice that your ISP is NTL, I'm also on there but have not suffered any of the problems you are seeing.

So is there anything I can do to see where there are differences in our route(s) to Berkeley.

Andy
Hey thanks for the kind offer but I don't actually have the problems. I am just trying to track it down and help people that are suffering from it. I am a bit of a go between with the devs right now on this one.

For once I applaud our ISP for having such a good route and good proxies.

---

OK I did an experiment around this 500 problem.

I have saved the boincview logs and the ethereal trace if anyone wants them but they tell this story.

All projects (seti, LHC,CPDN,Einstein) are working fine and updating etc as one would want.

I use linux to route. So I made it a router that had a 576 sized MTU on two of its nics: my side and Internet side.

All still worked OK.

I made sure windows was saying do not fragment.

I turned off pinging on my linux router.

All hells breaks loose.

I get boinc error -182 from LHC. I get http error from Einstein and guess...I get the infamous 500 from seti.

I had just created the router problem we have talked about for some time.

I reset MTU sizes and turned on ping and hey ho it all worked again.

So where does that leave us. As Ned says - combination of bad MTU sizes and not handling ping on someones route and its all over: use a proxy?

---