Has anyone had problems accessing www.unmannedspaceflight.com recently ? Since last weekend I haven't been able to access it from home but if I use a computer at work (as I'm obviously doing now ;-) ) there are no problems.

This is the only website I'm having any problems accessing so this is really weird.

I'm having no problems, but um3k emailed me earlier today to ask me the same question -- he can't see it either.

--Emily

Sounds like somebody's DNS server has gone sideways, somewhere...

Bob Shaw

Weird - it works now for the first time since last Saturday (I'm sending this from home ). And I checked many times a day so the problem was probably 'continuous'.

EDIT: I don't think this was a DNS problem because I'm getting the same address for UMSF (72.9.234.170) as I got several hours ago when I couldn't get here from home.

It's working for me now.

I've not had any problem at any point from either work or home. It can't be a server problem as it was working for most people all the time. Perhaps some sort of routing problem in the 'net somewhere.

Doug

Once in a while UMSF will "time out" and I'll get a "Page Cannot Be Displayed" message. I assume it's a 'net problem.

Could Bjorn's problem be a firewall at work? Or some network admin filtering non-work-related Internet addresses?

--Bill




EDIT: oops, I re-read the messge and the problem is at home.

I dunno...

The problem has reappeared - I again cannot access UMSF from home. There have been intermittent errors from work as well but a 'Refresh' in IE usually gets rid of these.

Maybe a routing problem. Here is a portion of 'traceroute' I did when everything worked properly yesterday:

[Snip]
8 95 ms 83 ms 83 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
9 50 ms 52 ms 50 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10 50 ms 83 ms 54 ms ldn-b2-link.telia.net [213.248.100.193]
11 59 ms 51 ms 50 ms ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12 618 ms 330 ms 368 ms nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13 306 ms 411 ms 281 ms ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14 227 ms 194 ms 159 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15 154 ms 159 ms 159 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16 150 ms 140 ms 138 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17 172 ms * 173 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18 176 ms 172 ms 169 ms star.dnsprotect.com [72.9.234.170]

Now things look like this:

[Snip]
8 85 ms * 98 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
9 * 52 ms 59 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10 51 ms 60 ms 62 ms lon-b2-pos1-3.telia.net [213.200.77.134]
11 83 ms 84 ms 83 ms ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12 142 ms 126 ms 128 ms nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13 187 ms 143 ms 130 ms ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14 151 ms 147 ms 141 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15 143 ms 132 ms 120 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16 128 ms 125 ms 117 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17 134 ms 146 ms 149 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Strangely I also get "Request timed out" at work but still can access UMSF...

An interesting topic just to find out on which kind of server is UMSF running ?
a curious ITer on the continent

It's a package from www.imhosted.com



Doug

Bjorn:

You get to star.dnsprotect.com [72.9.234.170] when it works, but don't when it fails. Sounds to me like somebody, somewhere, is going to a cached version of UMSF (sometimes). When it all works, it all works. When it fails briefly, the page gets (properly) refreshed next time. Try changing your DNS lookup to another DNS server - I'll post a list if anyone is interested.

Bottom line: trust not host services, or ISPs - they have the LIE flag set by default!

Bob Shaw

This "Page Cannot Be Displayed" has happened to me a few times today and other days usually while paging backwards. but its just occassional

Traceroute is getting to be quite unreliable these days on the big ole internet as many providers specifically block such traffic in order to prevent malicious entities mapping their infrastructure. Some systems block all ICMP traffic so even simple pings don't work but slightly smarter systems allow ping traffic but recognise and block Traceroute packets.

The problem as described would have me suspect the following (in decreasing order):
DNS problems - either the affected client has a DNS cache issue or its DNS servers have an issue dealing with some DNS change for www.unmannedspaceflight.com. That change might not be one Doug would ever be aware of - it could be a change in any DNS system between your DNS and the root DNS infrasture or between the point where www.unmannedspaceflight.com is registered and the root DNS servers.
If you are using XP the following command lines may help see\resolve the issue if it is client side\your DNS:
ipconfig /displaydns and nslookup
Shows the contents of your DNS Cache - specifically shows the host name and Time To Live (in seconds). The TTL shows the time left before your DNS will go back out and confirm the cached value of UMSF that it has. Nslookup <hostname> will show you the current ip-address your machine resolves <hostname> to.
ipconfig /flushdns
This will clear out your local dns cache and force your machine to carry out a lookup again. It wont help if dns servers are the problem but it's worth a shot.

A netblock ban being enforced by some entity between you and www.unmannedspaceflight.com. It happens to some folks more than others and depends mostly on how responsive your own ISP is to requests to cut off sources of known malicious traffic.

A failed\misconfigured load balancer close to www.unmannedspaceflight.com . The real nasty aspect of these is that unless you know how the load balancer in question actually works it can be very hard to identify. In the cases I've seen the problem will affect a subset of users and depends entirely on your ip-address. Sometimes it's block based (e.g. users from 172.44.22.x can get to the site but users from 172.44.23.x can't) and sometimes it's full-ip based (e.g. 172.44.22.101 can get to the site but 172.44.22.102 can't), sometimes it's a round-robin effect (you succeed on average 4 times out of five attempts on a 5 way load balancer with one failed node). These are fairly simple examples, current ip load balancer tech is pretty smart but when it fails it really can be a bugger for a customer to figure out.

AlertSite provide a nice minimal page with all the basic tools in one place that allow you to get the same tests from a different location (WebPage Performance\Ping\Traceroute\Whois\DNS lookup]
http://www.dnsstuff.com/ Provides a bunch of additional excellent stuff in a slightly less simple format. It's trace route clearly recognises that dnsprotect seems to suppress unwanted ICMP traffic.
Traceroute.org provides a dazzling array of potential source locations for carrying out a traceroute test.

Now I'm again unable to access UMSF from home. Things worked briefly (for about a day) on Monday. This is getting seriously annoying but I'm not sure where (if anywhere at all) to complain...

If anyone else apart from me and probably um3k has had similar problems I'd really like to know.

I have tried flushing the DNS cache on my machine as suggested in the previous message but to no avail.

Did you setup a hosts file ? If you did and the target ip address changed you may not be able to display the page.

Still 100% for me from both work and home- I really don't know what to suggest.

Doug

FWIW, UMSF is what I like to call a 'live' site rather than a 'static' one, ie what we see is really a front-end for a database. If we refresh any such site we don't simply go to a cached page (many providers cache without telling you) but instead actually ask the UMSF server to do some work. I sometimes find that my first - presumably stealthily cached by NTL, my cable company - attempt attempt to see a UMSF page fails, but the second is fine. Perhaps there's an error condition generated at the cache end which then points me directly to UMSF?

This could be the cause of home vs work problems - I'll bet that home users get cached to save traffic on the real WWW (would users even notice?).

Bob Shaw

That would make a lot of sense. UMSF is indeed entirely DB driven, PHP, SQL and Apache all have to work to serve each page. If for some reason you have a local cached version perhaps with your ISP or work network - that would 'break' it.

Doug

I've had some occasional issues with UMSF not refreshing well (or at all quickly), but it's been a while since I've had a really hard time staying connected. And when I do have a problem, it's usually a SQL error and not a DNS lookup issue that's killing me.

However, I'm seeing a more subtle behavior issue lately. Keep in mind, I'll often start reading posts here, go off and do other things, and come back to read more posts -- all without logging in or out of the site.

Now we all know that when you first bring the site up, the forum and sub-forum icons show you if there are unread posts in those fora. When you get into the topic lists, of course, there is a small red flag next to individual threads if they contain unread posts.

When I leave the site up but unattended for a while (especially when displaying a given thread or sub-forum topic list) and then go back to the main forum list, the forum icons reset to an "all read" status, even if I haven't gone into those fora during this visit. I end up checking the last-post timestamps at the forum levels to see if there might be unread posts out there that I haven't seen.

It's not a huge inconvenience (if I didn't care about keeping my reading organized into fora, I could just look at the recent posts lists). But it is a glitch in the proper operation of the Invision board software, so I thought I'd mention it.

-the other Doug

I'm sure it's something that was probably looked at with the latest invision board revision - but obviously, as experience has shown - I'm not a big fan of upgrades

Doug

I'm seeing something similar. I generally tend to use the "View New Posts" button to monitor activity and it has worked pretty reliably up until recently. I've noticed occassional posts in the past that I missed but over the last week or two I've seen a lot and yesterday I noticed that the list "cleared" almost completely between two sessions even though I hadn't read any of them.

It's not a big deal for me either, more of an inconvenience as you say, but just thought I'd flag it as something I'd noticed.

I have noticed this as well but it's a minor inconvenience.

The big issue for me is accessing UMSF from home. I seriously doubt it's a caching issue. When 'tracert' ends with star.dnsprotect.com (as in one of the sample traceroute outputs I posted on page 1 in this thread) I can access UMSF from home; when it doesn't I can't access it from home but can access it from work. The tracert output is identical from home and work except for the first few entries.

I wonder if this might be a problem at gig0-1.l3-atl-5.gnax.net [209.51.131.94]

At the moment I cannot access UMSF at home; several hours ago I could. The situation was similar yesterday, a 'window' for a few hours when I could access UMSF from home.

Maybe I should try complaining to my ISP and pretend I have no idea of tracert etc. .

This is really sounding like a load balancer issue to me. Your ISP may well be using load balancers to maintain even traffic on its server nodes. If one of those goes a little bad, this is the kind of thing that can happen. And it's hard as hell to track down.

Instead of pretending ignorance of such things, it might be best to simply tell them what you know and inquire as to whether they have been doing any tests on their load balancers.

Also, it's possible that your ISP is using a larger provider's servers, and has limited control over some of the nodes it uses. And that includes load balancing on those nodes. So, that might be a good data point to pin down with them, as well -- if you can.

-the other Doug

I emailed my ISP today and included several 'tracerts' I did when things worked/didn't work etc. Hopefully I get a useful response although I am not particularly optimistic (needless to say I am not posting this message from home).

Here's an idea - whenever you have trouble - do a tracert and past the full contents here - and I'll collect a few and send them to the hosting company, just to check things from their end.

Doug

I've noticed that when I access UMSF from home after 8:00pm in the evening, the toilet in the front bathroom flushes, and it does it again each time I attempt to reload a page. It doesn't happen when I access a page through a link. When I click on an image link Monday mornings after 6:00 am, the front doorbell rings twice, causing my dog to bark and wake up the kids.

Reminds me of the old Steven Wright line:

Obviously a Microsoft conspiracy ;-).


Here is a tracert from work:

Tracing route to unmannedspaceflight.com [72.9.234.170]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 10.1.0.252
2 <10 ms 1 ms 1 ms 213.213.152.93.in.is [213.213.152.93]
3 1 ms 2 ms 1 ms fe2-0.core02.islandssimi.is [213.176.138.67]
4 2 ms 2 ms 1 ms fe0-0.uk-gw.islandssimi.is [213.176.138.5]
5 47 ms 47 ms 48 ms 213.176.138.254.in.is [213.176.138.254]
6 43 ms 46 ms 55 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
7 42 ms 41 ms 41 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
8 43 ms 41 ms 41 ms ldn-b2-link.telia.net [213.248.100.193]
9 42 ms 42 ms 42 ms ldn-bb2-pos1-3-0.telia.net [213.248.64.73]
10 153 ms 166 ms * nyk-bb2-pos0-2-0.telia.net [213.248.65.94]
11 136 ms 131 ms 139 ms ash-bb1-pos7-0-0-0.telia.net [213.248.80.138]
12 160 ms 158 ms 148 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
13 143 ms 127 ms 133 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
14 123 ms 123 ms 128 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
15 136 ms 136 ms 123 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
16 153 ms 118 ms 118 ms star.dnsprotect.com [72.9.234.170]

Trace complete.


Here is a tracert from home:

Tracing route to unmannedspaceflight.com [72.9.234.170]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms my.router [192.168.1.1]
2 6 ms 7 ms 7 ms 217.151.181.57
3 6 ms 6 ms 6 ms 217.151.181.58
4 8 ms 8 ms 8 ms 217.151.181.62
5 9 ms 9 ms 10 ms fe2-0.core01.islandssimi.is [213.176.138.66]
6 24 ms 11 ms 9 ms fe0-0.uk-gw.islandssimi.is [213.176.138.5]
7 55 ms 54 ms 54 ms 213.176.138.254.in.is [213.176.138.254]
8 49 ms 49 ms 49 ms ae0-6.lon11.ip.tiscali.net [213.200.77.125]
9 70 ms 75 ms 79 ms so-3-1-0.lon22.ip.tiscali.net [213.200.80.30]
10 51 ms 51 ms 50 ms lon-b2-pos1-3.telia.net [213.200.77.134]
11 90 ms 84 ms 82 ms ldn-bb1-pos0-1-0.telia.net [213.248.74.1]
12 162 ms 157 ms 205 ms nyk-bb1-pos0-2-0.telia.net [213.248.65.90]
13 164 ms 211 ms 201 ms ash-bb1-pos6-0-0-0.telia.net [213.248.80.69]
14 154 ms 155 ms 170 ms atl-bb1-pos5-0-0.telia.net [213.248.80.142]
15 141 ms 126 ms 140 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
16 122 ms 130 ms 132 ms atl-core-a-tgi2-1.gnax.net [209.51.149.105]
17 154 ms 137 ms 160 ms gig0-1.l3-atl-5.gnax.net [209.51.131.94]
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.

Trace complete.

When things work from home 'line' 18 above becomes identical to line 16 in the tracert from work.

Did you get a useful response from the hosting company ?

Needless to say I got no response to the email I sent to my ISP. I have been unable to access UMSF continuously for over a week now. I'll try their phone support next (which I have heard is not good) to see what happens although for this kind of problem email is (or should be) much easier.

Maybe I'll end up switching to another ISP...

Another idea, not to solve but at least to isolate the problem.

Do you have a dynamic IP address? In such a case, have a look at it when you have connection and when you haven't. I'm wondering if it could be something related to blocked addresses or routing issues.

There are 5 blocked IP addresses currently, for people, how shall we put this, 'unwilling to participate in an mature and acceptable manor'

They are ( with the end two numbers removed for privacy )

24.88.something
69.141.something
61.11.something
61.17.something
65.121.something

If they coincide with anyone who's having trouble - I'll unblock and see what happens.

Doug

I have the same problems: It works at work, it doesn't at home. I have no idea what to do.

Analyst

Same problem here. I read UMSF at work while eating dinner each evening. At home, on AOL, I have no luck signing on. It hasn't always been this way. When I first discovered UMSF last September I would read from home, and bookmarked it as one of my "favorites". But now I have virtually given up trying to get home access. But after reading this thread I tried again yesterday, and this morning and could not sign on from home.

David

I would be very interested in seeing a 'tracert' from those who cannot access UMSF from home (like me). For those who don't know what I'm talking about, in Windows simply open a Command Prompt (aka 'DOS Prompt') and type the following:

tracert www.unmannedspaceflight.com

Then post the result here (and needless to say, do this from a machine that cannot access UMSF).

You should get something that looks like what I posted in http://www.unmannedspaceflight.com/index.p...opic=2170&st=28

If it ends as my tracert (at gig0-1.l3-atl-5.gnax.net [209.51.131.94]) it might be time for Doug to complain to the company hosting UMSF because in that case it looks (to me at least) that someone is (probably inadvertently) preventing some specific traffic from reaching UMSF.

tracert's people - tracert - then I can submit them to the hosting firm - lets find a common trouble-'node' and figure it out

Doug

I will do, now I know what you're talkig about "tracert". But it's friday, I won't be at work before monday. Doug please post an e-mail adress or send me a PM with the adress. I will send you the "tracert" from home. I can't otherwise, it's the nature of this problem.

Analyst

Yup - please do - doug@rlproject.com


D

Any news? I have sent you a tracert, Doug.

There's a common node that's causing trouble, but no news yet.

Doug

Here's what I found on my tracert:

Tracing route to unmannedspaceflight.com [72.9.234.170] over a maximum of 30 hops:

1 * * * Request timed out.
2 48 ms 47 ms 47 ms iptfarma-rtc-ve3.proxy.aol.com [152.163.104.30]
3 48 ms 48 ms 82 ms wc2-rtc-ae0.router.aol.com [172.30.81.12]
4 48 ms 48 ms 48 ms dar2-rtc-ge-4-0-0.net.aol.com [172.31.9.65]
5 49 ms 48 ms 48 ms pop2-vie-P2-0.atdn.net [66.185.145.9]
6 49 ms 49 ms 48 ms bb2-vie-P1-0.atdn.net [66.185.139.130]
7 48 ms 48 ms 48 ms pop1-vie-P1-0.atdn.net [66.185.139.83]
8 139 ms 53 ms 48 ms Level3.atdn.net [66.185.139.86]
9 49 ms 49 ms 49 ms ae-2-52.bbr2.Washington1.Level3.net [4.68.121.33]
10 61 ms 62 ms 61 ms as-2-0.bbr1.Atlanta1.Level3.net [64.159.1.1]
11 62 ms 62 ms 61 ms ae-12-51.car2.Atlanta1.Level3.net [4.68.103.3]
12 61 ms 62 ms 61 ms 4.78.210.6
13 67 ms 80 ms 79 ms 209.51.149,101
14 62 ms 62 ms 62 ms 13-atl-5.gnax.net [209.51.131.98]
15 62 ms 62 ms 62 ms star.dnsprotect.com [72.9.234.170]

Trace complete.

That note about "Request timed out" certainly doesn't look good. But I will leave it to the computer experts to decipher the problem.

David

Hmmm... this looks like a trace from a computer that can access UMSF.

Any news yet ? I still cannot access UMSF from home.

Nothing - they've said they're investigating it, but because the vast majority are having no trouble at all, they're working hypothesis is that it isnt their end, it's elsewhere.

Doug

I've submitted 3 more tracert's to the host. Flicking between my internet connection and a neigbours internet connection ( Plunet ADSL and NTL Cable ) - mine works, the neigbours doesnt. Who know how many people have just given up on the place - and the coincidence of this problem first appearing with a drop in total visit numbers for Feb is too much to leave un-attended - so I'm going to keep hacking at the hosting firm till they correct it.

Doug

This is great news. I contacted my ISP and (as I was sure of beforehand) apparently no problem on their end. The person I spoke to even was able to access UMSF. Even though this doesn't prove anything I am sure the problem is not with my ISP. UMSF is the only website I have had problems accessing from home and I visit lots of websites regularly. Also I am not the only one having this problem.

BTW this problem has persisted for over a month now. For the first 10 days or so there were intermittent brief periods when I was able to access UMSF from home but this problem has been continuous from roughly February 10.

Have you tried using a proxy server to work around the problem?

Yes - it works but it's much slower than accessing UMSF 'directly'.

I'm told there's a huge number of public proxies out there and that they can even be searched for. Maybe you just stumbled across a bad one?

I don't think a proxy server is the way to go with a website which is really the front end of a database - it just adds time to the whole exercise. What *might* help more is another DNS address, in case the IP isn't being properly resolved (and if that's happening across multiple - different - DNS addresses then it surely must be Doug's hosting company which is at the root of the problem). Alternatively, you might try playing with your Hosts settings...

Here are a bunch of proxies anyway:

62.254.32.6
62.254.32.7
62.255.32.6
62.255.32.7
62.255.32.8
62.253.64.6
62.253.64.7
62.253.64.8
62.253.64.9
62.255.0.6
62.255.0.7
62.255.0.8
62.253.128.6
62.253.128.7
62.252.32.6
62.252.32.7
213.107.224.6
80.3.160.5
62.253.0.6
62.252.0.6
62.252.96.6
62.252.224.6
62.252.224.7
62.252.224.8
62.252.64.6
62.252.64.7
62.252.64.8
62.252.192.6
62.252.192.7
62.252.192.8
62.252.192.9
62.252.192.10
62.254.64.6
62.254.64.7
62.254.0.6
62.254.0.7
62.254.0.8
62.254.0.9
62.254.0.34
62.254.0.36
62.253.32.6
62.253.32.7
62.254.128.6
62.254.128.7
62.255.64.6
62.255.64.7
62.252.128.6
62.252.128.7
62.252.128.10

Bob Shaw

i'm gonna add this to the this thread as it is an access problem:

since the most recent invision update UMSF crashes safari on my mac, and i mean all the time. nothing else (and i get throught a lot of other stuff) crashes safari but UMSF.

i'm currently running osx 10.3.9 (yes yes i know i need to get 10.4) and safari version: 1.3.2 (312.5).

anyone else having this problem?