Sorry but I am upset you are not keeping us informed from day to day or week to week about why I can't get any files uploaded or downloaded.

If the routers are still the problem why have they not been fixed rerouted or something.

I am in Canada I have not been able to transfer any infomation since the router failed.

Bye for now.

Have to agree with you, David. BOINC has been reporting to me here in the UK that the project servers may be temporarily down continually for close on two week. Nothing has been changed this end and my other projects continue to work properly. A regular status update (daily, when there are major issues would be good) and a recognition that some of us, at least, are experiencing problems would be appreciated.

For the first time of about a month I got a functional connection with S@H today. Reported one work and got plenty to crunch.

I haven't done anything about proxys etc so suddenly it just work.

Regards

Nisse E

---

Yes, the issue is completely random as to who it will or won't hit or for how long.

---

For the first time of about a month I got a functional connection with S@H today. Reported one work and got plenty to crunch.

I haven't done anything about proxys etc so suddenly it just work.

Regards

Nisse E

And today, my "work" pc will not upload again! I get it working for about a week and then dead in the water! No ryme or reason, proxy, no-proxy, different proxy........

Very frustrating!

---

I have exchanged emails with HE and supplied successful and unsuccessful traceroutes from different ISPs.

They tell me that the packets are stopping at the SETI router.

This is the last response from them, and is the best summary:

paix.he.net is the hop before their router. Their router doesn't have
enough memory for a global routing table, and due to this, BGP sessions
bounce, and their routing table is often incomplete or in some corrupted
state. It can't always reply due to no return path.

You could try traceroute to my address (211.30.25.25). And to the edges of the HE network.

A traceroute to paix.he.net (198.32.176.20) and to 10gigabitethernet3-2.core1.pao1.he.net (72.52.92.69) should provide some interesting comparison with my traceroutes.

Either HE is right and it is your router, or the route to you is not being picked up by all of the HE routers, or both.


Answers:
1. No - none
2. Last successful update 5th oct from what I can tell
3. I am on Optus Cable (211.30.25.25 - dynamic but rarely shifts)
4. Sydney Australia
5,6

Ping fails to all of the addresses for me.

Traceroute produces same result for all of the addresses.
Traceroute to 208.68.240.13 (208.68.240.13), 64 hops max, 40 byte packets
1 10.0.1.1 (10.0.1.1) 14.825 ms 2.196 ms 2.379 ms
2 10.63.0.1 (10.63.0.1) 14.893 ms 9.158 ms 9.461 ms
3 riv3-ge0-2.gw.optusnet.com.au (198.142.160.241) 14.248 ms 11.392 ms 9.398 ms
4 riv5-ge5-0.gw.optusnet.com.au (211.29.126.29) 11.025 ms 12.089 ms 9.914 ms
5 203.208.131.245 (203.208.131.245) 176.757 ms 203.233 ms 173.577 ms
6 POS3-2.sngtp-ar2.ix.singtel.com (203.208.182.205) 171.980 ms xe-0-0-0-0.plapx-cr2.ix.singtel.com (203.208.183.161) 174.327 ms POS3-2.sngtp-ar2.ix.singtel.com (203.208.182.205) 175.082 ms
7 paix.he.net (198.32.176.20) 175.871 ms 198.289 ms 172.580 ms
8 * * *


From another ISP in sydney (TPG ADSL- 123.243.83.241 - static):
Ping to all addresses works (times vary slightly):
PING 208.68.240.20 (208.68.240.20): 56 data bytes
64 bytes from 208.68.240.20: icmp_seq=0 ttl=55 time=170.762 ms

All of your IPs traceroute the same from here also.
traceroute to 208.68.240.13 (208.68.240.13), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 1.995 ms 0.529 ms 3.296 ms
2 10.20.21.49 (10.20.21.49) 16.975 ms 15.506 ms 17.576 ms
3 202.7.173.185 (202.7.173.185) 16.513 ms 16.077 ms 15.855 ms
4 syd-nxg-men-crt1-ge-7-0-0.tpgi.com.au (202.7.171.1) 16.489 ms 16.850 ms 18.254 ms
5 207.114.154.9 (207.114.154.9) 167.543 ms 167.152 ms 167.294 ms
6 sjc1-pr1-ge-1-0-0-0.us.twtelecom.net (66.192.242.190) 166.172 ms 166.575 ms 166.876 ms
7 10gigabitethernet3-2.core1.pao1.he.net (72.52.92.69) 167.939 ms 168.211 ms 174.577 ms
8 64.71.140.42 (64.71.140.42) 167.181 ms 166.714 ms 167.547 ms
9 208.68.243.254 (208.68.243.254) 190.159 ms 183.709 ms 178.069 ms
10 * * *

