I can access SDMB with Tor, but Chrome times out. Why?

(My question may be complicated, with no clear answer. Mods, feel free to move it to IMHO.)

Perhaps SDMB Internet experts can shed light on my on-going problem. I live in Thailand. I connect to Internet with a directional antenna aimed at a Wifi transmitter 3 km away. Sometimes it works well, sometimes not. I’ll get timeouts from SDMB (as well as some but not all other sites) for a few minutes (“(110) Connection timed out”), then the problem will clear up.

My Wifi provider says the problem is some unknown “router” colliding with our signal. He plans to visit each customer and install some fix on the receiving antennae. This sort of made sense, though I’m so ignorant about Wifi and Internet I didn’t fully understand.

But recently I noticed something strange. I often have a Tor browser (which bypasses Thai government censorship) on stand-by to access dailymail.co.uk and other websites that are banned in Thailand. I pointed that browser at SDMB and … experienced no problem!! It’s not Chrome vs Firefox of course; when the Chrome browser is getting errors from SDMB so is the ordinary Firefox browser. But Tor browsing works fine (subject to Tor limitations) even when other browsers are getting timeouts.

This makes me think the problems have nothing to do with “alleged collisions with an unknown router” and may be caused by overloading of Thai computers responsible for checking Internet packets for blacklists. Any insights from experts? Experimentation may be difficult as the error periods come and go irregularly.

I don’t live in Thailand, but it’s entirely possible that one of the intermediate servers is blocking your access on purpose or by accident. If you go to your terminal (dunno which OS you’re using) you can run a tracert to straightdope.com and see which servers the connection goes through (or dies at).

You might also try using Google’s DNS; sometimes that’s enough to bypass bad ISP nameservers or mild government censorship. Dunno what the Thai will do to you if they find out, but if you’re using Tor already, that’s probably not a concern.

Edit: Slightly longer version is that internet routing does not necessarily seek out the most efficient path, but whatever routes are defined by system administrators. Tor just spreads its tentacles all around, and so you have a higher chance of routing through someone who has a connection to the site rather than whatever the government or ISP imposes on you. You’re trading stability for latency in that case.

I’ll second the DNS suggestion Reply made, though I know nothing about such things. I had a problem with SDMB (and webmail) not loading last week. I took the suggestion made here to change my DNS settings and it’s working fine now.

If either of you are curious, DNS just means “When I type straightdope.com, where should my browser go?” Website servers have numerical addresses, kinda like the street address + apartment number for your house, and DNS servers are just internet whitepages that tell your browse which number belongs to which name. Cheap ISPs have flakey DNS servers and cheap governments use it as a low-investment way to censor sites. Google’s DNS tends to be very reliable, if not always fast as your ISP’s own DNS servers. It’ll often add a second or two to page load times, but that’s probably better than having them randomly time out altogether.

Thailand uses fake error messages when censoring the internet.

It’s possible the SDMB is being deliberately blocked, and you’re seeing one of these. A Connection Timed Out error is similar to the sort of fake message they’ve used in the past.

It’s also possible that it’s a genuine error, perhaps caused unintentionally by the censoring proxy interacting with the board’s intermittent slowness. When you get the 110 error, is there a long timeout delay before it happens?

The delay before timeout is about 25 seconds. I know because I’m experiencing the problem right now – I’m posting this via Tor.

There may be more than one censoring mechanism. When I atttempt dailymail.co.uk I’m redirected to this page which states in Thai that the website has unacceptable content and has been suspended by the Ministry of Information and Communication Technology. (Sometimes instead I get a time-out trying to load that page. :confused: ) I’ve never seen that with SDMB (although sometimes the Wikipedia page for Thailand’s King redirects there!)

Be aware that SDMB usually works fine from the normal browser, but has streaks where it mostly times out. (Right now, a few minutes after I started typing here in Tor, it’s working again.)

I’ve never tried to change DNS server before, but I found a webpage that instructs how to do that. I’ll try it soon, when I’m feeling alert.

Why don’t you just keep using Tor? Or sign up for an American/Canadian/European VPN somewhere where the Thai don’t block?

Most sites work adequately most of the time.

