We're finding our router (down at the PAIX) is continually getting corrupted routing tables in memory due to (a) lack of memory and (b) constant super-high levels of traffic. Still working on it. There may also be a bad default route in there somewhere.

I'll try to elaborate more on this in tech news later today...

- Matt

Thanks for the update. Let us know if we need a fund raiser to get a replacement box.

---

Well this is reassuring...

For weeks now, I've been holding off on commenting; instead favoring keeping my mouth shut. I refuse to be one of those people who will complain when there is naught to be done for it.

Not to backpedal and suddenly complain vicariously here... But I actually have been quite frustrated with this whole mess of late. Getting work units has been near impossible. Watching my RAC drop has been somewhat infuriating at times. These proxy fixes have yielded only occasional results at best. Changing the proxy for one project has led to issues with other projects being able to connect, etc...

I don't usually complain. Instead I normally just get another one of the projects in my list fired up and going again to keep my machine busy. But I would rather devote my CPU time to SETI as that is what I have always done for the now 12 years that I've worked with the project.

But I'm not one to berate the staff. It must really suck being them right now. This particular situation seems particularly evasive, too. It's always one thing after another with this project for the last couple of years and I'm sure that for however infuriating it might be for some of us, it's twice as much or better for the staff.

Although I've pondered the idea of a router somewhere taking on too much traffic and choking up... I've wondered if we aren't experiencing some kind of DoS attack at times - given the situation itself AND the poor, inconsistent results we've seen in trying to utilize proxies. Just a thought.

But I would like to at least take some kind of proactive role in thanking the staff and volunteers for their efforts and their willingness to put up with the impatience and confusion in the comments.

Do you guys maybe have a spare box laying around that you could turn into a temporary router maybe? Just a suggestion... Although I'm sure it's something that's already been considered. :P

Keep us updated. Thanks in advance.

Cory

---

2U Rackmount Server:
Tyan 2912E, 2 Opteron DC 2220's @ 2.8GHz, 8GB DDR2 667 ECC Reg

Gaming rig: ASUS Sabertooth X58, i7 950, 6GB Corsair DDR3, 2x EVGA GTX 570 Superclocked in SLI (012-P3-1572-AR), Corsair AX1200

Using Lunatics Win64 SETI

Well then... I'm happy to report that I have finally begun to take on new work units on a regular basis. In the last 24 hours, I've received more work than I have in the last two weeks.

All without any special fixes or proxies.

Whatever you guys did... Keep doing it. :)

---

2U Rackmount Server:
Tyan 2912E, 2 Opteron DC 2220's @ 2.8GHz, 8GB DDR2 667 ECC Reg

Gaming rig: ASUS Sabertooth X58, i7 950, 6GB Corsair DDR3, 2x EVGA GTX 570 Superclocked in SLI (012-P3-1572-AR), Corsair AX1200

Using Lunatics Win64 SETI

I have not been having any problems getting work units. FWIW.

I am also running Rosetta and those WU are coming in fine as well.

Cox.net in SE Virginia:

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

  1    <1 ms    <1 ms    <1 ms  192.168.2.1
  2     6 ms     7 ms     7 ms  10.13.120.1
  3     7 ms     7 ms     8 ms  68.10.14.169
  4     9 ms     8 ms    10 ms  172.22.48.26
  5    10 ms     8 ms     8 ms  68.10.8.181
  6    16 ms    13 ms    17 ms  68.1.4.139
  7    87 ms    86 ms    87 ms  10gigabitethernet7-4.core1.pao1.he.net [184.105.
213.177]
  8    86 ms    86 ms    86 ms  64.71.140.42
  9    93 ms    92 ms    89 ms  208.68.243.254
 10   121 ms   161 ms   119 ms  boinc2.ssl.berkeley.edu [208.68.240.13]

Trace complete.

