Another question for the IT pros...
 

I am using a MS Surface Pro (SP) running Win10. I have the SP configured with their dock and have an ethernet cable plugged directly into the dock/SP. I am using Firefox as a browser.

The problem is when I try to reach motorsportreg.com (MSR) I continually get an error message that the MSR server has timed out. The same thing happens if I use IE as a browser on the SP. And when using both my iPhone and iPad on the condo's wifi the same thing happens using Safari as the browser.

This is the only website that I have tried where this happens and I am on the computer many hours of the day at many different sites.

The interesting thing is that if I turn the wifi off, my iPhone and iPad reach MSR immediately using the local cell provider (Cox, here in the Scottsdale, AZ area). I spoke with MSR yesterday and they assured me that their system is up and running and a colleague in the PHX area said he had accessed MSR just minutes after I told him I was still having problems.

So the question is: what would cause this problem and how do I fix it?

Might be a name resolution issue. Can you reach the server by using it's IP address?

T-Rex

Thanx for your quick response KC911.

I don't know the IP address of MSR; however when I just did a Google search on "what is the IP address of motorsportreg.com" I got a list of results, the first of which was a notice from MSR, dated October 1, 2019, addressing an issue "DNS Server Issues" which as it first paragraph was "Beginning yesterday at 3:00pm Pacific time we began receiving reports of intermittent access problems with MotorsportReg.com. Initially it appeared to be a routing issue but as we worked with our vendors to peel back the layers of the onion we found it was a problem with a DNS server. For a small percentage of our users this made the site unavailable and we are very sorry for the interruption."

So clearly there have been some problems with reaching MSR and the MSR rep I spoke with yesterday was either unaware of this problem from just a couple of months ago or was disingenuous in her answer.

Along with getting the IP address and trying it, run a trace route (tracert.exe) to that name and also the IP address to see what the times for the various hops are and what the last one or two at the website.

Try the whole URL:

https://www.motorsportreg.com/

also https://69.63.143.195

David,
I tried both of those with the same no-joy results, i.e., I get the server timed out error message.

John: I'm afraid that I don't know how to run tracert.exe command.

On your surface, open a command prompt.
Click start and start typing "Command Prompt" until it shows up as something to choose.
At the "C:\>" prompt, type "Tracert www.motorsportreg.com"
Here's part of my result, I'm leaving out the first few hops.

5 2 ms 2 ms 2 ms vaonet-air-gw.direct.airstreamcomm.net [64.33.129.130]
6 3 ms 3 ms 3 ms 10ge2-13.core1.msn1.he.net [216.66.73.241]
7 7 ms 7 ms 8 ms 100ge4-1.core1.chi1.he.net [184.105.65.225]
8 8 ms 8 ms 8 ms level3-as3356.100gigabitethernet6-2.core1.chi1.he.net [216.66.73.246]
9 * * * Request timed out.
10 29 ms 29 ms 29 ms edge-web-ho.ear3.washington1.level3.net [4.59.144.222]
11 235 ms 30 ms 29 ms balt1-c1r4.edgehosting.net [68.169.0.4]
12 30 ms 29 ms 29 ms 69.63.143.195

Trace complete.

Now then, two questions -
Are you married?
How tech savvy is your wife?

She could have blocked motorsportreg.com in your router to keep you home weekends.

Well it doesn't sound like you have a resolution issue.

Since you can get to the server with one service provider (COX) and not the other (condo?), I'm thinking that maybe this is being blocked by the condo SP. Either globally, or at the router as rockfan suggests.

Do you control the router? Do you have any "nanny" filters configured?

Just checking back in....

Don't think DNS resolution has been eliminated for the OP....yet. Keep in mind that ICMP (tracert, pings) are not TCP like the browser traffic....could be port related too.

....pssst....it's DNS ;)....

Good luck!

How would DNS resolution factor in if he tries to hit https://69.63.143.195

I missed that post ;)....bad eyez :)

Ok, I was able to do the Tracert (thanx Rockfan for showing me how to do that) and here is what I got:

http://forums.pelicanparts.com/uploa...1576186214.jpg

I have no idea what this means...

And Mrs. Balloonmeister is not tech savvy. :)

(i got a bad certificate warning when i try to get to that site using the IP or its url)

DNS = Domain Name Server - it translates human readable names to ip address. When you type the domain name in the browser, the system will hit DNS to find the IP address for that name, then go to the IP address. If you enter the IP address instead then it just goes directly to the server with that IP address. This is an extreme simplification of the process but that's the gist of it.

Using different networks will point you to different DNS servers.

Maybe DNS cache is stale. at a command prompt type ifconfig /flushdns and see if the works.

If not at a command prompt type nslookup <website name>

Do this for both your cox network and the other one you mentioned and post your results.

URL loads fine for me. The IP will show bad certificate because the cert is registered to the domain name.

Most likely the router/firewall at your site/home blocking it. If it works on cell, but not on your wireless it's probably a local setting on wireless or firewall