Tor has severe inconveniences – or perhaps I don’t have it configured right. It doesn’t allow tabs; it lacks add-ons, some sites (vidoes?) don’t work at all, I had to re-enter my SDMB password sometimes, etc. etc. Maybe there are workarounds for some of these problems, but the effort would be greater hassle than the problem it would bypass. It’s quite convenient to do 95% of browsing from Chrome and switch, via simple cut-paste, to Tor as needed.

Anyway, I’m curious. Are the timeouts caaued by blacklist-checking bottlenecks?

I’m aware of very few blocked sites right now. They’re no longer blocking Quicktopic and RollingStone. I’d paid no attention to Daily Mail except for occasional links from other sites.

I’ll try the DNS experiment when I’m in a leisurely alert state, and rethink after that.

Yeah, try the DNS thing. If it works, that’d be the easiest work around.

If that fails, Tor is more than just a browser: it’s the network. You can use the Tor network with other browsers, you just compromise security & privacy by doing so. But if you just wanna browse the news and read the Dope, maybe that doesn’t matter much. Again, not sure how the Thai treat people who circumvent their laws for their reading pleasure, but you can try configuring Chrome to work with Tor:

There used to be a simpler 1-click process called “TorButton” for Firefox that did the same thing, but they stopped supporting it. You can look for that too if you want.

If all else fails, just look for “VPN” service. A lot of expats use that to bypass foreign internet filters. They generally cost $5 to $15 a month.

We can speculate all we want, but only you would know by doing a traceroute. If the terminal is too daunting for you, you can try a visual program like this one:

Open Visual Traceroute download | SourceForge.net (Java needed, sadly)

Missed edit. Two other quick workarounds you can try:

You can also try http://anonymouse.org/ for an easy, free proxy or you can also add “nyud.net” to the end of the domain name, like dailymail.co.uk.nyud.net – this pipes it through a global proxy network run by a bunch of universities to study how to make internet routing more resilient.

For me, learning about the Internet and tools (more out of curiosity than real need) is as important as solving my SDMB problem. This and another recent thread have already taught me more than I get with lots of Googling. Thank you, Reply and other Dopers! I hope I’m not wearing out my welcome or abusing GQ.

I’ll the DNS experiment later, but will enclose the results from tracert, some of which seem odd.

Comments:
(1) You’ll note two types of result from SDMB though each leads to “Destination host unreachable.”
The cases where the “unreachable” message occurs immediately (as event 2) are when Chrome is experiencing the time-out errors. The cases where it gets lots of “Request timed out” messages before “unreachable” are when Chrome is accessing SDMB OK! :confused:

(2) The tracert to Google.com has a last line with a ‘th’ country code appended. When I run http://www.ip-adress.com/reverse_ip/54.94.50.182, I’m told the domain is in Brazil with ISP = Amazon Technologies!

BTW, I needed to run www.ip-adress.com/reverse_ip via Tor. On Chrome I got “Invalid Response error was encountered while trying to process the request:” or just “(104) Connection reset by peer” for the domain name by itself. I saw something similar on another IP lookup site.

(3) The final tracert is to a blacklisted site. Perhaps pings are allowed to backlisted; anyway it timed out.

(4) If I get a knock on the door from soldiers wondering why I’m pinging blacklisted websites, I’ll just point them to SDMB and say you guys told me to do it. :stuck_out_tongue:



Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     4 ms     3 ms     2 ms  172.16.0.1
  2  192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     3 ms   112 ms     4 ms  172.16.0.1
  2     *     192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert boards.straightdope.com

Tracing route to boards.straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     3 ms     4 ms     2 ms  172.16.0.1
  2  192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     4 ms     4 ms     4 ms  172.16.0.1
  2     *     192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert boards.straightdope.com

Tracing route to boards.straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     4 ms     2 ms     2 ms  172.16.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *     192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert boards.straightdope.com

Tracing route to boards.straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     2 ms     2 ms     2 ms  172.16.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *     192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert boards.straightdope.com.nyud.net

