> 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!

Sorry, Ian.

The internet was developed by the U.S. Department of Defense. It started solely as a way to keep communications going after a nuclear attack.

... and while the relevant department has changed a couple of times, the U.S. Government is still involved in a number of different ways.

The most significant part: ICANN, the not-for-profit Internet Corporation for Assigned Names and Numbers gets their mandate from a contract with the U.S. Department of Commerce.

If the government thinks that ICANN is not working, they can pull the contract.

Granted, everyone is trying to do the right thing, worldwide, and it is in general working -- but let there be no question that Government involvement continues.

---

Uh, whut?

> 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
>

---

> 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......

This makes sense if the problem is really a routing-snarl caused by how Cogent filters BGP route announcements.

Packets appear to be going in to Cogent, but Cogent is trying to return them through the (now down) peer.

Routing on the 'net is usually not symmetrical.

---

True and I stand corrected. But should the Internet community divorce itself from them then all would still be fine. There is no active political part by the US Govt in the Internet though. There was when it was considered to be technology not to be shared but their extraterritorial legislative rules are long since gone. I am saying this thing is fine as an amorphus mass which is self regulated by no one but should players get political with a small 'p' they will be ousted and replaced by one of many willing players.

---

> > 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......
>
> This makes sense if the problem is really a routing-snarl caused by how Cogent
> filters BGP route announcements.
>
> Packets appear to be going in to Cogent, but Cogent is trying to return them
> through the (now down) peer.
>
> Routing on the 'net is usually not symmetrical.
>

Well I have no experience of EBGP and only limted knowledge of IBGP. I think this is more a screw up than a plot to thwart folks.

---

According a French website these configurations of proxy and port should work:

195.229.240.86 PORT : 80
82.101.132.51 PORT : 8080
62.193.231.243 PORT : 8080
195.229.240.86 PORT : 80
193.188.96.19 PORT : 80
193.188.96.138 PORT : 80
217.17.233.181 PORT : 80
66.160.69.101 PORT : 80
202.56.253.183 PORT : 8080

in order to connect from Wanadoo to Cogent.

>
> Packets appear to be going in to Cogent, but Cogent is trying to return them
> through the (now down) peer.
>
> Routing on the 'net is usually not symmetrical.
>

This would maybe explain why I can trace S@H on the website from my network provider. It maybe only checking the link from KPN, NL to Cogent, USA. If I try trace route at home it's maybe waiting for a response from the remote machines. If Cogent routes the response via the down peer that won't work...

I also tried a trace from Cogent, USA and from KPN, NL to my pc. The trace in both cases reaches the last node before my Pc's DSL modem. The reason it can't reach my DSL modem is probably due to my firewall. This actually means that Cogent is able to trace me (provided I disable the firewall in my DSL modem). There however doesn't seem to be any France Telecom machines involved. Trace to my pc from Cogent router, Washington, DC:

1 f29.ba01.b005944-0.dca01.atlas.cogentco.com (66.250.56.189) 0 msec 0 msec 0 msec
2 g2-1.core02.dca01.atlas.cogentco.com (66.28.67.225) 4 msec 4 msec 4 msec
3 p6-0.core01.jfk02.atlas.cogentco.com (66.28.4.82) 12 msec 8 msec 8 msec
4 p5-0.core01.bos01.atlas.cogentco.com (66.28.4.117) 80 msec 216 msec 208 msec
5 p3-0.core01.lon02.atlas.cogentco.com (130.117.0.45) 84 msec 84 msec 84 msec
6 p15-0.core01.ams03.atlas.cogentco.com (130.117.1.226) 92 msec 88 msec 88 msec
7 217.71.101.142 92 msec 92 msec 92 msec
8 ge0-2.dsl-rtr1.ams-tc2.io.nl (81.17.32.69) 92 msec 88 msec 88 msec
9 v61.dsl-kpn-rtr.ams-tc2.io.nl (81.17.32.22) 88 msec 92 msec 92 msec
10 195.190.249.9 88 msec 92 msec 92 msec
11 * * *

Hop 11 would actually be my modem.

Regards

---

> This would maybe explain why I can trace S@H on the website from my network
> provider. It maybe only checking the link from KPN, NL to Cogent, USA. If I
> try trace route at home it's maybe waiting for a response from the remote
> machines. If Cogent routes the response via the down peer that won't work...

setiweb.ssl.berkeley.edu appears to use Berkeley's connection to the net.

setiboincdata.ssl.berkeley.edu goes through Cogent.

---

Thierry,

Your proxy settings helped me to get my Seti Classics going.

I'll try the same on Boinc. However, how do I add a proxy server to boinc? There must be an XML file but which one and what is the format? Do you know?

I live in the south of France and this has been down for a week. I'm trying to get boinc up and running for my father's birthday (he actually owns the accounts).

Thanks again,
Michael

---

> Thierry,
> Your proxy settings helped me to get my Seti Classics going.
> I'll try the same on Boinc. However, how do I add a proxy server to boinc?
> There must be an XML file but which one and what is the format? Do you know?
> I live in the south of France and this has been down for a week. I'm trying
> to get boinc up and running for my father's birthday (he actually owns the
> accounts).

Not sure the IP
82.101.132.51 with 8080 port
is working. I tried it from here in Belgium and couldn't access Berkeley. The others seems to be OK.

