Actually, (and as far as I know) the reason why wanadoo users cannot connect to Berkeley's servers any more is that Cogent has blacklisted wanadoo ip addresses.

As a wanadoo user, I'm going to send a mail to France Telecom support.
Unfortunately, I'm not sure to have a worthwhile answer in return...

The "blacklisting" is most likely due to the volume of spam from Wanadoo. I'm amazed that Verizon isn't on that list, too.

Back to topic: Would a proxy/mirror alleviate the situation?

---

Well according to Setione using the following works. Setione is an affected user in France btw. He had problems but this has overcome those problems.

For the moment use proxy setting with for exemple 203.215.178.83 on port 8080, it's OK for download and Up WU

Cheers

---

> Would a proxy/mirror alleviate the situation? >
Yes with a proxy it's always good on this morning for Up and down

---

********************
<img src="http://www.boincstats.com/signature/user_132726.gif" border="0">

Success sir!. Well done Setione. Will you post back in the other threads as a number of people have the problem. And we can both bump it throughout the days to make sure new sufferers are aware. Thanks for your help here. My guess is this problem will get worse before it gets better. As classic comes over there could be thousands having problems and just giving up which is really bad news!.

---

This is a pretty strange situation. It won't last for long though - or it will get the two ISPs into trouble.

As mentioned you can use a proxy not on one of the two networks in order to connect to the seti servers trough a third party.

There's not really much else to do about the problem right now.

Agreed. The proxy below works ok - thanks to SetiOne research. But customers, including UC Berkeley, should complain to Cogent and France Telecom as the situation is unacceptable. Whilst there is little jurisdiction wise that can be done they do have a duty to their customers to provide service. They should keep their politics between themselves and not harm/hurt other folk. We only talk about Seti traffic here but other users in the world of commerce, health etc are affected too. They must hammer the desk of the ISPs to make sure this is fixed and apologies given. If this is politically (and I mean commercial politics) motivated they should be thoroughly ashamed of themselves.....it is not in the spirit of the Internet!

---

Out of curiosity, how are ISPs in Europe? Is there any such thing as competition?

If it were Verizon that was blocking (as it usually is the case) I call 'em up and tell them to send the last bill I'll ever pay them and that I shouldda gone with cable when I had the chance. Soon thereafter (usually within 18 hours) the blocking is lifted.

---

> Out of curiosity, how are ISPs in Europe? Is there any such thing as
> competition?
>

Here in the UK there are around a dozen or so big-players, and heaven knows how many others. That said, unless you have cable, British Telecom carries all the local-loop (exchange to subscriber) traffic - but, IMO it works well enough.

---

I figured that any nation that is smart enough to have its telecommunications decisions made the State can't possibly be worse than allowing those same decisions to be made by the chaotic Market for the lowest cost and cheapest quality...

---

Plus d'infos ici (more news here)

pcinpact.com
presence-pc.com

---

********************
<img src="http://www.boincstats.com/signature/user_132726.gif" border="0">

Thanks to SetiOne's proxy server (by the way how do you find such a server?) S@H now works again as it should. Finally a succesfull schedular response.

But still there are some things I don't understand.

1) According to this thread mentioned before by Ned Ludd, Open Transit (France Telecom) just recently depeered Cogent. However the schedular problems we discussed here are already present since about March 15.

2) In my trace route I can't find any machines owned by France telecom. Maybe some of the European Cogent machines are maintained by them, or my knowledge on internet nodes doesn't suffice. I don't know. Anyway these are my trace routes:

Bezig met het traceren van de route naar setiboincdata.ssl.berkeley.edu [66.28.250.125]
via maximaal 30 hops:

1 2020 ms 3 ms 3 ms SpeedTouch.dcdl [10.0.0.138]
2 10 ms 10 ms 10 ms 195.190.249.9
3 11 ms 10 ms 10 ms ge0-1-v61.dsl-rtr1.ams-tc2.io.nl [81.17.32.21]
4 11 ms 11 ms 10 ms if3-4.rtr2.ams-tc2.io.nl [81.17.32.70]
5 11 ms 10 ms 11 ms portch1.core01.ams03.atlas.cogentco.com [195.69.144.124]
6 18 ms 18 ms 18 ms p5-0.core01.lon02.atlas.cogentco.com [130.117.1.225]
7 88 ms 88 ms 88 ms p10-0.core01.bos01.atlas.cogentco.com [130.117.0.46]
8 109 ms 109 ms 108 ms p5-0.core01.ord01.atlas.cogentco.com [66.28.4.110]
9 154 ms 154 ms 155 ms p5-0.core01.sfo01.atlas.cogentco.com [66.28.4.185]
10 156 ms 155 ms 156 ms g0-1.na01.b003123-1.sfo01.atlas.cogentco.com [66.28.6.2]
11 * * * Time-out bij opdracht.

