Frustrated that I don't UNDERSTAND why my network times out

Below (sorry for the top post) is the old traceroute from yesterday on Microknoppix.

Here is the new traceroute from a few seconds ago. The route is entirely different! Since *UNDERSTANDING* is what we're after, can you give me insight into *how* all of a sudden, the route is so very different (and why it works now)?

Who decides what route my packets will take?

knoppix@Microknoppix:~$ traceroute

traceroute to (85.12.30.227), 30 hops max, 60 byte packets 1 192.168.1.1 (192.168.1.1) 2.940 ms 2.915 ms 5.895 ms 2 67-218-118-85.ridgewireless.net (67.218.118.85) 23.983 ms 23.970 ms 23.953 ms 3 10.50.0.1 (10.50.0.1) 23.935 ms 23.920 ms 23.905 ms 4 10.25.0.1 (10.25.0.1) 33.716 ms 33.701 ms 33.687 ms 5 10.20.0.1 (10.20.0.1) 113.640 ms 127.266 ms 127.251 ms 6 10.0.0.1 (10.0.0.1) 155.135 ms 198.034 ms 198.014 ms 7 69.36.226.193 (69.36.226.193) 77.534 ms 88.951 ms 88.940 ms 8 vl2.core2.scl.layer42.net (69.36.225.130) 101.711 ms 101.700 ms 107.203 ms 9 xe-0-0-0-22.r07.snjsca04.us.bb.gin.ntt.net (140.174.21.101) 111.422 ms 111.419 ms 111.404 ms

10 te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 111.376 ms te0-4-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.10.49) 111.352 ms te0-7-0-32.ccr21.sjc03.atlas.cogentco.com (154.54.11.85) 111.341 ms 11 be2047.ccr22.sjc01.atlas.cogentco.com (154.54.5.113) 111.324 ms 111.311 ms be2000.ccr21.sjc01.atlas.cogentco.com (154.54.6.105) 111.251 ms 12 be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 111.238 ms be2166.mpd21.sfo01.atlas.cogentco.com (154.54.28.69) 58.660 ms be2165.ccr22.sfo01.atlas.cogentco.com (154.54.28.65) 66.012 ms 13 be2132.ccr21.mci01.atlas.cogentco.com (154.54.30.54) 168.366 ms be2135.mpd22.mci01.atlas.cogentco.com (154.54.6.34) 168.350 ms be2133.ccr22.mci01.atlas.cogentco.com (154.54.30.66) 165.709 ms 14 be2159.mpd22.ord01.atlas.cogentco.com (154.54.24.82) 168.316 ms 168.300 ms be2158.mpd21.ord01.atlas.cogentco.com (154.54.7.130) 168.285 ms 15 be2079.ccr21.yyz02.atlas.cogentco.com (154.54.27.182) 139.555 ms 133.671 ms be2138.ccr22.bos01.atlas.cogentco.com (154.54.43.202) 155.781 ms 16 be2090.ccr21.ymq02.atlas.cogentco.com (154.54.30.206) 139.505 ms te0-3-0-1.ccr21.lpl01.atlas.cogentco.com (154.54.31.230) 208.018 ms te0-4-0-3.ccr22.lpl01.atlas.cogentco.com (154.54.44.190) 208.007 ms 17 te0-5-0-6.ccr21.lpl01.atlas.cogentco.com (154.54.87.65) 211.696 ms be2182.ccr21.ams03.atlas.cogentco.com (154.54.77.245) 226.780 ms te0-4-0-6.ccr22.lpl01.atlas.cogentco.com (154.54.44.214) 211.705 ms 18 be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 229.203 ms te0-0-0-4.mag21.ams03.atlas.cogentco.com (154.54.76.190) 310.294 ms be2185.mpd22.ams03.atlas.cogentco.com (154.54.37.105) 310.272 ms 19 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.393 ms te0-0-0-12.mag21.ams03.atlas.cogentco.com (154.54.76.134) 310.218 ms 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.367 ms 20 10ge-2-3.cr1.ams3.baseip.com (149.6.128.198) 305.344 ms 305.321 ms 310.147 ms 21 85.12.30.227 (85.12.30.227) 305.263 ms !X 305.254 ms !X 205.255 ms !X knoppix@Microknoppix:~$

OMG, I'm sorry. I take that back. Unless you are a yoga guru, that was really bad advice.

OK, last bit of advice. You use a wireless ISP. Rainy days, interference from nearby antennas, antenna positioning and a lot of other stuff can cause lags and mess up traceroutes. Since your problems are not linux or freeware related, keep it on alt.internet.wireless And check your antenna AND cables for shorts etc. HTH

"billy" schreef in bericht news:l2vumu$4bj$ snipped-for-privacy@speranza.aioe.org...

"billy" schreef in bericht news:l2vumu$4bj$ snipped-for-privacy@speranza.aioe.org...