Tracing route to http.l2.l1.l0.nyucd.net [137.165.1.114]
over a maximum of 30 hops:

  1     2 ms     2 ms     3 ms  172.16.0.1
  2    27 ms    25 ms    24 ms  10.121.65.125
  3    25 ms    25 ms    24 ms  10.121.65.126
  4    36 ms    32 ms    32 ms  mx-ll-110.164.14-187.static.3bb.co.th [110.164.1
4.187]
  5    30 ms    30 ms    34 ms  mx-ll-110.164.14-186.static.3bb.co.th [110.164.1
4.186]
  6    30 ms    31 ms    30 ms  mx-ll-110.164.1-139.static.3bb.co.th [110.164.1.
139]
  7    34 ms    31 ms    34 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8    59 ms     *        *     mx-ll-110.164.0-251.static.3bb.co.th [110.164.0.
251]
  9    58 ms    60 ms    59 ms  1-60-41-175.TWGATE-IP.twgate.net [175.41.60.1]
 10   110 ms   108 ms   109 ms  203.78.187.81
 11   259 ms   237 ms   235 ms  14-60-41-175.TWGATE-IP.twgate.net [175.41.60.14]

 12   234 ms   234 ms   235 ms  sl-st50-pa-.sprintlink.net [144.223.243.81]
 13   242 ms   240 ms   239 ms  sl-crs2-sj-.sprintlink.net [144.232.1.185]
 14   241 ms   239 ms   239 ms  144.232.7.127
 15   246 ms   247 ms   245 ms  144.232.12.42
 16   277 ms   280 ms   277 ms  144.232.11.18
 17   286 ms   284 ms   285 ms  144.232.1.74
 18   294 ms   298 ms   304 ms  144.232.20.186
 19   309 ms   310 ms   307 ms  sl-crs2-spr-0-9-0-0.sprintlink.net [144.232.10.8
1]
 20   307 ms   308 ms   305 ms  sl-gw6-spr-15-0-0.sprintlink.net [144.232.1.9]
 21   312 ms   314 ms   312 ms  sl-crock5-96615-0.sprintlink.net [144.223.76.22]

 22   313 ms   311 ms   311 ms  66.59.57.126
 23   311 ms   335 ms   310 ms  137.165.1.25
 24   328 ms   325 ms   325 ms  planetlab4.williams.edu [137.165.1.114]

Trace complete.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     3 ms     2 ms     2 ms  172.16.0.1
  2     *        *     192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     3 ms     4 ms     2 ms  172.16.0.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9     *        *        *     Request timed out.
 10     *        *        *     Request timed out.
 11  192.168.254.187  reports: Destination host unreachable.

Trace complete.

C:\Users\764>tracert google.com

Tracing route to google.com [182.50.94.54]
over a maximum of 30 hops:

  1     6 ms     2 ms     2 ms  172.16.0.1
  2    27 ms    28 ms    33 ms  10.121.65.133
  3    29 ms    46 ms    26 ms  10.121.65.126
  4    33 ms    32 ms    35 ms  mx-ll-110.164.14-193.static.3bb.co.th [110.164.1
4.193]
  5    33 ms    39 ms    30 ms  mx-ll-110.164.14-192.static.3bb.co.th [110.164.1
4.192]
  6    32 ms    29 ms    30 ms  10.11.253.18
  7    77 ms    42 ms    33 ms  54.94.50.182.static-corp.jastel.co.th [182.50.94
.54]

Trace complete.

C:\Users\764>

C:\Users\764>

C:\Users\764>tracert boards.straightdope.com.nyud.net

Tracing route to http.l2.l1.l0.nyucd.net [128.220.231.5]
over a maximum of 30 hops:

  1     2 ms     2 ms     2 ms  172.16.0.1
  2    25 ms    34 ms    24 ms  10.121.65.125
  3    25 ms    25 ms    62 ms  10.121.65.134
  4    31 ms    35 ms    33 ms  mx-ll-110.164.14-187.static.3bb.co.th [110.164.1
4.187]
  5    29 ms    29 ms    44 ms  mx-ll-110.164.14-186.static.3bb.co.th [110.164.1
4.186]
  6    43 ms    38 ms    29 ms  mx-ll-110.164.1-139.static.3bb.co.th [110.164.1.
139]
  7    44 ms    41 ms    35 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8    73 ms    68 ms    60 ms  mx-ll-110.164.0-129.static.3bb.co.th [110.164.0.
129]
  9   271 ms   268 ms   251 ms  mx-ll-110.164.0-85.static.3bb.co.th [110.164.0.8
5]
 10   244 ms   237 ms   244 ms  xe-4-1-0.bar1.SanFrancisco1.Level3.net [4.35.160
.121]
 11   237 ms   238 ms   257 ms  ae-0-11.bar2.SanFrancisco1.Level3.net [4.69.140.
146]
 12     *        *        *     Request timed out.
 13     *        *        *     Request timed out.
 14     *        *        *     Request timed out.
 15     *        *        *     Request timed out.
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.
 19     *        *        *     Request timed out.
 20     *        *        *     Request timed out.
 21   335 ms   343 ms   325 ms  ae-4-4.car2.Baltimore1.Level3.net [4.69.134.106]

 22   329 ms   329 ms   347 ms  JOHNS-HOPKI.car2.Baltimore1.Level3.net [4.59.246
.2]
 23   356 ms   458 ms   338 ms  addr162129253110.testippl.jhmi.edu [162.129.253.
110]
 24     *        *        *     Request timed out.
 25   357 ms   345 ms   318 ms  planetlab4.cnds.jhu.edu [128.220.231.5]