Pinging 208.68.240.13 with 32 bytes of data:
Reply from 208.68.240.13: bytes=32 time=93ms TTL=55
Reply from 208.68.240.13: bytes=32 time=93ms TTL=55
Reply from 208.68.240.13: bytes=32 time=96ms TTL=55
Reply from 208.68.240.13: bytes=32 time=90ms TTL=55

Ping statistics for 208.68.240.13:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 90ms, Maximum = 96ms, Average = 93ms

---

1. Are you able to reach ANY of the upload, download, or scheduling servers?
Sometimes, after enormous amounts of retries (between a few hours and a month).
2. When did you start having this problem?
Almost 12 months ago
3. What is your ISP?
XS4ALL
4. What is your geographic location?
Netherlands
5. What happens when you ping 208.68.240.13? 208.68.240.16? 208.68.240.18? 208.68.240.20?
Ping most of the time end in timeouts
6. How about traceroutes of the above four addresses?
Tracert seems to end in filling *** after 208.68.243.254

nslookup ends up many times in error also
As test i added the servers to my hosts to see if that solves the issue, but sadly no go.
This upload/download is a big pain in the behind

---

... This upload/download is a big pain in the behind

/signed
the trouble does not end for me too. I do not get enough work-units, I have real problems in uploading/downloading units and I am not that pro in technical issues to try out all the hints given here.

But meanwhile I must ask myself if this is worth my costs?

Kind of frustrated, old and not so serious participant like most of you here. Anyway I have had my fun in the idea of this project.

---

there is only a thin red line - between the sane and the mad

Everything worked OK for a few days, now I can't upload a completed task (doesn't see server), and update tells me there are no new tasks available, but at least it seems to see that server, so this is a different problem. All other tasks (MW, Einstein) work OK.

My IP is 187.140.205.102

Pete

I am in Shrewsbury, New Jersey.
My ISP is Verizon (FiOS)

$ nslookup 208.68.240.16
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
16.240.68.208.in-addr.arpa name = setiboincdata.ssl.berkeley.edu.

Authoritative answers can be found from:
240.68.208.in-addr.arpa nameserver = adns1.berkeley.edu.
240.68.208.in-addr.arpa nameserver = adns2.berkeley.edu.

$ traceroute 208.68.240.16
traceroute to 208.68.240.16 (208.68.240.16), 30 hops max, 40 byte packets
1 vrouter.localdomain (192.168.0.1) 0.832 ms 1.240 ms 1.236 ms
2 * * *
3 G0-5-4-7.NWRKNJ-LCR-21.verizon-gni.net (130.81.183.181) 9.726 ms 10.864 ms 12.199 ms
4 P0-4-0-0.NWRKNJ-LCR-21.verizon-gni.net (130.81.22.62) 54.861 ms 54.936 ms *
5 * 0.so-7-0-0.XL3.EWR6.ALTER.NET (152.63.19.177) 58.235 ms *
6 * 0.xe-2-1-0.XL3.NYC4.ALTER.NET (152.63.18.58) 88.920 ms *
7 GigabitEthernet4-0-0.GW1.NYC4.ALTER.NET (152.63.20.97) 52.773 ms 52.607 ms 55.657 ms
8 teliasonera-gw.customer.alter.net (157.130.60.14) 52.049 ms 61.734 ms 61.399 ms
9 nyk-bb2-link.telia.net (213.155.130.244) 93.744 ms 79.723 ms 79.195 ms
10 sjo-bb1-link.telia.net (80.91.245.96) 84.575 ms 82.290 ms 83.171 ms
11 hurricane-113209-sjo-bb1.c.telia.net (213.248.86.54) 89.879 ms 89.879 ms 91.898 ms
12 (64.71.140.42) 85.441 ms 85.512 ms 82.373 ms
13 (208.68.243.254) 134.652 ms 133.808 ms 135.597 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
trillian:jeandavid8[~]$