I have a RIPE atlas probe on my Optus cable account - it is number 1075 and is public.

Let me know if I can provide any more help.

---

I should also mention that HE tell me their traceroute & ping page (http://lg.he.net/) is broken:

Our LG does not always source traces from the correct addresses at the
moment. Some of our interfaces were renumbered to rfc1918 space, and
when it chooses one of these to source a trace from, you cannot see
beyond our network.

Make of this what you will.

Is 64.71.140.42 an address on the failing router? Or one hop upstream?

---

Sorry but I am upset you are not keeping us informed from day to day or week to week about why I can't get any files uploaded or downloaded.

If the routers are still the problem why have they not been fixed rerouted or something.

I am in Canada I have not been able to transfer any infomation since the router failed.

Bye for now.

2nd that here.. I have 1 comp that U/L and D/L fine. The other one (right next to the working one) gets nothing.. Timeout when ping. Tried to flush the DNS and still nothing.

I have no idea what to try next.

It is possible to manually transfer work from one comp to another until they fix thes problem?

-W

---

Hey all - I'm trying to characterize this current problem where some users are unable to reach any of our servers through Hurricane Electric. If possible please answer in this thread the following questions (feel free to leave out anything you want to keep private, or don't understand):

1. Are you able to reach ANY of the upload, download, or scheduling servers?
2. When did you start having this problem?
3. What is your ISP?
4. What is your geographic location?
5. What happens when you ping 208.68.240.13? 208.68.240.16? 208.68.240.18? 208.68.240.20?
6. How about traceroutes of the above four addresses?
7. Or nslookups of the above four addresses?

Or if you know what the exact problem is (or if there isn't really a single problem but a set of problems) that would be useful, too.

Thanks!

- Matt

1 - 1 out of 2 computers can, both have the same connection to the internet.
2 - Sometime within the 1st week of Oct.
3 - ISP is Sasktel
4 - Saskatchewan, Canada
5 - All time out on the non-working comp.
6 - Cannot get past Hurricane Electric. time outs
7 - Cannot get past Hurricane Electric.

-W

---

Hi, I am reporting the same old HE problem.
My traceroute ends on 10gigabitethernet7-4.core1.pao1.he.net:

zrouter ~ # traceroute 208.68.240.20
traceroute to 208.68.240.20 (208.68.240.20), 30 hops max, 60 byte packets
1 ip-58-1.sn1.eutelia.it (62.94.58.1) 17.456 ms 17.303 ms 22.586 ms
2 ip-3-164.sn-212-90.eutelia.it (212.90.3.164) 24.950 ms 24.854 ms 27.440 ms
3 20gigabitethernet1-3.core1.ams1.he.net (195.69.145.150) 55.712 ms 55.621 ms 58.145 ms
4 10gigabitethernet2-1.core1.par2.he.net (184.105.213.102) 69.227 ms 71.785 ms 71.690 ms
5 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93) 151.443 ms 154.076 ms 154.000 ms
6 10gigabitethernet7-4.core1.pao1.he.net (184.105.213.177) 206.905 ms 206.770 ms 209.371 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 *^C


But from HE Looking Glass tool,
selecting their Amsterdam (ams1.he.net) entry point all is OK:


core1.ams1.he.net> traceroute 208.68.240.20 numeric Target 208.68.240.20
Hop Start 1
Hop End 30
Hop Packet 1 Packet 2 Packet 3 Hostname
1 10 ms 10 ms 10 ms 10gigabitethernet2-1.core1.par2.he.net (184.105.213.102)
2 88 ms 90 ms 88 ms 10gigabitethernet7-1.core1.ash1.he.net (184.105.213.93)
3 161 ms 158 ms 165 ms 10gigabitethernet7-4.core1.pao1.he.net (184.105.213.177)
4 177 ms 159 ms 159 ms 64.71.140.42
5 186 ms 200 ms 200 ms 208.68.243.254
6 198 ms 199 ms 200 ms setiboinc.ssl.berkeley.edu (208.68.240.20)

