Tracert Diagnostics

[bdenner]

Last week I had connection problems with TV (TV only I might add as the 6 other forums I login too worked fine). The TV support desk was very helpful and asked me to run ‘Tracert’ to test the routeing through the ISP etc.

This test taken 30th May where I could not ‘Post’ or ‘Preview Post’ on ThaiVisa

Tracing route to thaivisa.com [203.174.84.82]

over a maximum of 30 hops:

1 1381 ms 814 ms 521 ms 10.217.188.190

2 480 ms 478 ms 587 ms 10.217.188.190

3 499 ms 498 ms 529 ms 10.217.188.129

4 * * * Request timed out.

5 * * * Request timed out.

6 * * * Request timed out.

On these results they suggested that I had big connection problems from my end. I use AIS GPRS – OK after a few days everything resolved itself and now I have full access again.

This test was run a few minutes ago where I have full access to ThaiVisa all options are operational. If anything this looks slower:-

Tracing route to thaivisa.com [203.174.84.82]

over a maximum of 30 hops:

1 1558 ms 720 ms 498 ms 10.217.188.190

2 502 ms 515 ms 503 ms 10.217.188.190

3 532 ms 530 ms 604 ms 10.217.188.129

4 * * * Request timed out.

5 * * * Request timed out.

6 *

[cdnvic]

My guess by seeing that is your provider's DNS is/was buggered as it wasn't getting you past it's own domain. Thailand, so far as I can see, has by far the most incompetant technicians when it comes to getting their DNS set right.

I've been sending a lot of people to OpenDNS lately, and for many of them it fixes the problem. Here's the instructions for setting it up on your mobile:

http://www.opendns.com/start/mobile.php

[paveet]

My guess by seeing that is your provider's DNS is/was buggered as it wasn't getting you past it's own domain. Thailand, so far as I can see, has by far the most incompetant technicians when it comes to getting their DNS set right.

How is this a DNS problem when thaivisa.com clearly resolves? DNS doesn't go further than the user's computer resolving (one connection to a DNS server, which appears to be totally successful since thaivisa.com --> 203.174.84.82), once the client knows the IP, it just makes a connection to that IP. Only once the connection has been established between your computer and that IP does your client say what host it's trying to reach (to the destination IP) and thats all in HTTP packets, nothing to do with DNS.

I'm assuming 10.x.x.x is your AIS's internal network (that's how its meant to be setup, it's not really practical to give public IPs to GPRS/3G subscribers)... something's looking funny with that routing... which to me suggests that AIS uses a proxy (in the range 10.x.x.x) for all HTTP outbounds... Do other services apart from HTTP work? POP3/IMAP emails (not webmails like Yahoo! and Hotmail)?

Do the rest of the hops come back as * * * request timed out all the way downwards if you keep leaving the tracert running or does it start returning IPs again after like the 8th hop?

[bdenner]

Thanks for the response. Unfortuneatly my old Nokia 8910i does not give me the option to change the DNS settings, was a great phone in it's day costing me some 28K Baht 4 years ago, although fully functional now gone past it's use by date.

[paveet]

To answer your original question, a tracert gives you a list of the 'path' that your data ('packet') take from your computer to the destination you asked it to (thaivisa.com in this case). These IPs that come up in 1. 2. and 3., etc are routers, they sit between two subnets in order to route (act as a path) between them.

IPs that start with 10.xxx are IANA (Internet Assigned Number Authority) reserved numbers for 'private networks'. What that is, is a network that is not reachable as a whole from the internet (non-routable addresse), i.e. it may be an office network or something, it allows more computers in a network than the number of public IPs (addresses) on the internet that the organisation has. For example, someone's home may have 15 computers but only 1 public IPs, the 15 computers and the router would have an IP in the 'private' range. The router would have 2 IPs altogether, so it has one in the 'public' internet range too. There are a limited numbers of IPs available on the internet, so not everyone can have 15 'public' (internet) IPs.. so they have to resort to using 'private' IPs (this problem should go away in several years when a new standard comes out though).