$ ping -c 3 208.68.240.13
PING 208.68.240.13 (208.68.240.13) 56(84) bytes of data.
64 bytes from 208.68.240.13: icmp_seq=1 ttl=249 time=87.4 ms
64 bytes from 208.68.240.13: icmp_seq=2 ttl=249 time=91.0 ms
64 bytes from 208.68.240.13: icmp_seq=3 ttl=249 time=90.9 ms

--- 208.68.240.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 87.466/89.826/91.030/1.704 ms
trillian:jeandavid8[~]$ ping -c 3 208.68.240.16
PING 208.68.240.16 (208.68.240.16) 56(84) bytes of data.

--- 208.68.240.16 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2000ms

trillian:jeandavid8[~]$ ping -c 3 208.68.240.18
PING 208.68.240.18 (208.68.240.18) 56(84) bytes of data.
64 bytes from 208.68.240.18: icmp_seq=1 ttl=250 time=133 ms
64 bytes from 208.68.240.18: icmp_seq=2 ttl=250 time=132 ms
64 bytes from 208.68.240.18: icmp_seq=3 ttl=250 time=135 ms

--- 208.68.240.18 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 132.209/133.701/135.807/1.531 ms
trillian:jeandavid8[~]$ ping -c 3 208.68.240.20
PING 208.68.240.20 (208.68.240.20) 56(84) bytes of data.
64 bytes from 208.68.240.20: icmp_seq=1 ttl=250 time=134 ms
64 bytes from 208.68.240.20: icmp_seq=2 ttl=250 time=134 ms
64 bytes from 208.68.240.20: icmp_seq=3 ttl=250 time=137 ms

--- 208.68.240.20 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 134.420/135.601/137.710/1.524 ms
trillian:jeandavid8[~]$ date
Sat Aug 20 11:13:49 EDT 2011

---

Uploads are dead in the water again.
Trace routes are failing in the same old place on all SAH IP's,
paix.he.net 198.32.176.20

This has been happening since around 22nd Aug 21:27 UTC
Which corresponds nicely with a blip in the Cricket graphs at around 14:00 Berkeley Time

3 of my hosts are now dead, too (all on the same ISP). Judging by the drop in incoming traffic on the Cricket graph, a lot of hosts got cut off at that time.

---