Reading all I can of this thread (maybe not all because off my newsserver is not 100% reliable) I followed the diving into the routing and the protocol. AFAIS one cause has been overlooked so far: An intermittend hardware error. To me all results so far point in that direction. Suspect is all hardware between your computer and WISP. Shortest way to find out is exchanging all parts of it one at a time, including cables and power supplies. The logic behind it looks like obvious to me. All that equipment is similar to that of your neighbours but the latter has no problem. Your computer has no problem when using it too. So your equipment itself or the place or way it has been installed may cause that peculiar problem.

petrus bitbyter

It is hard for me to see how a hardware error could cause troubles with ONLY centos.org. Remember that he says that he can browse almost all other web sites, even during the months that he cannot browse centos.org. It is really really hard to imagine some hardware error that would be that selective in its application, and furthermore one that allowed the packets to reach the penultimate link on a long chain and then fail on that final link.

He has certainly been aware of your possibility, but has no idea how that could explain the symptoms. Perhaps you could explain how, even in the wildest of scenarios, this could explain his symptoms. And if it does, how he could figure our WHAT is wrong.

This reminds me of a problem I encountered with a system using a RTL8111/8168B PCI Express Gigabit Ethernet controller.

Every once in a while, it would stop connecting to some sites, while still working for other sites, and I could still use ssh to access the system.

My nephew suggested rebooting the system. I explained, this was a linux system, and wouldn't make any difference. After arguing a bit, I rebooted it to show him, it wouldn't matter. To my surprise, it did clear the problem.

That system is using a 50ft cable to connect to the router. My current guess, is that some packet is getting mangled, some of the time, and when it does, the only way to clear the problem, is to reset the pci device, by rebooting the system.

Restarting the network is not enough. The system has to actually be rebooted. I suggested changing the wiring, and moving the router so a shorter cable could be used, but the owner has chosen to just reboot the system, whenever this happens, typically about every other week. This has been going on for a couple of years now, with multiple kernel updates during that time, and no change in behaviour.

So there are cases where a hardware problem will affect some sites, but not others. Without disassembling the firmware, I have no idea what the nic is doing, so I can only confirm the observed results.

Regards, Dave Hodgins

Well, I agree. It's very hard see how it may happen. Nevertheless, the impossible never happens and hard to see is not impossible. In a situation like this I'd want to rule out the possibillity that the error is caused by my own equipment somehow. It's not only the pure hardware I think about. I consider the firmware a part of the hardware in this equipment. I have some experience maintaining computer equipment and I several times saw unexplainable errors disapear by exchanging parts or equipment that seem to have nothing to do with it.

*If* the cause of the problem has been located in this part of the path, there's a question left that may be next to impossible to answer: How does it happen? As the OP mentioned that's the most frustrating part of the problem.

petrus bitbyter

weird - yup - it times out from my network - and other "online testing sites" - so... ????

Ping - centos.org - 85.12.30.227 --> Amsterdam location Ping -

- 72.232.194.162 ---> ????

So, where does the - 72.232.194.162 come from ?? vs my DNS lookup is showing 85.12.30.227 ??

2 NS1.LAYEREDTECH.COM 72.232.1.236 AUTH 0 ms Received 1 Answers , rcode= PTR: PointerName=www.centos.org,

cname:

Lookup failed after 1 name server timed out or responded non-authoritatively

----------- Here's his traceroute run: knoppix@Microknoppix:~$ traceroute

traceroute to (72.232.194.162), 30 hops max, 60 byte

---------- HopCount IP Address HostName 1 208.123.79.34 net208-123-79-34.static-customer.corenap.com 2 198.252.182.180 aus-core-10-v12.corenap.com 3 24.155.184.106 xe-0-0-2-509.AUSTTXMIM002.aggr09.austtx.grandecom.net 4 24.155.121.76 xe-0-0-0-0.aggr08.austtx.grandecom.net 5 4.30.74.53 ae5-868.edge9.Dallas1.Level3.net 6 4.69.145.200 ae-4-90.edge3.Dallas1.Level3.net 7 4.71.170.6 LAYERED-TEC.edge3.Dallas1.Level3.net 8 * * * * * * 9 72.232.194.162

---------

their TCP/IP world seems messed up somewhere within their DNS records -

That is the correct IP.

That is not the correct IP resolution according to google's DNS.

That is,

resolves to 85.12.30.227 but 85.12.30.227 does not rDNS to

However, 72.232.194.162 rDNS to

which does not resolve to

72.232.194.162

The DNSreport on centos.org says the MX, SOA, WWW, are all OK but the Parent nameservice fails on one dns report but not another.

Parent Failed Parent nameservers centos.org Your NS records at the parent server are:

Failed Nameservers for domain in DNS centos.org Your NS records at your nameservers are:

However, my dig worked OK showing ns1, ns3, & ns4.centos.org and their IPs and all 3 nameservers produced the MXes etc.

The report at mxtoolbox said the ns at the parent was OK, but then the information said it was not. I don't understand this inconsistency in the parent DNS status for centos.org.

YEAH - this is one weird DNS situation - I'd like to find out what eventually turns out to be the problem with the DNS, but this discussion is all over the map with various tangents regarding the orig problem.