This is correct.

The internet is like a road system with turns, on and off ramps, etc....

The mobile devices when off WIFI are driving to the destination from a different starting point so they are taking different roads.

The condo WIFI takes OP on a route that has a bridge out.

He can try changing the DNS his Surface uses from what is most likely the ISP's DNS to to a public DNS like google.

On the Cox network in the condo:



http://forums.pelicanparts.com/uploa...1576204172.jpg

show me the name in 69.63.143.195 . That's right it's not there. That's because I already ''resolved" it for him. 69.63.143.195 IS THE IP ADDRESS OF THE WEB SERVER. https://www.motorsportreg.com/ = https://69.63.143.195

No further resolution is needed. If he can't get to https://69.63.143.195 (which he can't) it's not a DNS problem. Period.

Reread post #6

Sorry the nslookup command in my post should have been nslookup motorsportreg.com. the name was filtered out due to the way I typed it.

As David pointed out again...not DNS....

This time ;)

Having an MS in Cybersecurity and IA, CISSP, GPEN, GCFA, I was able to piece together that the IP address is IP of the server :rolleyes:. I simply didn't see post 6. Having said that you are correct. If he's unable to get to the site via the IP address then it's likely being filtered.

To the OP - I would recommend giving your internet provider a call and see if they can resolve for you. That tracert screenshot should point them in the right direction as to where it's getting blocked.

^^^ LOL....I know what IP and OP mean....so there ;)!

No virtual web server can respond appropriately if you simply hit it via the IP address, as they need the name of the site encoded in the URL in order to decide what content to serve.

The traceroute output doesn't show that he can't hit it with a web browser; what it demonstrates that network hops after a certain point are having ICMP (either requests or replies) filtered, or a router is choosing to drop packets with the ICMP_TIME_EXCEEDED flag set. Very common across network boundaries.

Also, ICMP != TCP. So a failure to get an ICMP response from an IP tells you zip about the state of TCP connections you may (or may not) be able to establish to that same IP or port - the only way is to try to connect using the appropriate protocol and/or ports - eg TCP/80 or TCP/443.

For example: Broadly speaking, "connected" means you can reach it fine via TCP; any error after that is either a server-side configuration issue or a problem with the URL you provided.

A firewall filtering connections most often just times out w/ no handshake.

"connection refused" means a TCP reset was issued; usually means nothing listening on that port at the far end (so issued by the hosts' TCP stack), although sometimes a firewall is configured to reset instead of just quietly dropping packet(s).

[QUOTE=spuggy;10687194]No virtual web server can respond appropriately if you simply hit it via the IP address, as they need the name of the site encoded in the URL in order to decide what content to serve.

At a minimum using just the IP we would have expected an invalid certificate warning. Indicating that he could at least reach the web server and something else was the issue (possibly DNS). The OP got a server timeout using just the IP. The OP also states that all the other websites he goes to work just fine.

Still standing on not DNS.

As stomachmonkey already said - the fact it works on one route and not another indicates a problem specific to the communication path. It looks to me that broadband is Cox address space - so as it works over cell (stated to be also Cox), likely they're messed up in some way for broadband (both networks would typically be almost entirely separate).

Could be any number of things - from name servers caching values from when the DNS *was* screwed up (eg long TTL on either the RR or SOA), to bad routing/filtering.

Bad filtering, bad or asymmetric routing seems much more likely than a cached "bad" DNS response from October, but there's a reason customer satisfaction ratings for cable companies are so low - they're often pretty poor ISP/NSPs.

Agreed. Unfortunately the next step for the OP is to spend 2 hours on hold waiting for a 1st tier support rep to tell him that everything's is fine and it's his DNS. :)

This is true. Although I can hit it using IP address from my network. (comcast)


This is also correct. However, i can tracert to the server and the OP cannot. Since he is the one having the problem that is a good indicator that something is being blocked/filtered or there's some routing issue.

All of this is also correct. However, when the OP tries connecting he gets a server timeout error.

Looking at OP tracert output, his trace route is getting bounced around Zayo network.

OP - try visiting http://69.63.128.6 (I got lucky) and https://www.woodmenlife.org. If you have the same problem with these websites then that's a pretty good indicator there's a routing issue to that network. Then you can tell COX that you cannot access any websites in the range 69.63.128.0/19.

^^^^ (David's DNS post) LOL....I lived in the world of corporate/carrier grade Intranets....at least it was MY mess to figure out :D. I knew I had a DNS issue before anyone back then....

I wuz a busy Pelican so I knew when DNS issues stopped me from browsing forums ...damn....gotta work ;)

Agreed. I'm thinking he may also try calling motorsportreg.org and let them know he cannot access their site from COX network. The issue means more to them than it does to COX as it's less visibility to their site, thus they would be more motivated to have the issue rectified.

Looks like there are others ...