Trace complete.

C:\Users\764>tracert en.wikipedia.com

Tracing route to en.wikipedia.com [198.35.26.96]
over a maximum of 30 hops:

  1     4 ms     2 ms     7 ms  172.16.0.1
  2    27 ms    25 ms    25 ms  10.121.65.125
  3    50 ms    34 ms    24 ms  10.121.65.134
  4    32 ms    31 ms    31 ms  mx-ll-110.164.14-187.static.3bb.co.th [110.164.1
4.187]
  5    30 ms    47 ms    32 ms  mx-ll-110.164.14-186.static.3bb.co.th [110.164.1
4.186]
  6    30 ms    32 ms    31 ms  mx-ll-110.164.1-5.static.3bb.co.th [110.164.1.5]

  7    35 ms    36 ms    39 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8    60 ms     *       73 ms  mx-ll-110.164.0-251.static.3bb.co.th [110.164.0.
251]
  9    59 ms    60 ms    77 ms  xe-0-0-0-6-101.r00.sngpsi02.sg.bb.gin.ntt.net [1
16.51.17.189]
 10    60 ms    73 ms    75 ms  ae-1.r20.sngpsi05.sg.bb.gin.ntt.net [129.250.3.1
46]
 11   249 ms   230 ms   238 ms  ae-3.r20.snjsca04.us.bb.gin.ntt.net [129.250.3.4
8]
 12   278 ms   240 ms   239 ms  ae-1.r01.snjsca04.us.bb.gin.ntt.net [129.250.4.2
07]
 13   231 ms   238 ms   231 ms  xe-0-7-0-11.r01.snjsca04.us.ce.gin.ntt.net [129.
250.204.6]
 14   239 ms   262 ms   239 ms  text-lb.ulsfo.wikimedia.org [198.35.26.96]

Trace complete.

C:\Users\764>tracert dailymail.co.uk

Tracing route to dailymail.co.uk [195.234.240.212]
over a maximum of 30 hops:

  1     2 ms     3 ms     2 ms  172.16.0.1
  2    29 ms    27 ms    31 ms  10.121.65.133
  3    26 ms    26 ms    26 ms  10.121.65.134
  4    57 ms    31 ms    39 ms  mx-ll-110.164.0-201.static.3bb.co.th [110.164.0.
201]
  5    30 ms    34 ms    30 ms  mx-ll-110.164.0-140.static.3bb.co.th [110.164.0.
140]
  6    36 ms    30 ms    30 ms  mx-ll-110.164.1-65.static.3bb.co.th [110.164.1.6
5]
  7     *       37 ms    33 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8     *       80 ms    58 ms  mx-ll-110.164.0-251.static.3bb.co.th [110.164.0.
251]
  9   349 ms   226 ms   226 ms  mx-ll-110.164.0-219.static.3bb.co.th [110.164.0.
219]
 10   242 ms   226 ms   225 ms  prs-b5-link.telia.net [213.248.81.93]
 11   232 ms   232 ms   232 ms  prs-bb1-link.telia.net [62.115.138.120]
 12   238 ms   237 ms   242 ms  ldn-bb1-link.telia.net [80.91.247.35]
 13   275 ms   240 ms   272 ms  ldn-b5-link.telia.net [80.91.246.145]
 14   240 ms   241 ms   249 ms  ldn-tch-i1-link.telia.net [80.91.250.210]
 15   250 ms   255 ms   249 ms  internap-ic-121223-2-ldn-tch-i1.c.telia.net [213
.248.75.210]
 16   252 ms   308 ms   258 ms  border5.po1-20g-bbnet1.lon.pnap.net [212.118.240
.40]
 17   348 ms   254 ms   266 ms  anmedia-200922-gw.lon.border5.lon.pnap.net [212.
118.240.202]
 18   273 ms   249 ms   251 ms  195.234.242.72
 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.