Hop 2, 3 and 4 are Dutch machines I guess, after that European and American Cogent machines.

3) When i try a trace on the website of my network provider (KPN, The Netherlands), over here it for some reason seems to be able to trace the server without any problems. Can anyone explain why? I am connected by them, but my trac routes don't reach S@H. Their traceroute is:

Tracing the route to 66.28.250.125

1 asd-dc2-ias-ar13.nl.kpn.net (194.151.228.97) [AS 286] 4 msec 0 msec 0 msec
2 195.190.232.205 4 msec 4 msec 0 msec
3 195.190.232.206 4 msec 0 msec 4 msec
4 asd-dc2-ias-ur10.nl.kpn.net (195.190.227.7) 0 msec 0 msec 0 msec
5 195.190.233.72 4 msec 4 msec 0 msec
6 195.190.233.75 4 msec 4 msec 0 msec
7 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 4 msec 0 msec 4 msec
8 portch1.core01.ams03.atlas.cogentco.com (195.69.144.124) 8 msec 8 msec 8 msec
9 p5-0.core01.lon02.atlas.cogentco.com (130.117.1.225) [AS 174] 12 msec 8 msec 8 msec
10 p10-0.core01.bos01.atlas.cogentco.com (130.117.0.46) [AS 174] 80 msec 76 msec 76 msec
11 p5-0.core01.ord01.atlas.cogentco.com (66.28.4.110) [AS 174] 100 msec 100 msec 100 msec
12 p5-0.core01.sfo01.atlas.cogentco.com (66.28.4.185) [AS 174] 144 msec 144 msec 144 msec
13 g0-1.na01.b003123-1.sfo01.atlas.cogentco.com (66.28.6.2) [AS 174] 144 msec 144 msec 144 msec
14 UC-Berkeley.demarc.cogentco.com (66.250.4.74) [AS 174] 152 msec 152 msec 152 msec
15 66.28.250.125 [AS 174] 152 msec 152 msec 152 msec


Regards, Dirk

---

> Thanks to SetiOne's proxy server (by the way how do you find such a server?)

for me at this time a proxy it's always necessary for UP and DL
You can find proxy (free proxy) here :
aliveproxy.com
or here (etc)
free-proxy-servers.com

---

********************
<img src="http://www.boincstats.com/signature/user_132726.gif" border="0">

Proxy solution works beautifully here too. Thank YOU SetiOne!

Dirk, from 8 on the second trace route you present exactly matches the
trace route I get when I hook up my laptop to my neighbour's
wireless network (bbnet).

Cheers,
Rob

---

I got an e-mail from Wanadoo that is actually an
answer to my question! They are aware of the problem, tell me
it's the Cogent network that cannot be reached, and that they are
working on it......

For those of you who can read Dutch, the original:

***
Het probleem, zoals u die omschrijft, is inderdaad bij ons bekend. Het betreft sites achter een bepaald netwerk (Cogent Communications). We doen ons best het probleem zo snel mogelijk op te lossen.
***

Cheers,
Rob

> Het probleem, zoals u die omschrijft, is inderdaad bij ons bekend. Het betreft
> sites achter een bepaald netwerk (Cogent Communications). We doen ons best het
> probleem zo snel mogelijk op te lossen.

Na, dan doe maar ;)

---

Gruesse vom Saenger

For questions about Boinc look in the BOINC-Wiki

> Thanks to SetiOne's proxy server (by the way how do you find such a server?)
> S@H now works again as it should. Finally a succesfull schedular response.
>
> But still there are some things I don't understand.
>
> 1) According to <a> href="http://www.merit.edu/mail.archives/nanog/2005-04/msg00484.html">this
> thread[/url] mentioned before by Ned Ludd, Open Transit (France Telecom) just
> recently depeered Cogent. However the schedular problems we discussed <a> href="http://setiweb.ssl.berkeley.edu/forum_thread.php?id=13645">here[/url] are
> already present since about March 15.
>
> 2) In my trace route I can't find any machines owned by France telecom. Maybe
> some of the European Cogent machines are maintained by them, or my knowledge
> on internet nodes doesn't suffice. I don't know. Anyway these are my trace
> routes:
>
> Bezig met het traceren van de route naar setiboincdata.ssl.berkeley.edu