https://forums.cox.com/forum_home/internet_forum/f/internet-forum/24517/website-not-found---only-on-cox

930addict:

I was able to reach the site woodmenlife.org, a life insurance company, thru my SP using Cox internet service in my condo. I was not able to reach the IP address 69.63.128.6.

However, I googled "what website is IP 69.63.128.6?" and got a site and with some sleuthing found that the only domain with this address is getcadrplus.com. I clicked on that link and it opened a website with some info about that domain. However, if I try to put getcadrplus.com in the browser address bar it times out just like MSR.

So, woodmenlife.org worked but that other IP address doesn't work.

I've had to call cox and have them reset my cable router. Rebooting was not enough to clear the issues.

An ICMP issue does not indicate a TCP/IP problem. IP may have an issue that also affects ICMP - but failure of any external network hop to design to talk ICMP to you is not a problem.

Many network operators won't pass ICMP outside their network. Although many NSPs will.

So, you work(ed) for Zayo, are familiar with the internal device naming nomenclature/topology of their network and can thus definitively identify the routing issue there from some number of unidentified nodes that don't respond to public ICMP?

Oh, that's not right? OK.

While it's entirely possible that there is some issue with Zayo, it's also possible that Cox broadband uses that route incorrectly (whereas Cox cellular doesn't), and so one works while the other fails.

However, what the OP's traceroute actually shows is that it goes via LA, Dallas, Houston and then through DC to Baltimore.

My traceroute traverses Level3, transits their edge in Washington before hitting a Baltimore interface belonging to edgehosting.net. So the OP's traceroute that hits Zayo looks perfectly reasonable, and is not "bouncing around" inside Zoyo at all, as far as anyone can tell from that traceroute.

What is probably happening is that edgehosting either aren't accepting connections from Zoyo, or have a bad route for the return packets.

But nothing can really be inferred from 3 hops that don't respond. The ONLY thing you can tell for certain from external hops that don't belong to you and won't return ICMP information is that (a) they're there and (b) they don't want to talk ICMP to you.

It could be a bad route for Cox on the broadband side of the house, but I suspect an issue with edgewebhosting/Zayo is more likely - given that the packets are getting like, right there to Baltimore and not back...

If it were me, I'd probably ask the folks at motorsportreg.com to contact their webhosting company and tell them that their website is broken for packets transiting Zayo from Cox broadband in SoCal.


www.woodmenlife.org is in Toronto when I try it.

Spuggy, et al: One more piece of info for you. I contacted a fellow PCAer here in the PHX area, who is an organizer of an AZ PCA event, of course, they are using MSR for registration purposes, and asked him today if he was using Cox internet in his home when he successfully connects with MSR and he said, yes.

So, he is using Cox internet service, in his home, successfully to connect to MSR and I am using Cox internet service in my condo in the Scottsdale area and cannot connect to MSR. I will call MSR back and relay this information that you have provided and see what they say. It's interesting that at least some other sites are being blocked by Cox also.

I know that. Traceroute is a good tool to start your troubleshooting with and it's available to the OP. While it has limitations it's not a useless tool. Many operators configure their routers to not respond to icmp traffic but they will forward them to the next hop. That's how you get the broken traceroute returns that ultimately get to the destination. It just depends on the network.

The other tools available that can perform TCP scans (like nmap, Hping) require specialized knowledge and so would not be helpful to him. Not to mention that most system owners don't like people scanning their system.

Why the attitude?

And how did you come up with all of that? I never identified an issue. I simply said it was bouncing around Zayo's network. Perhaps I should've said "it certainly looks like it's bouncing around Zayo's network" - probably would have read better. But that was more of a tongue-in-cheek commentary on the number of hops. I work for a 40k user organization in silicon valley - I'm not used to seeing that many hops on our network.

And just for kicks I did an experiment. I think there were 11 hops on the OP trace route - 6 just inside Zayos network. I was able to do a traceroute to a DNS server in Wandsworth United Kingdom in 13 hops (212.118.241.1) with no breaks between routes.

Anyway - the OP trace route shows it leaving OP's home network. Enters and exit COX network at 68.105.30.150 and 64.125.25.122. Enters Zayos at 64.125.25.122 after which all subsequent hits are Zayos:
64.125.29.52
64.125.28.98
64.125.29.48
64.125.30.247
64.125.25.129

So doesn't seem to be an issue with COX. Seems like an issue between Zayos and whatever comes next.

One thing is certain - none of us know what the issue is and none of us are in a position to fix it.

One other certainty is there are some big ego's here judging by the attitudes in some of these posts. Wow. :eek:

Have you unplugged your cox cable modem for 15 minutes, then plugged it back in?

Are you using a separate wifi router? Reset it.

The process is to kill all routing tables that either or both are storing.
May have stored a bad route then their stuff was not routing correctly.

I just drop in to to watch the bit flinging....with popcorn ;)

LOL....I thought it wuz a prerequisite for communications geeks ....mebbe it's just me tho' :D