I will try and post lines of the log individually

Since you are struggling to post here, but your BOINC client can communicate with climateprediction.net, are you able to post the log files to their BOINC message boards: climateprediction.net Questions and answers?

OP’s location: United Kingdom

Working:
climateprediction.net Oxford University, UK
WCG ?

Not working:
Einstein U. of Wisconsin - Milwaukee, USA
SETI University of California, Berkeley, USA
Rosetta University of Washington, USA
Predictor The University of Michigan, USA
Cosmology University of Illinois, USA

LHC University of London, UK But their url is STILL “ch”, which is Switzerland

Is it just me, or can anyone else see a pattern here?

How does your ISP connect to “outside the UK”? Via a squid proxy?
See this thread

I looked at the thread referred to and ran myIP through the suggested website, which says there is no proxy... But my symptoms are exactly those mentioned. I've changed the config to http1.0, I'm currently running on 5.10.39....

There is one "niggling" issue here, and that is there were fairly extensive internet probs in southren UK on Friday, but my prob happened days before that and was just seti and rosetta failing to update hwere they had done fine for years before.

---

Larry Botheras

Is it just me, or can anyone else see a pattern here?

Agreed, I saw the same pattern, with one more possibility. I think WCG uses https, which is less prone to being intercepted. Alas, I don't think this holds true for CPDN, but it's saving grace may well be that it's local (or an ac.uk), as you pointed out.

Now I'm thinking about a possible faulty/misconfigured router at ISP level, or something else doing faulty packet inspection...

This will likely spin things off topic, and deserves its own thread, but it may be pertinent to this situation, so:
I may be mistaken, but aren't UK ISP's (globally even) now taking a lot of flak about being responsible for content traversing their networks? Could some covert experimentation be taking place here?

I looked at the thread referred to and ran myIP through the suggested website, which says there is no proxy... But my symptoms are exactly those mentioned.

I recall another site that offers a more indepth check to find well hidden proxies. I'll update this when I relocate the url. There were a few steps to follow, but nothing overly complicated.
[edit]
Url is http://www.lagado.com/tools and options are proxy test and cache test.
[/edit]

I've changed the config to http1.0, I'm currently running on 5.10.39....

I noticed, but sadly it doesn't seem to be helping. Sorry about that. :(

There is one "niggling" issue here, and that is there were fairly extensive internet probs in southren UK on Friday, but my prob happened days before that and was just seti and rosetta failing to update hwere they had done fine for years before.

Sure seems to be destination (or protocol) dependent. Did you try posting a chunk of data to the CPDN message boards?

I give up. It appears to be hardwired machine based. Neither wired PC on our home net work, (XP and VIsta) and both wireless laptops do...

Bugger

I give up.

Every time I read/hear that, I remember the fax that circulated in the 80's of the sketch of the frog in the stork's mouth with its hands clasped tightly around the stork's throat, preventing the bird from swallowing. Tagline: "Never give up!!"

It appears to be hardwired machine based. Neither wired PC on our home net work, (XP and VIsta) and both wireless laptops do...

So wired fails, but wireless works. That's progress.
Obvious question is if you have a wired connection on the wireless laptop, what happens when you plug it in and disable the wireless?
Second thing is to determine the MTU size on both wired and wireless computers and if they are different, set the wired one to match the wireless one and observe the results.

Bugger

Only as a last resort. :)

Can he get to the SETI home page from the affected computer(s) http://setiathome.berkeley.edu/index.php?

IF he can not, it could possibly be related to an ongoing peering dispute between Cogent and Global Crossing (two of the largest internet backbones that serve as connect points between various countries ISP's).

Another thing to try is using the tracert command to the affected projects server from a command line on the affected machines to see if it's related the above mentioned problem or something in his local network/router configuration.

On a Windows PC press the Windows Key and the R key at the same time to get the run box.
In the run box, type cmd to get a command window.

Then type type the following in the cmd box:
tracert setiathome.berkeley.edu

Otherwise the output disappears before you get a chance to read it.

If the tracert command stops at 64.209.102.222 or anything other than the project server then the problem lies ar the failed tracert.
The last line of the successful tracert should be: thinman.ssl.berkeley.edu [128.32.18.150]

---

Well, it appeares that our Belkin 54G router was at fault... It gave strange behaviour with wired connections (I now remember that I'd had to move connections from port to port). I installed a new Linksys router, and have gone back to BOINC tonight, and... Everything is working. Main difference is being able to hard code DNS servers as opposed to relying on ISP default gateway.

Thanks for all your help guys. LHC@home still seems screwed [Edit-the service is up but out of work] , but seti, rosetta and all therest are back up for me... which makes it a full house....

---

Larry Botheras