What the numbers (how many ms) means is how many miliseconds it takes for 32 bytes of data to go from your computer to that IP address and back again. It does it three times per hop so that you can see and diagnose things from that (e.g. if there are great variations between the three numbers then you can tell it's a bad link there or something). But great variations in the numbers over GPRS networks are normal (same thing for satellite). But if you were getting those numbers over an ADSL line, I'd start worrying!

[cdnvic]

My guess by seeing that is your provider's DNS is/was buggered as it wasn't getting you past it's own domain. Thailand, so far as I can see, has by far the most incompetant technicians when it comes to getting their DNS set right.

How is this a DNS problem when thaivisa.com clearly resolves?

The DNS can resolve but if the tables are mucked up you aren't going anywhere. This was happening a lot after the earthquake broke the Taiwan cable and ISPs tried to route around the problem, and it happens all the time when they start screwing around trying to block sites.

[paveet]

My guess by seeing that is your provider's DNS is/was buggered as it wasn't getting you past it's own domain. Thailand, so far as I can see, has by far the most incompetant technicians when it comes to getting their DNS set right.

How is this a DNS problem when thaivisa.com clearly resolves?

The DNS can resolve but if the tables are mucked up you aren't going anywhere. This was happening a lot after the earthquake broke the Taiwan cable and ISPs tried to route around the problem, and it happens all the time when they start screwing around trying to block sites.

Then that's not a DNS problem but a routing problem between different AS'es or even the ISP's private networks.

[cdnvic]

My guess by seeing that is your provider's DNS is/was buggered as it wasn't getting you past it's own domain. Thailand, so far as I can see, has by far the most incompetant technicians when it comes to getting their DNS set right.

How is this a DNS problem when thaivisa.com clearly resolves?

The DNS can resolve but if the tables are mucked up you aren't going anywhere. This was happening a lot after the earthquake broke the Taiwan cable and ISPs tried to route around the problem, and it happens all the time when they start screwing around trying to block sites.

Then that's not a DNS problem but a routing problem between different AS'es or even the ISP's private networks.

Isn't using a third party DNS more likely to help navigate you to your destination in this case though?

[bdenner]

[

... Do other services apart from HTTP work? POP3/IMAP emails (not webmails like Yahoo! and Hotmail)?

All of my other connections have been fully functional through the problems I had with ThaiVisa – POP3 Email, login to other forums, Thai and Aust internet banking, share transactions etc.

Do the rest of the hops come back as * * * request timed out all the way downwards if you keep leaving the tracert running or does it start returning IPs again after like the 8th hop?

Times out all the way to 17 then where it started again but the DOS window closed there and I could not capture it.

[paveet]

I don't think so, because you've already found out the IP (which is correct)... It would help if thaivisa.com resolves to 10.1.2.3 (say) or something more worrying!

DNS does not play any roles in which path you take to a given server as long as the IP resolved from the domain name is already correct..

[cdnvic]

I don't think so, because you've already found out the IP (which is correct)... It would help if thaivisa.com resolves to 10.1.2.3 (say) or something more worrying!

DNS does not play any roles in which path you take to a given server as long as the IP resolved from the domain name is already correct..

Thanks

[paveet]

[

... Do other services apart from HTTP work? POP3/IMAP emails (not webmails like Yahoo! and Hotmail)?

All of my other connections have been fully functional through the problems I had with ThaiVisa – POP3 Email, login to other forums, Thai and Aust internet banking, share transactions etc.

Do the rest of the hops come back as * * * request timed out all the way downwards if you keep leaving the tracert running or does it start returning IPs again after like the 8th hop?

Times out all the way to 17 then where it started again but the DOS window closed there and I could not capture it.

Yeap that goes inline with what you said..

Here are the cases:

If you simply could not load up ThaiVisa at all, it could be a problem with the way AIS routes data to the ThaiVisa server.

If certain pages or objects (images) could not be loaded up from TV then you could also guess that the problem is with poor connections (things timing out) somewhere along the line.

If the pages loaded but with an error message (like could not connect to database), then it's ThaiVisa's problem.

[bdenner]

Thanks guys.

I did believe the support desk when they suggested that the problem was AIS generated but it was purely related to an upload to ThaiVisa. It's just the way the test results are interperated and why the error was related to one site only that has thrown me.

[dsys]

I'm guessing form your pst you are wanting to know how to use this info to trouble shoot. I'm assuming a few things here - Firstly you are using a windows system and secondly its going over a GPRS network not HSDC.

Firstly tracert on windows uses ICMP Internet control message protocol. This protocol is blocked by a lot of firewalls. Trace rt will send out three packets to each of the routers along the path to your destination, it does tis by TTL incrementing.

Here is a brief summary of what your tracert shows:

1 1381 ms 814 ms 521 ms 10.217.188.190 ----> the three numbers with ms after them refer to the "journey time" for each of the packets sent . The ip is well the IP. What does this tell So what does this info tell you, well you generally see you default gateway here.

2 480 ms 478 ms 587 ms 10.217.188.190 --> Now here is where it gets interesting - line two, you are getting your default gateway again on a TTL of 2. Which translates as your default gateway is two hops away, This is really strange - there appears to be a loopback of some sort on your gateway - misconfiguration on the network side here.

3 499 ms 498 ms 529 ms 10.217.188.129 --> Now you are moving to a different router and the path is progressing.

4 * * * Request timed out. --> Now this does not mean that you cannot find a path but you have hit a firewall. If you look closely you will see all the previous IP's are private Class A 10.X.X.X adresses. What you would expect to see here is a public IP address. The same stands for the rest of the hits.

5 * * * Request timed out.

6 * * * Request timed out.

The reason you can connect today and not previoulsy cannot be found from this information alone. The only usefull information we can take from these traces is -

1. You have a possible miconfiguartion on your default gateway - needs further investigation.

2. YOUR DNS server is working as you can resolve the address - perhaps there is a miconfig down the line

3. You ISP uses a firewall for their public IP routing.

If your phone is your default gateway, possible in some situations, you have it setup wrongly, contact your ISP.

If you have a unix bos run a tracert on that - it uses UDPO datagrams instead of ICMP and you may get more usefull info.

[bdenner]

Thanks for this. I don't have many GPRS options on my phone, it's either on or off and the ISP recognition code, in this case it's "Internet".

[Simmo]

If you have a unix bos run a tracert on that - it uses UDPO datagrams instead of ICMP and you may get more usefull info.

You can use "pathping" from a command prompt on windows - uses UDP for the trace.