It seems like someone is doing something nasty with source routing...
Or perhaps a BGP route problem.

Hope this is not a poor attempt to ask fundings by the nice SETI@HOME people.

Bye

1) Not as far as I can tell

2) Mid September IIRC.

3) Zen.co.uk

4) UK

5-7)

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

C:\Users\Mark>ping 208.68.240.13

Pinging 208.68.240.13 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.68.240.13:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Mark>ping 208.68.240.16

Pinging 208.68.240.16 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.68.240.16:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Mark>ping 208.68.240.18

Pinging 208.68.240.18 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.68.240.18:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Mark>ping 208.68.240.20

Pinging 208.68.240.20 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 208.68.240.20:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\Mark>nslookup 208.68.240.20
Server: dns.lb.mbr-roch.zen.net.uk
Address: 212.23.3.100

Name: setiboinc.ssl.berkeley.edu
Address: 208.68.240.20


C:\Users\Mark>tracert 208.68.240.20

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

1 5 ms 4 ms 4 ms (me)
2 32 ms 29 ms 29 ms losubs.subs.dsl2.th-lon.zen.net.uk [62.3.84.21]
3 31 ms 29 ms 29 ms ge-0-0-0-115.cr2.th-lon.zen.net.uk [62.3.84.189]
4 30 ms 41 ms 28 ms 10gigabitethernet1-1.core1.lon1.he.net [195.66.224.21]
5 120 ms 123 ms 124 ms 10gigabitethernet6-3.core1.ash1.he.net [72.52.92.137]
6 184 ms 187 ms 186 ms 10gigabitethernet7-4.core1.pao1.he.net [184.105.213.177]
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * ^C
C:\Users\Mark>

---

After core1.nyc4.he.net you see a "request timed out" warning

C:\Users\admin>tracert 208.68.240.20

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

1 <1 ms <1 ms <1 ms 192.168.0.1
2 7 ms 8 ms 7 ms xxxxxxxxxxx.dynamic.upc.nl [xxxxxxxxxxxx]
3 9 ms 7 ms 6 ms p52089.net.upc.nl [212.142.52.89]
4 16 ms 8 ms 8 ms p2129.net.upc.nl [212.142.2.129]
5 88 ms 86 ms 86 ms nl-ams05a-rd2-ae-60-2366.aorta.net [84.116.244.65]
6 88 ms 88 ms 88 ms us-nyc01b-rd1-gi-4-0-0.aorta.net [84.116.130.30]
7 89 ms 93 ms 86 ms us-nyc01b-ri1-ge-0-1-0.aorta.net [213.46.190.178]
8 179 ms 104 ms 86 ms core1.nyc4.he.net [198.32.118.57]
9 * * * Request timed out.
10 174 ms 174 ms 174 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
11 168 ms 166 ms 165 ms 64.71.140.42
12 175 ms 171 ms 172 ms 208.68.243.254
13 175 ms 175 ms 182 ms setiboinc.ssl.berkeley.edu [208.68.240.20]

Trace complete.

@David Mueller
@David1946
@richardw66
@Wolverine
@Andrea Zuccherelli
@Meridian
@S@NL Ejo
@everybody who can't UL/DL:)

Somewhere buried in this endless thread are the answers you are looking for. They are by Jeff Cobb, one of the Seti project scientists:

We are working with HE to clear up this routing issue. They are being very helpful.

We will need to involve parties beyond HE. Here is a little bit of background. Our PAIX router physically talks to HE on one side and to CENIC on the other, whereupon the physical path proceeds through CENIC, then through UCB, then through SSL before finally landing at the router in our closet. All of this even though, logically, we tunnel directly from our PAIX router to our closet router. Both of our routers were donated by Packet Clearing House (PCH). They also helped us initially set them up and physically host our PAIX router in their rack at the PAIX. PCH really came to our rescue way back when we learned that we could not use (or afford to use) the UCB commodity provider. They also helped us migrate from Cogent to HE.

Back to he problem...
HE guessed that we don't have enough memory in our PAIX router to hold the giant routing table that we need to hold. This is more or less confirmed by looking at the memory stats on that router. One solution (the best) is to add memory, or replace the router if it cannot take more memory.