As if to taunt me, I get “The system returned: (113) No route to host” when I click “Preview Post” just now. I’ll try again; if unsuccessful Post via Tor.

On retry I got the more common “(110) Connection timed out.” Posting via Tor…

You’re welcome. I don’t think anyone minds. We answer what we can. You’d probably get more complete, in-depth answers on something like AskSlashdot or StackExchange’s network engineering, though.

Hmm. It looks like they are dropping a lot of traceroute packets, probably on purpose. Don’t worry, it happens from the US too. Most sites block pings as a matter of course now, but I didn’t realize they were blocking other packets too, rendering tracert not very useful. Anyway, I’m having better luck with tracetcp, but you’ll need to download that along with the winpcap library.

As a supplement to that, in Chrome, you can push CTRL-SHIFT-I to open the inspector, go to Network, and then load a page. You can look at the headers and such to try and figure out what is going on, but it may or may not tell you much depending on how the pages are being censored. (This will only work if the requests are at least reaching a web server of some sort, rather than just being blocked at a lower network level).

If you want to delve deeper, WireShark lets you view everything your network card is saying, and the responses it gets (or doesn’t), but it takes more learning to understand. For example, you can see the DNS requests going out and you can see if they come back.*

The main thing here is that internet routes are not under your control. The best case scenario with tracetcp is that you’ll eventually hit a certain point after which packets disappear, but all that’ll really tell you is who that server is and maybe where it’s located in the world. Won’t really tell you much about how they’re censoring you, or if it’s on purpose, or why. If you wanna avoid that censorship, use the aforementioned methods. A properly configured VPN is the most reliable because it works on a level that isn’t application-dependent and routes all your traffic, encrypted, through that – making them very hard for governments to block selectively unless they want to block all traffic on certain ports, or all encrypted traffic (most censors don’t do this because it causes too much network trouble).

*You can also do this using the “nslookup” command straight from the terminal. Type “nslookup boards.straightdope.com” to see what your ISP is telling you, and “nslookup boards.straightdope.com 8.8.8.8” to see what Google would tell you if you used their DNS. Wireshark just lets you see that and a lot more, but you have to be able to understand what you’re looking at. I usually don’t.

Too late to run half this experiment without backing up – I’ve just changed to Google’s DNS. So far so good! :slight_smile: I’ll report again after several hours.



Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\764>tracert straightdope.com

Tracing route to straightdope.com [209.104.5.198]
over a maximum of 30 hops:

  1     2 ms     5 ms     5 ms  172.16.0.1
  2    44 ms    33 ms    28 ms  10.121.65.125
  3    32 ms    64 ms    26 ms  10.121.65.134
  4    33 ms    30 ms    32 ms  mx-ll-110.164.14-187.static.3bb.co.th [110.164.1
4.187]
  5    32 ms    31 ms    45 ms  mx-ll-110.164.14-186.static.3bb.co.th [110.164.1
4.186]
  6    29 ms    32 ms    30 ms  mx-ll-110.164.1-139.static.3bb.co.th [110.164.1.
139]
  7    38 ms    43 ms    31 ms  mx-ll-110.164.1-117.static.3bb.co.th [110.164.1.
117]
  8    94 ms    62 ms    61 ms  mx-ll-110.164.0-129.static.3bb.co.th [110.164.0.
129]
  9   238 ms   244 ms   264 ms  mx-ll-110.164.0-85.static.3bb.co.th [110.164.0.8
5]
 10   249 ms   257 ms   261 ms  te0-7-0-33.ccr21.sjc03.atlas.cogentco.com [38.10
4.138.121]
 11   246 ms   244 ms   490 ms  be2000.ccr21.sjc01.atlas.cogentco.com [154.54.6.
105]
 12   264 ms   268 ms   285 ms  be2162.mpd21.lax01.atlas.cogentco.com [154.54.27
.173]
 13   380 ms   270 ms   280 ms  be2332.ccr21.phx02.atlas.cogentco.com [154.54.41
.246]
 14   261 ms   406 ms   264 ms  te3-1.mag01.phx02.atlas.cogentco.com [154.54.24.
145]
 15   262 ms   275 ms   262 ms  te0-0-1-0.nr11.b022559-0.phx02.atlas.cogentco.co