Yes. I think some of these things we will never know. The core routing around the internet is quite complex with many people involved. It may be that some Dutch telco is owned by France Telecom perhaps. Who knows. Anyway....glad the SetiOne solution worked well for you. I am glad we have been able to identify this and get a solution. Well done to all for collecting tracerts, running ether traces etc so we could pin point it. Good team work gentlemen!
> [66.28.250.125]
> via maximaal 30 hops:
>
> 1 2020 ms 3 ms 3 ms SpeedTouch.dcdl [10.0.0.138]
> 2 10 ms 10 ms 10 ms 195.190.249.9
> 3 11 ms 10 ms 10 ms ge0-1-v61.dsl-rtr1.ams-tc2.io.nl
> [81.17.32.21]
> 4 11 ms 11 ms 10 ms if3-4.rtr2.ams-tc2.io.nl [81.17.32.70]
> 5 11 ms 10 ms 11 ms portch1.core01.ams03.atlas.cogentco.com
> [195.69.144.124]
> 6 18 ms 18 ms 18 ms p5-0.core01.lon02.atlas.cogentco.com
> [130.117.1.225]
> 7 88 ms 88 ms 88 ms p10-0.core01.bos01.atlas.cogentco.com
> [130.117.0.46]
> 8 109 ms 109 ms 108 ms p5-0.core01.ord01.atlas.cogentco.com
> [66.28.4.110]
> 9 154 ms 154 ms 155 ms p5-0.core01.sfo01.atlas.cogentco.com
> [66.28.4.185]
> 10 156 ms 155 ms 156 ms g0-1.na01.b003123-1.sfo01.atlas.cogentco.com
> [66.28.6.2]
> 11 * * * Time-out bij opdracht.
>
> Hop 2, 3 and 4 are Dutch machines I guess, after that European and American
> Cogent machines.
>
> 3) When i try a trace on the website of my network provider (KPN, The
> Netherlands), over <a> href="http://www.kpn.net/index.php?page=static.netwerk.start&menu=9">here[/url]
> it for some reason seems to be able to trace the server without any problems.
> Can anyone explain why? I am connected by them, but my trac routes don't reach
> S@H. Their traceroute is:
>
> Tracing the route to 66.28.250.125
>
> 1 asd-dc2-ias-ar13.nl.kpn.net (194.151.228.97) [AS 286] 4 msec 0 msec 0
> msec
> 2 195.190.232.205 4 msec 4 msec 0 msec
> 3 195.190.232.206 4 msec 0 msec 4 msec
> 4 asd-dc2-ias-ur10.nl.kpn.net (195.190.227.7) 0 msec 0 msec 0 msec
> 5 195.190.233.72 4 msec 4 msec 0 msec
> 6 195.190.233.75 4 msec 4 msec 0 msec
> 7 asd-nik-ias-ur10.nl.kpn.net (195.190.227.37) 4 msec 0 msec 4 msec
> 8 portch1.core01.ams03.atlas.cogentco.com (195.69.144.124) 8 msec 8 msec
> 8 msec
> 9 p5-0.core01.lon02.atlas.cogentco.com (130.117.1.225) [AS 174] 12 msec 8
> msec 8 msec
> 10 p10-0.core01.bos01.atlas.cogentco.com (130.117.0.46) [AS 174] 80 msec
> 76 msec 76 msec
> 11 p5-0.core01.ord01.atlas.cogentco.com (66.28.4.110) [AS 174] 100 msec
> 100 msec 100 msec
> 12 p5-0.core01.sfo01.atlas.cogentco.com (66.28.4.185) [AS 174] 144 msec
> 144 msec 144 msec
> 13 g0-1.na01.b003123-1.sfo01.atlas.cogentco.com (66.28.6.2) [AS 174] 144
> msec 144 msec 144 msec
> 14 UC-Berkeley.demarc.cogentco.com (66.250.4.74) [AS 174] 152 msec 152
> msec 152 msec
> 15 66.28.250.125 [AS 174] 152 msec 152 msec 152 msec
>
>
> Regards, Dirk
>
>

