|Josh, you seem not to have read my post in response #5. I suggest you go back and re-read it. |
Your philosohpy of "dont rule it out till it is tried" is a good one, but only if tempered by experience, logic, and common sense. I could just as easily recommend reinstalling Windows (which, believe me, I have heard people recommend far too often) under the premise that it shouldn't be ruled out as a troubleshooting step until it is tried. By that logic, everything could reasonably be tried as a troubleshooting step. The best way to eliminate the 99.999% of really bad troubleshooting ideas is to gather information about the problem before recommending anything. As I said, I always like to try and understand a problem before randomly throwing solutions at it. Even if those solutions have been known to work in apparently similar situations.
In response to your numbered points:
1) I randomly threw out several hypotheses. I readily acknowledge that a proxy server is the least likely of these. Please reference my response #5: All of that being said - I doubt that a proxy server is in use on the network you found. If it's just somebody's unsecured home network, it is very unlikely that they are using a proxy server. Web proxying takes some effort to implement, and is more likely to be in use on business networks. I would suggest you investigate the DNS issue before worrying about the proxy
1a) Given that the computer in question can ping an Internet host successfuly, I think it would be trivial to determine what ISP the wireless network is connected to, if any. Maybe that's something worth investigating.
1b) You said "this person could have comcast cable, or dsl, there is not proxy a setup there". I have cable internet at my home. I have an open wireless access point. I use a squid web proxy on my network. There is, then, possibly a proxy set up on the network RLP's sister-in-law found.
2) I don't know if this machine has the same problem on other networks, as stated in my response #10.
3) Applying random "fixes" to a problem is, at best, a way to further obfuscate the source of the problem. If you get lucky and winsockfix somehow "fixes" the problem, what does that tell you? Unless you know exactly what winsock does, and the possible cascading results, it tells you nothing. Since you propose running winsockfix only because you "could see it possibly fixing this issue" I can only assume that you do not know exactly what it does. That is, in my opinion, scattershot troubleshooting.
All that being said - this is devloping into an argument, which is pointless. Winsockfix almost certainly won't make things worse, so let's try it. If it succeeds in solving the problem, we can assume that the source of the problem was on RLP's local machine. If it doesn't fix the problem - well, we haven't learned anything further about the problem so we're basically back where we started. Which is, as I was trying to point out, in an unknown state of connectivity on a foreign network. Exploration of the network would be, in my opinion, the best course of action at this point.
Short version: Let's run winsockfix and hope it works!