Cannot connect to host in C: Hostname not found (11001) on Windows, DNS Problem?
I am trying to use an API that connects to a remote server in C, but I keep having the following error message:
log_message: 15:13:19.489 I [ap:1388] Connecting to AP A3.spotify.com:4070
log_message: 15:13:19.490 E [ap:1324] AP Socket Error: Hostname not found (11001)
log_message: 15:13:19.491 E [ap:3396] Connection error: 4
log_message: 15:13:19.491 I [ap:1388] Connecting to AP A1.spotify.com:80
As you can see with the dates, the error message is instantaneous, so I think something is blocking the messages locally on my computer.
Here is the TCP stream I captured with Wireshark:
30 1.682802 MyLocalIp 193.182.8.15 HTTP Continuation or non-HTTP traffic
31 1.702236 193.182.8.15 MyLocalIp HTTP Continuation or non-HTTP traffic
33 1.901706 MyLocalIp 193.182.8.15 TCP 50222 > http [ACK] Seq=12 Ack=12 Win=251 Len=0
So, according to Wireshark, the first message sent by my computer has an incorrect Header checksum.
I know the host is correct, because when I use the same C API in Java with JNA, I have the following result:
log_message() called:15:46:48.718 I [ap:1388] Connecting to AP A1.spotify.com:4070
log_message() called:15:46:53.769 E [ap:1324] AP Socket Error: Undefined Error 0x4E20 (20000)
log_message() called:15:46:53.770 E [ap:3396] Connection error: 117
log_message() called:15:46:53.770 I [ap:1388] Connecting to AP A2.spotify.com:80
log_message() called:15:46:53.789 I [ap:938] Connected to AP: 193.182.8.12:80
So, here the connection fails on port 4070, which is normal because it is blocked by the company's firewall, and then it succeeds on port 80.
And here is the Wireshark capture for the Java version:
104 6.296125 MyLocalIp 193.182.8.15 TCP 50339 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_PERM=1
107 6.575599 193.182.8.15 MyLocalIp TCP http > 50339 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460 SACK_PERM=1 WS=7
108 6.575732 MyLocalIp 193.182.8.15 TCP 50339 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
109 6.582627 MyLocalIp 193.182.8.15 HTTP Continuation or non-HTTP traffic
110 6.614789 193.182.8.15 MyLocalIp TCP http > 50339 [ACK] Seq=1 Ack=512 Win=6912 Len=0
112 6.714201 193.182.8.15 MyLocalIp HTTP Continuation or non-HTTP traffic
113 6.722057 MyLocalIp 193.182.8.15 HTTP Continuation or non-HTTP traffic
115 6.746484 193.182.8.15 MyLocalIp TCP http &开发者_开发百科gt; 50339 [ACK] Seq=500 Ack=677 Win=8064 Len=0
116 6.750938 193.182.8.15 MyLocalIp HTTP Continuation or non-HTTP traffic
117 6.751093 MyLocalIp 193.182.8.15 HTTP Continuation or non-HTTP traffic
118 6.985366 193.182.8.15 MyLocalIp HTTP [TCP Retransmission] Continuation or non-HTTP traffic
119 6.985416 MyLocalIp 193.182.8.15 TCP [TCP Dup ACK 117#1] 50339 > http [ACK] Seq=787 Ack=544 Win=65024 Len=0 SLE=500 SRE=544
121 7.013666 193.182.8.15 MyLocalIp HTTP Continuation or non-HTTP traffic
124 7.213661 MyLocalIp 193.182.8.15 TCP 50339 > http [ACK] Seq=787 Ack=1803 Win=65536 Len=0
132 7.703708 MyLocalIp 193.182.8.15 HTTP [TCP Retransmission] Continuation or non-HTTP traffic
133 7.721265 193.182.8.15 MyLocalIp HTTP Continuation or non-HTTP traffic
I tried adding the IP 193.182.8.15 in my System32/drivers/etc/hosts file for the hostname A1.spotify.com, A2.spotify.com and A3.spotify.com, but it didnt change anything.
I shut down the Windows firewall and antivirus, it didn't help either.
I tried running this at home without company proxy and firewall, but it was the same (except that on the Java version the service was able to connect on port 4070)
Any idea?
Thanks!
Incorrect header checksums are not critical. Lots of software relies on the hardware re-computation of header checksums so they rarely pre-compute the header checksum in the CPU. Since wireshark grabs the information before it goes to the chip that sends it out the wire, wireshark will report incorrect header checksums with some frequency.
Note that the original error was dealing with host A3, but some of your "proof" that machines were reachable was demonstrated with hosts A1 and A2. Odds are good that these hosts do not share the same IP address, so I would be careful about "setting them all to X.X.X.X" in the hosts file.
Also note that bind clients can be configured to skip over host file entries. I'm not sure that's the case here, but I would look to adding a public name server to the resolv.conf file (or equivalent) and see if you get better results. If the machine you ran on "at home" was the same laptop you used "at work" a bad resolv.conf file would have "traveled with you".
Good luck
You didn't say which networking library you are using. Presumably a 3rd party or internal library.
I'm going to take a wild guess, but I bet your networking library expects IP addresses and not DNS names? Have you tried programming your app to just connect to "193.182.8.15" instead of "a3.spotify.com"? If that works, do a gethostbyname call to resolve the DNS name to IP address.
Here's some other things to try
Type this from the command line:
ping a3.spotify.com
If successful, the result will look something like this:
Pinging a3.spotify.com [193.182.8.15] with 32 bytes of data:
Reply from 193.182.8.15: bytes=32 time=79ms TTL=49
Reply from 193.182.8.15: bytes=32 time=79ms TTL=49
Reply from 193.182.8.15: bytes=32 time=79ms TTL=49
Reply from 193.182.8.15: bytes=32 time=79ms TTL=49
Ping statistics for 193.182.8.15:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 79ms, Maximum = 79ms, Average = 79ms
The output of this program tells me two things.
That a3.spotify.com correctly resolves to 193.182.8.15. No hosts files hacks necessary. (Maybe on your corporate network you do need this).
Since I got valid pings back, that means the host is likely reachable. But some machines are configured not to accept pings, so lack of a ping response it not a definitive answer. What is important to see if ping successfully resolved the hostname.
Now type this from the command line to test connectivity to port 80.
telnet a3.spotify.com 80
(don't have telnet? see below)
Does it "connect" (and jump to a blank screen)? (Press CTRL+] to exit, followed by "quit")
Do the same telnet, except for port 4070.
ping and telnet are quick and dirty ways to test for DNS resolution and IP:port connectivity.
These above commands may not work on your corporate network, because your firewall may require all traffic to go through a proxy. Your browser at work is likely configured to work this way either via auto-detect or by admin install. If this is the case, then your app isn't likely to work on the corporate network - unless your networking library can be configured to use a proxy. (Some network libraries auto-detect or read your browser settings).
To install Telnet Client Click the Start button , click Control Panel, and then click Programs.
Under Programs and Features, click Turn Windows features on or off. If you are prompted for an administrator password or confirmation, type the password or provide confirmation.
In the Windows Features dialog box, select the Telnet Client check box.
Click OK. The installation might take several minutes.
I finally found the solution: Running my program as Administrator solved the problem
精彩评论