---

> Actually, (and as far as I know) the reason why wanadoo users cannot
> connect to Berkeley's servers any more is that Cogent has blacklisted wanadoo
> ip addresses.
>
> As a wanadoo user, I'm going to send a mail to France Telecom support.
> Unfortunately, I'm not sure to have a worthwhile answer in return...
>
> The "blacklisting" is most likely due to the volume of spam from Wanadoo. I'm
> amazed that Verizon isn't on that list, too.

If I'm reading and understanding things correctly, Cogent filters route announcements so that traffic to their peers stays on their own network until it reaches the peering points. That's probably a good thing if their "cheap bandwidth" generates a lot of extra traffic.

For that reason, when OpenTransit stopped peering, they pick up routes headed toward Cogent, but Cogent doesn't have routes back.

It is an attempt by one party to force the policies of the other by fracturing the internet -- and that's ultimately a mistake.

Besides, as someone who buys bandwidth, I checked Cogent pricing, and it isn't that great unless you happen to be in a "lit" building.

---

As I said before this is small 'p' politics. It was for that reason the Internet was never allowed near governments after it took off cos they would screw it up for sure. Whoever screws this up on purpose or dealys fixing a genuiine mistake are themelves making a huge mistake. The Internet is free and open and transparent to all....stuff the party and company politics! That's my view!

---

> If I'm reading and understanding things correctly, Cogent filters route
> announcements so that traffic to their peers stays on their own network until
> it reaches the peering points. That's probably a good thing if their "cheap
> bandwidth" generates a lot of extra traffic.

Translated by Google: news from France concerning F@H and Wanadoo/Coogent:
Quote:
Problem Wanadoo/Cogent
The folding@home Project

Faithful reader of Presence PC, you are not without knowing the scientific project of calculation divided folding@home. It is about research the PUBLIC project of the university of Stanford which developed a method to include/understand how the proteins "yield", the fine whole to better include/understand and treat many diseases, like that of Creutzfeld-Jakob, of Alzheimer, or cancer.

Presence PC chose to take part in this project for many reasons that we announce to you in this topicality. You are besides numerous to have joined the team, which has taken part in the project for two years, and we thank you .

Problems of connection

It seems that for a few days, the users of Wanadoo (and for the professionals, Oleane) have known problems of navigation. The problem is serious for the French-speaking Alliance (of which we form part), which has taken part in the project for more than three years (cf this topicality )! Indeed, the operator does not allow any more the reception of the scientific computations to carry out and the sending of their result towards the waiters of professor Vijay Pande, in Stanford. According to our JWhy fellow-member, large stimulating of the project in France: "this loss of calculated data starts to cost the team and the project".

An email of professor Pande, who makes any possible sound of dimensioned sound, states clearly that: '' the problem seems to be due to the supplier of principal access of Stanford: Cogent . If all occurs well they will examine the problem quickly ' '. It should be recalled that Cogent is an operator at low cost whose network is of very average quality. This incident shows it besides well.

Cogent did not comply with the rules


Alas, it seems that the relations between France Telecom and Cogent are not with beautiful fixed and this problem is perhaps not only one simple technical nuisance: France Telecom cut the peering with Cogent because this one did not respect 2 criteria of the policy of peering of France Telecom, which official and is published . On a traditional network, another road towards the waiters of folding@home could have been found, but in the case of Cogent, that could not be done.

Certain sources indicate that, following this decision of France Telecom to be more inter-connected directly with Cogent, this last would have completely blocked the visits coming from IP addresses pertaining to users of France Telecom! And indeed, according to France Telecom: "By retaliatory measure, Cogent established a well of traffic for the France Telecom addresses, cutting the roads between their monohomés customers and those of France Telecom. This measurement is in rupture with the commonly allowed rules in community Internet. France Telecom cannot be responsible opposite its customers for the consequences the action taken by Cogent which in door only the responsibility " .

The with dimensions one of Cogent, one shows France Telecom. Let us hope that the situation does not go envenimer.

Consequently of what, in waiting of a happy end to this sad history, the plieurs of French-speaking Alliance are setting up a structure to circumvent this blocking.
End quote

Wow!. I think Google need to work very hard on its translation software. The upshot may well be that UC Berkeley should consider a new ISP perhaps?

---