Another, perhaps interim, solution suggested by HE is to have our router utilize a default route rather than maintain a huge routing table. We tried that. Well, at least HE did their part to make it so. And it flat-lined our traffic. Thus our need to involve the other players. I have emailed them all. But everyone is super busy and, in the case of PCH, all effort is donated.

Speaking of being super busy.... I apologize for the the lack of communication recently. Both Matt and Bob have been gone for the past month, and Eric for the past week. That leaves one man on deck. So I'm a bit um.. stretched.

and

Memory for our PAIX router has been ordered. This will increase the amount of memory x4. Once it arrives, we will need to work with Packet Clearing House to physically swap in the new DIMMs.

The increase in memory *should* solve the connectivity problems.

You can find those here

So, your guess is as good as mine, but maybe it'll get fixed this week? Maybe next? Unfortunately (it sounds like) it's just one of those problems that are gonna need time to fix.

Edit: another thing to keep in mind is that depending on your personal forum settings, not all posts in this thread are displayed. Mine, for example, hide a lot of messages (and I think these are probably the default settings as I can't recall changing them). So underneath Matt's first post in the thread it reads:

"Only the first post and the last 75 posts (of the 458 posts in this thread) are displayed.
Click here to also display the remaining posts."

Patience grasshoppers:)

What led me to post about this was that the Traceroute appeared to show a routing problem besides the memory.

Although this seems like a routing issue going to the SETI router, it was quite plausible that it is just memory in the router.

I think the issue is the complexity of the environment the router is working within is what makes it look like a router issue to those of us without a thorough knowledge of the network the router is living in.

This complexity is also what is making the routing table so large, thereby using up the memory.

My communication with HE ended with that response I posted about the PAIX router being the last hop.

If the traceroutes are always dying at the last hop before the SETI router with the memory issue, then the diagnosis would be that the SETI router was the only issue.

I only raised the issue about routing as this did not appear to be the case. HE assured me it is the case, so I thanked them and closed the ticket.

There seemed to be 'official' doubt on here so I offered the data in that spirit and suggested ways to check.

The reverse traceroutes out of SETI to the world would provide confirmation, I did not disbelieve HE as such, I just remain skeptical with any tech issue until it is resolved, and my suggested methods should have confirmed HE's diagnosis.

The issue here is nowhere near as mysterious as it seems, there are 3 possibilities with a routing issue that is location dependant:

1. The packets are not getting to HE from all destinations.
2. The HE routers are not routing the packets correctly to all destinations
3. the packets are not routing to the SETI router from all other routers at HE.
4. The SETI router is not routing packets from all routes correctly.

Options 1 and 2 are not ocurring, the traceroutes rule that out.

Option 3 is what I discussed with HE - and they rule that out. If I knew their network better I could have ruled it out.

So this leaves option 4 and ded1o1's traceroute nicely shows the failure ocurring at the router.

When SETI finds intelligent life the first question we ask should be 'What is the solutions to the problems of time and money?'

That will provide the solution to the router :)

---

NB: We should also correct the grammar of any question I pose before sending it, so the human race doesn't look stupid :)

---

NB: We should also correct the grammar of any question I pose before sending it, so the human race doesn't look stupid :)

The human race *is* stupid, but at least, most of us here are less stupid than average!

I processed many several tens of WUs the last four weeks, but getting them validated, and receiving the credits, turns out to be a slow process. My interpretation is that it is related to the connection problems.

Eric and I went to the PAIX today and quadrupled the memory in our router. The router stats indicate that there is now plenty of memory to spare. But we are still seeing evidence of packet loss from various points around the globe.

Is anyone seeing a difference? Thanks!

---

Hi Jeff

After many weeks without being able to even connect without a proxy I could up-/download and report today WUs, though with a few hick-ups.
Location Switzerland, ISP cablecom.
Trace routes and pings were successfully too (well, almost).

BR

Andy

---

I just wasted some time looking for a working proxy and decided to look at this thread.

It's great news that, for me, the problem is solved, at least for now, and I do not need that proxy after all.

It would be great if an improvement like this had been posted as a Boinc Manager Notice, it would have saved a half hour of futility.

---