m [154.24.0.50]
 16   372 ms   394 ms   370 ms  38.122.89.162
 17   358 ms   276 ms   266 ms  204.17.58.121
 18   270 ms   315 ms   277 ms  tus6.Login.COM [209.104.1.6]
 19   274 ms   275 ms   275 ms  straightdope.com [209.104.5.198]

Trace complete.

C:\Users\764>nslookup boards.straightdope.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  2001:4860:4860::8888

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Request to UnKnown timed-out



And with Chrome now “working,” nslookup times out. :smack:

SDMB had no trouble at all :slight_smile:
But I started getting Timeouts on other sites, e.g. skepticalscience.com :frowning: If I switch back to “Get DNS automatically”, vice versa. Tor always works.

Since there’s a “primary” and “secondary” DNS server, could I solve it all by using Google’s as one, and whatever my “automatic” DNS server is as the other? How do I determine the IP address of my “automatic” DNS?

And now I’m getting " (113) No route to host" for SDMB via Chrome with Google’s DNS.

Posting via Tor with no problem. :confused: :confused: :smack: :eek: :frowning:

Timeouts are difficult to diagnose at the best of times, and traceroutes are unfortunately not very useful. Your traceroute packets probably do not follow the same route as your web browsing.

I think


ipconfig /all

will list the DNS servers set by dchp.

Update: SDMB started getting timeouts again, despite using Google’s DNS. I know intermittent errors are hard to troubleshoot, but it seemed spooky the way Google’s DNS gave me good SDMB for several hours and then started failing. By running nslookup, I think I found that my “automatic” DNS is 172.16.0.1 – some sort of generic address? I tried listing Google for primary and this one as secondary. That seemed to improve at first, but then, again, things got bad. I’m getting paranoid! (BTW, do I need to change both IPv4 and IPv6? I have been, but didn’t try to figure out the IPv6 version of 172.16.0.1.)

Today things are worse than ever. :mad: Tor browser still works fine, and I’ve been doing much of my browsing from there. (Sometimes getting “Your IP Address is banned” message when I try to post on SDMB – another example of Tor inconvenience.)

Others in Thailand have Internet problems, but symptoms are too variable to know if they relate to mine.

As I said, the Wifi guy thinks there’s an (enemy!?) router colliding with his signal. He knows much more than me, but would that really yield this strange symptom where Tor works fine?

BTW, isn’t there some sort of DNS cache? Why would DNS cause trouble in the middle of a session that repeats the same domain names?

There is, and DNS is probably not what you’re seeing. It was just an easy troubleshooting thing to rule out.

Don’t have any more answers for you beyond “get a VPN”, I’m afraid. Perhaps others have ideas. Good luck!

And the wifi guy is just totally bullshitting you. Network people who have to talk to consumers are usually there for one of two reasons: 1) they don’t know enough to be a proper network engineer with a much higher paying, non-tech-support job or 2) they’re part of some small fly-by-night operation that figures it can retain customers by feeding them plausible-enough bullshit for problems they experience

He’s not part of some fly-by-night operation; he is the operation. He seems eager to help; contracts another young local guy for technical help. And he probably does intend to visit and modify our receiver, an expensive detour if it’s just bullshit.

And I’m pretty sure he’ll let me sit at his computer (i.e. before his flakey Wifi connection to me) and access SDMB from there for an hour or two, to see if I get similar problems. (A better first experiment, I think, would be to take my laptop to his shop and use his Wifi from 10 meters instead of 3 km.) In either case the intermittent nature of the problem will make diagnosis uncertain.

Some months ago, he straightened out a problem which perhaps I should have mentioned. Between our Wifi receiver and a retransmitter is a Dlink box which got hijacked several months ago. I didn’t understand that at the time – we got bogus login page – but he “fixed” it. Googling for a mention just now, I suddenly wonder if an ongoing hijack could be related to my recent problem? :confused: :smack: