Bad link, joemike; I can't even get iogear.com to open from a Google link.


Edit - This was originally a reply to joemikeb in USB Hub Bub.

works for me
http://www.iogear.com/product/GUH420/

I'm unable to access IOGEAR with any URL.

Safari 4 v 3 (that I'm still running)?

I dunno.

Works for me in Safari 4.0.2.

works for me, too. clear your cache, artie?

silly assumption: since the IOGear hub has both FW and usb, I assume you have to have both plugged in to make them work?

FWIW, I'm having the same problem as you have, working from a WiFi hotspot overlooking Fistral Beach. Although this setup limits my options, I can traceroute iogear just fine, and emptying Safari's cache doesn't help either.

I still can't access iogear.com from either Safari (Yep...cleared its cache.) or Firefox.

1. Ping has started ...

ping: cannot resolve iogear.com: Unknown host

2. Traceroute has started ...

traceroute: unknown host iogear.com

3. SDSC Traceroute Output

FROM www.sdsc.edu TO iogear.com at Sun Aug 23 23:51:08 PDT 2009.
traceroute: unknown host iogear.com

4. On the other hand, though:

Traceroute from www.socket.net to 216.73.102.159 (iogear.com)
traceroute to 216-73-102-159.ocdc-01.net (216.73.102.159), 30 hops max, 40 byte packets
1 fw1.como.socket.net (216.106.88.148) 2.121 ms 2.092 ms 2.066 ms
2 rtr1.office.socket.net (216.106.32.1) 2.334 ms 2.374 ms 2.968 ms
3 atm1kcmo-rtr1office (216.106.23.105) 27.973 ms 30.818 ms 27.264 ms
4 gw2.kcmo.socket.net (216.106.6.82) 37.551 ms 27.975 ms 28.854 ms
5 97.65.172.221 (97.65.172.221) 119.845 ms 29.905 ms 107.837 ms
6 peer-02-so-0-0-0-0.chcg.twtelecom.net (66.192.244.20) 39.799 ms 44.432 ms 39.930 ms
7 xe-0-0-0.lax20.ip4.tinet.net (89.149.185.178) 86.756 ms 86.049 ms 91.933 ms
8 wbs-gw.ip4.tinet.net (77.67.69.102) 85.873 ms 82.973 ms 84.886 ms
9 66.78.0.254 (66.78.0.254) 84.898 ms 83.470 ms 86.794 ms
10 216-73-102-159.ocdc-01.net (216.73.102.159) 83.941 ms 95.058 ms 89.039 ms

Can anybody make any sense out of all that?

Thanks.

FWIW, I resolved my problem by running DNS Flusher. I can't say for sure if that was the hangup, but things look OK again.

If that won't work for you, take a look at your network and router settings (DNS, proxies).

> FWIW, I resolved my problem by running DNS Flusher.

Thanks! That turned the trick.

Off-topic: Will you please explain precisely, or, as the case may be, vaguely, why?

Seems odd that your being ported to Amsterdam from Time Warner twtelecom.net (66.192.244.20 for a server in L.A.
7 xe-0-0-0.lax20.ip4.tinet.net (89.149.185.178) 86.756 ms 86.049 ms 91.933 ms
8 wbs-gw.ip4.tinet.net (77.67.69.102) 85.873 ms 82.973 ms 84.886 ms

I appreciate your having taken the time to read and post, but what did you say?

DNS queries are cached, like browser pages. While such caching is intended to speed things up, caches can also get 'stuck' and prevent refreshing when necessary, even when you've got alternative DNS addresses listed. When a previous query's result is no longer valid*, its continued use yields the error we got: time for a flush.

*) This problem tends to happen more frequently with wireless users who switch hotpoints.

Thanks for the clear, concise explanation.

Out of curiosity, alternaut, was our both running into the same DNS problem at the same time and with the same website just an unlikely coincidence, or is there maybe some common link?

Thanks.

Artie your trace route traveled on a Time Warner Backbone (twtelecom.net) and then went to ( Amsterdam (tinet.net) to get to a server in L.A.

To be more specific it went onto the RIPE.NET and on to Germany.

Whois has started ...

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag.

% Information related to '89.149.185.0 - 89.149.185.255'

inetnum: 89.149.185.0 - 89.149.185.255
netname: NACNET-EU
descr: Tiscali International Network B.V.
descr: Robert-Bosch-Str. 32
descr: D-63303 Dreieich
country: DE
admin-c: SE33-RIPE
tech-c: TIS333-RIPE
status: ASSIGNED PA
mnt-by: TISCALI-INT-NET
source: RIPE # Filtered

role: Tiscali International
address: Tinet SpA
address: Hugenottenallee 167
address: 63263 Neu-Isenburg
address: Germany
phone: +49 6102 8235381
fax-no: +49 6102 8235389

Try more traces and see where it takes you.

Hi, sandbox.

I certainly appreciate your taking the time to respond, but, as with your last post to me, I haven't got the foggiest idea what you've said.

I can't even tell If your latest post is responsive to my latest question.

Enough with the off-topic questions already. I've pulled this branch out of sandbox's USB Hub Bub and given it a new subject. Will update the subject of each reply later today and then move this thread to the Networking forum in a day or two.

To some extent I'm guessing here, but the common link likely was the derailed caching of DNS data, since others reported above that they could access the Iogear site without a problem. I suspect that the DNS caching mechanism used is subject to interactions with data cached that affect its normal turnover and may lead to a 'stuck' cache.

If correct, this may explain why certain sites could be more prone to this, although the cache 'usage context' of the issue likely also is a factor. But beyond switching wireless hotpoints (which only increases the occurrence of the already existing possibility of this happening), I cannot add any hard information about exactly what caused our problem.

Thanks for responding. (I'll understand all of this some day... Maybe.)

> Enough with the off-topic questions already.

Am I supposed to stop thinking just because two lines of discussion are intertwined, cyn?

No. You're supposed to think of your fellow FTMer, sandbox, whose thread about issues with a USB hub you turned into a thread of your own about DNS caching.

Following your assertion that joemikeb's link to iogear was "bad," there was a flurry of posts in which several of us noted that we could connect to that site without issue. At this point, one might argue, a member sensitive to another poster's needs would've started his own thread, instead of escalating what was now clearly an off-topic issue into equal billing by posting the output of traceroute and asking for help interpreting it.

The two lines of discussion were never logically intertwined; they were only physically interwtwined because you didn't choose to separate them by starting your own thread on your own issue. Remember, if the fact that the issue arose in another thread feels like a relevant part of the story, you can always link to the original thread in the opening post of the new thread.

Nobody is trying to squelch your intellectual curiosity. As we all know, quite a bit of the collective wisdom here or anywhere else originates as side effects from other lines of inquiry. But since our primary mission is to provide troubleshooting help to those who seek it—and the help-seeker's thread is the vehicle by which that's carried out—we need to pursue those side effects in ways which don't undermine that mission. We routinely discourage new posters from piggybacking onto someone else's different-but-thematically-related topic; why should long-time members not respect that prohibition in cases in which there's not even a thematic connection?

OK... Perhaps I was remiss in not starting a new thread, but, too, "one might argue," a Mod "sensitive to a(nother) poster's needs" and call of duty could reasonably have been expected to have stepped in and separated the two lines of discussion when I failed to do so.

And, further, alternaut's posting the same problem as I had posted and a solution that worked for both of us turned the off-topic issue into a completed troubleshooting thread - problem...solution - in and of itself, and again you Mods failed to split it off.

Consequently, when I decided to pursue the matter further I had little alternative to doing so in the original thread where it was left sitting.


And (since we're on the subject), by the same token, the two lines of discussion in this thread, "Opening PDFs In Safari Window" and "Should a test user account be Admin or Standard," are "only physically interwtwined because you didn't choose to separate them by starting your own thread on your own issue." (And when I clicked on "Notify" and asked whether the line of discussion should have its own thread, and which I still feel strongly would be appropriate, I was ignored, and, as a result, a topic that would probably be of interest to our troubleshooters is languishing!)



A little consistency would be in order and might help to alter my impression that you guys are beginning to remind me of the board of directors of a co-op.

dkmarsh's "escalating what was now clearly an off-topic issue into equal billing by posting the output of traceroute and asking for help interpreting it" just coalesced in my head, and I now see that a second apology is in order, sandbox...

I posted that traceroute only to see if it included any info that might help explain my inability to connect to IOGEAR, not because I wanted it translated into English, thus the reason I didn't understand your two responding posts... You were answering a question I didn't know I'd asked.

Now that I understand what happened I understand your posts and thank you for taking the time to respond.