> Thierry,
>
> Your proxy settings helped me to get my Seti Classics going.
>
> I'll try the same on Boinc. However, how do I add a proxy server to boinc?
> There must be an XML file but which one and what is the format? Do you know?
>
> I live in the south of France and this has been down for a week. I'm trying
> to get boinc up and running for my father's birthday (he actually owns the
> accounts).
>
> Thanks again,
> Michael
>
J'ai écrit hier 16/04 cette solution dans ce sujet/ I have write yesterday 16/04 on this thread :

"Pour l'instant utilisez un proxy (paramètres dans Options) et indiquez par "exemple 203.215.178.83 port 8080 et ç'est bon pour recevoir et envoyer des WU

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

Ce n'est qu'un exemple de proxy j'en ai indiqué d'autres aussi mais il te suffit donc dans BOINC d'aller dans outil/Option et d'indiquer les coordonnées xxx.xxx.xxx.xxx dans la rubrique "adresse" et xxxx dans la rubrique "port" et OK

---

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

Is it not just great when a good workaround comes about.

---

Make you wanna hug your CPU, doesn't it?

I love it when technology works!

---

Sure does. I love it when it goes wrong...nice challenge to fix it lol.

---

> According a French
> website these configurations of proxy and port should work:
>
> 195.229.240.86 PORT : 80
> 82.101.132.51 PORT : 8080
> 62.193.231.243 PORT : 8080
> 195.229.240.86 PORT : 80
> 193.188.96.19 PORT : 80
> 193.188.96.138 PORT : 80
> 217.17.233.181 PORT : 80
> 66.160.69.101 PORT : 80
> 202.56.253.183 PORT : 8080
>
> in order to connect from Wanadoo to Cogent.
>
>
Hey good news and well discovered. Thx from Europe.

---

> Thierry,
>
> Your proxy settings helped me to get my Seti Classics going.
>
> I'll try the same on Boinc. However, how do I add a proxy server to boinc?
> There must be an XML file but which one and what is the format? Do you know?
>
> I live in the south of France and this has been down for a week. I'm trying
> to get boinc up and running for my father's birthday (he actually owns the
> accounts).
>
> Thanks again,
> Michael
>
>
>

Boinc manager/ Tools/ Options/ HTTP Proxy tab.

---

Just thought I'd check this out from the UK. I'm on the South Coast (Portsmouth)and was worried I might route through France. This might happen occassionally and might explain some erratic problems in connections. I'll run tracert when it happens and see if this is the cause.


C:\>tracert setiboinc.ssl.berkeley.edu

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

1 74 ms 142 ms 22 ms rasd3nrp2.ilford.broadband.bt.net [213.120.157.168]
2 86 ms 81 ms 93 ms rasd3nrp5.ilford.broadband.bt.net [213.120.157.180]
3 23 ms 22 ms 22 ms 81.146.245.94
4 27 ms 46 ms 22 ms 217.41.170.5
5 62 ms 22 ms 22 ms 217.41.170.126
6 73 ms 46 ms 58 ms 213.123.78.38
7 27 ms 22 ms 22 ms 217.47.23.107
8 145 ms 93 ms 22 ms core1-pos-9-2.ilford.ukcore.bt.net [194.72.20.186]
9 26 ms 69 ms 46 ms core1-pos14-0.telehouse.ukcore.bt.net [194.74.65.133]
10 23 ms 46 ms 58 ms 195.66.226.185
11 94 ms 94 ms 141 ms p10-0.core01.bos01.atlas.cogentco.com [130.117.0.46]
12 167 ms 238 ms 130 ms p5-0.core01.ord01.atlas.cogentco.com [66.28.4.110]
13 182 ms 226 ms 178 ms p5-0.core01.sfo01.atlas.cogentco.com [66.28.4.185]
14 215 ms 262 ms 166 ms g0-1.na01.b003123-1.sfo01.atlas.cogentco.com [66.28.6.2]
15 169 ms 190 ms 166 ms UC-Berkeley.demarc.cogentco.com [66.250.4.74]
16 191 ms 238 ms 190 ms 66.28.250.125

Trace complete.

---

Looks fine then.

---

No one has good pricing, unless you are in a lit building. In a lit building, AT&T is at $3500 for 100 megs, via the telco, its $7k for 45 megs. Same with just about every company out there. You can thank your not-friendly RBOC for that (Verizon, SBC, BellSouth, Qwest).

-Mike

> 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.
>

---

The BOINC\SAH\whomever people should get their own AS from ARIN. Have BGP connections to both Cogent and Berkeley. Pre-pend the hell out of the Berkeley link so that unless something really can't be gotten to via Cogent or its on Berkeley's network, it won't travel through Berkeley. Maybe they could even setup a peering link between the two so that then all Berkeley traffic goes directly to Cogent without the pre-pending affecting it.

Cogent does lose peering relationships from time to time. This happens for two reasons. One is that since Cogent has a lot of content-push customers, they are more likely to exceed the BGP peer traffic ratios. Two isn't really proven, but more of an idea people toss around from time to time is that other carriers do it as sabotage. Cogent sells their primary product at $15/meg. Most of the big guys are over $30/meg. Obviously a lot of people move over to Cogent.

---