Hmm. I see there is still no new work being generated (the forum won't let me post to that thread in News; since there is only one reply, I guess no one can). However, my new computer downloaded a bunch last night and this morning. Is it just getting lucky and asking for them at times when there are expired or conflicted units becoming available for resend?

As far as I can tell, I'm not having any problem uploading. Next time I'm downstairs (which should be tonight), I'll try to remember to do the pings and traceroutes.

David

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Hmm. I see there is still no new work being generated (the forum won't let me post to that thread in News; since there is only one reply, I guess no one can). However, my new computer downloaded a bunch last night and this morning. Is it just getting lucky and asking for them at times when there are expired or conflicted units becoming available for resend?

As far as I can tell, I'm not having any problem uploading. Next time I'm downstairs (which should be tonight), I'll try to remember to do the pings and traceroutes.

David

The work you got more than likely were re-sends. I had received a few on my desktop, but nothing on my laptop. And to get re-sends, it is a pretty lucky shot to get in when they are loaded into the feeder. :-)

---

As far as I can tell, I'm not having any problem uploading. Next time I'm downstairs (which should be tonight), I'll try to remember to do the pings and traceroutes.

David

1. Haven't noticed any problems, but I don't pay close attention. I have boinc set for a 6 day cache and don't think I've run out this summer.
2. n/a
3. Was SBC when I signed up, now calls itself AT&T.
4. Chicago suburbs, area code 630. (Targeted ads that set themselves according to ip address usually think I'm in Elmhurst, but I'm not.)
5-7:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\User>ping 208.68.240.13

Pinging 208.68.240.13 with 32 bytes of data:

Reply from 208.68.240.13: bytes=32 time=112ms TTL=52
Reply from 208.68.240.13: bytes=32 time=108ms TTL=52
Reply from 208.68.240.13: bytes=32 time=105ms TTL=52
Reply from 208.68.240.13: bytes=32 time=104ms TTL=52

Ping statistics for 208.68.240.13:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 104ms, Maximum = 112ms, Average = 107ms

C:\Documents and Settings\User>ping 208.68.240.16

Pinging 208.68.240.16 with 32 bytes of data:

Reply from 208.68.240.16: bytes=32 time=103ms TTL=51
Reply from 208.68.240.16: bytes=32 time=104ms TTL=51
Reply from 208.68.240.16: bytes=32 time=103ms TTL=51
Reply from 208.68.240.16: bytes=32 time=103ms TTL=51

Ping statistics for 208.68.240.16:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 103ms, Maximum = 104ms, Average = 103ms

C:\Documents and Settings\User>ping 208.68.240.18

Pinging 208.68.240.18 with 32 bytes of data:

Reply from 208.68.240.18: bytes=32 time=564ms TTL=51
Reply from 208.68.240.18: bytes=32 time=533ms TTL=51
Reply from 208.68.240.18: bytes=32 time=104ms TTL=51
Reply from 208.68.240.18: bytes=32 time=102ms TTL=51

Ping statistics for 208.68.240.18:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 102ms, Maximum = 564ms, Average = 325ms

C:\Documents and Settings\User>ping 208.68.240.20

Pinging 208.68.240.20 with 32 bytes of data:

Reply from 208.68.240.20: bytes=32 time=119ms TTL=52
Reply from 208.68.240.20: bytes=32 time=103ms TTL=52
Reply from 208.68.240.20: bytes=32 time=103ms TTL=52
Reply from 208.68.240.20: bytes=32 time=103ms TTL=52

Ping statistics for 208.68.240.20:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 103ms, Maximum = 119ms, Average = 107ms

C:\Documents and Settings\User>tracert 208.68.240.13

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

1 <1 ms <1 ms <1 ms [my router]
2 <1 ms <1 ms <1 ms [my router's DNS]
3 44 ms 43 ms 44 ms adsl-*-*-*-*.dsl.emhril.sbcglobal.net [my dsl modem]
4 44 ms 44 ms 80 ms dist1-vlan60.emhril.ameritech.net [68.22.72.130]

5 51 ms 44 ms 44 ms bb1-g9-0.emhril.sbcglobal.net [151.164.94.162]
6 45 ms 45 ms 45 ms 151.164.99.169
7 45 ms 45 ms 45 ms asn3549-glbx.eqchil.sbcglobal.net [151.164.248.18]
8 101 ms 99 ms 100 ms Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net [64.214.174.246]
9 98 ms 99 ms 98 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
10 98 ms 99 ms 112 ms 64.71.140.42
11 103 ms 112 ms 103 ms 208.68.243.254
12 103 ms 105 ms 104 ms boinc2.ssl.berkeley.edu [208.68.240.13]

Trace complete.

C:\Documents and Settings\User>tracert 208.68.240.16

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

1 <1 ms <1 ms <1 ms [my router]
2 <1 ms <1 ms <1 ms [my router's dns]
3 43 ms 45 ms 44 ms adsl-*-*-*-*.dsl.emhril.sbcglobal.net [my dsl modem]
4 44 ms 43 ms 44 ms 68.250.251.66
5 76 ms 44 ms 43 ms dist1-g2-1.emhril.sbcglobal.net [151.164.43.88]

6 44 ms 44 ms 44 ms bb1-g9-0.emhril.sbcglobal.net [151.164.94.162]
7 44 ms 45 ms 44 ms 151.164.99.161
8 286 ms 256 ms 306 ms asn3549-glbx.eqchil.sbcglobal.net [151.164.248.18]
9 98 ms 98 ms 98 ms Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net [64.214.174.246]
10 100 ms 99 ms 98 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
11 104 ms 99 ms 100 ms 64.71.140.42
12 104 ms 111 ms 104 ms 208.68.243.254
13 103 ms 104 ms 103 ms setiboincdata.ssl.berkeley.edu [208.68.240.16]

Trace complete.

C:\Documents and Settings\User>tracert 208.68.240.18

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

1 <1 ms <1 ms <1 ms [my router]
2 <1 ms <1 ms <1 ms [its dns]
3 44 ms 43 ms 44 ms adsl-*-*-*-*.dsl.emhril.sbcglobal.net [modem]
4 47 ms 43 ms 44 ms 68.250.251.2
5 44 ms 44 ms 43 ms dist1-g2-4.emhril.sbcglobal.net [151.164.53.130]

6 44 ms 43 ms 57 ms bb1-g0-0.emhril.ameritech.net [151.164.43.82]
7 61 ms 44 ms 44 ms 151.164.99.165
8 45 ms 44 ms 44 ms asn3549-glbx.eqchil.sbcglobal.net [151.164.248.18]
9 98 ms 99 ms 113 ms Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net [64.214.174.246]
10 124 ms 102 ms 98 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
11 98 ms 100 ms 98 ms 64.71.140.42
12 102 ms 103 ms 104 ms 208.68.243.254
13 103 ms 104 ms 103 ms boinc2.ssl.berkeley.edu [208.68.240.18]

Trace complete.

C:\Documents and Settings\User>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 [router]
2 <1 ms <1 ms <1 ms [its dns]
3 44 ms 43 ms 44 ms adsl-*-*-*-*.dsl.emhril.sbcglobal.net [modem]
4 45 ms 44 ms 44 ms dist2-vlan60.emhril.ameritech.net [68.22.72.131]

5 43 ms 44 ms 45 ms dist1-g2-1.emhril.sbcglobal.net [151.164.43.88]

6 44 ms 45 ms 46 ms 151.164.101.214
7 45 ms 44 ms 44 ms 151.164.99.169
8 58 ms 45 ms 45 ms asn3549-glbx.eqchil.sbcglobal.net [151.164.248.18]
9 103 ms 99 ms 102 ms Hurrican-Electric-LLC.Port-channel100.ar3.SJC2.gblx.net [64.214.174.246]
10 99 ms 98 ms 99 ms 10gigabitethernet3-2.core1.pao1.he.net [72.52.92.69]
11 99 ms 99 ms 99 ms 64.71.140.42
12 103 ms 104 ms 103 ms 208.68.243.254
13 104 ms 104 ms 103 ms setiboinc.ssl.berkeley.edu [208.68.240.20]

Trace complete.

C:\Documents and Settings\User>nslookup 208.68.240.13
*** Can't find server name for address [my router]: Non-existent domain
*** Default servers are not available
Server: UnKnown
Address: [my router]

Name: boinc2.ssl.berkeley.edu
Address: 208.68.240.13

C:\Documents and Settings\User>nslookup 208.68.240.16
*** Can't find server name for address [my router]: Non-existent domain
*** Default servers are not available
Server: UnKnown
Address: [my router]

Name: setiboincdata.ssl.berkeley.edu
Address: 208.68.240.16


C:\Documents and Settings\User>nslookup 208.68.240.18
*** Can't find server name for address [my router]: Non-existent domain
*** Default servers are not available
Server: UnKnown
Address: [my router]

Name: boinc2.ssl.berkeley.edu
Address: 208.68.240.18


C:\Documents and Settings\User>nslookup 208.68.240.20
*** Can't find server name for address [my router]: Non-existent domain
*** Default servers are not available
Server: UnKnown
Address: [my router]

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


C:\Documents and Settings\User>

I hope this is somehow helpful.

David

---

David
Sitting on my butt while others boldly go,
Waiting for a message from a small furry creature from Alpha Centauri.

Unable to upload WU's since Monday. Can not ping the 4 IP address. tracert dies after leaving my network.

---

Just to add another report.

I am another who hasn't been able to upload results for several days.
Some of the reults I can't upload are close to deadline.

I tried using a proxy server (as suggested in the other thread)
but that didn't help.

Pinging the ip addresses suggested just times out.

Boinc Manager itself gives the standard message
"Internet access OK - project servers may be temporarily down."
The Server status page says the upload server is working.

Trace route (using Ping Plotter) gives the destination IP as unreachable after the first he.net address

Target Name: setiboincdata.ssl.berkeley.edu
IP: 208.68.240.16
Date/Time: 2011-08-25 13:20:54 (+12)

2 136 ms 177 ms lns2.sky.woosh.net.nz [202.74.206.8]
3 * * [-]
4 143 ms 192 ms g0-1-70.br3.sky.woosh.net.nz [202.74.206.115]
5 111 ms 189 ms woosh.cre2.nct.odyssey.net.nz [121.99.12.45]
6 402 ms 138 ms odyssey-int.tkbr10.global-gateway.net.nz [202.50.234.66]
7 387 ms 105 ms xe3-1-0-101.tkbr10.global-gateway.net.nz [202.50.234.65]
8 356 ms 85 ms ae10-10.tkbr9.global-gateway.net.nz [202.50.232.205]
9 326 ms * ae2-3.labr5.global-gateway.net.nz [203.96.120.142]
10 321 ms 403 ms ae1-3.sjbr2.global-gateway.net.nz [203.96.120.94]
11 290 ms 382 ms ae0.pabr4.global-gateway.net.nz [203.96.120.74]
12 511 ms 362 ms paix.he.net [198.32.176.20]
13 * * [-] Destination Address Unreachable

Destination not reached in 35 hops

---

This router business is getting damned annoying. Compare the 2 trace routes below. ISP #1 gets through every time (but this is my mobile account and which has a limited monthly MB allowance). ISP #2 is my home ADSL account which is blocked by the faulty router. The most annoying thing is that the 2 switchers at addresses 202.84.251.34 and 202.84.251.106 are probably located in the same building if not the same rack.

The proxy in Denmark is dying, I think the admin must have noticed the sharp increase in traffic and has started blocking or throttling IP addresses. Either that or its getting overloaded.

Unfortunately it looks like I will have to "go dark" until the problem is fixed. I just don't have the time to chase alternate proxies or babysit my computers through the upload process. It's probably just as well there are no new work units coming down the pipe it would really be FUBAR for the project if the bandwidth usage was "normal".

Surely there must be some way to patch around the faulty router ???

ISP #1
Tracing route to boinc2.ssl.berkeley.edu [208.68.240.13]
over a maximum of 30 hops:
<snip>
12 246 ms 260 ms 389 ms 203.50.13.130
13 2168 ms 1149 ms 1139 ms i-0-3-2-0.paix-core01.bx.reach.com [202.84.140.5
4]
14 398 ms 421 ms 478 ms i-3-1.paix01.bi.reach.com [202.84.251.34]
15 * * * Request timed out.
16 406 ms 400 ms 400 ms 64.71.140.42
17 360 ms 359 ms 381 ms 208.68.243.254
18 811 ms 369 ms 379 ms boinc2.ssl.berkeley.edu [208.68.240.13]

Trace complete.

ISP #2
Tracing route to boinc2.ssl.berkeley.edu [208.68.240.13]
over a maximum of 30 hops:
<snip>
6 242 ms 244 ms 242 ms i-0-0-2-0.paix-core01.bx.reach.com [202.84.140.1
06]
7 243 ms 242 ms 299 ms i-2-1.paix01.bi.reach.com [202.84.251.101]
8 266 ms 274 ms 273 ms paix.he.net [198.32.176.20]
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 ^C

T.A.

I am now able to upload :-}

---

Matt just posted in Tech News that he rebooted the router again.
Might want to give it one more try.......

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Still dead here.
No uploads and Trace routes still die at paix.he.net [198.32.176.20] :-(

T.A.