Unable to TCP connect by hostname

I’ve seen other threads regarding this issue, but most are somewhat old, referring to older firmware versions, or not specifically the Photon. I’m able to make (http) tcp connections by IP address to remote hosts over the internet. However, when I use a hostname, the connection always fails.

WiFi.resolve("hostname"); 
WiFi.dnsServerIP();

both return 0.0.0.0. I tried to setStaticIP/useStaticIP, supplying my own DNS server, but it didn’t stick.

Any ideas? What’s the current word on this issue?

Thanks!

It appears to work for me. Here’s the code I used:

#include "Particle.h"

unsigned long lastCheck = 0 - 25000;

const char *hostnames[5] = { "google.com", "www.facebook.com", "community.particle.io", "notavalidhost.example.com", NULL };

void setup() {
	Serial.begin(9600);
}

void loop() {
	if (millis() - lastCheck >= 30000) {
		lastCheck = millis();

		for(size_t ii = 0; hostnames[ii]; ii++) {
			const char *hostname = hostnames[ii];

			IPAddress addr = WiFi.resolve(hostname);
			if (addr) {
				Serial.printlnf("resolved %s: %s", hostname, addr.toString().c_str());
			}
			else {
				Serial.printlnf("did not resolve %s", hostname);
			}
		}
	}
}

And the serial log:

resolved google.com: 172.217.5.14
resolved www.facebook.com: 173.252.90.36
resolved community.particle.io: 52.3.160.21
did not resolve notavalidhost.example.com

Not resolving for me:

did not resolve google.com
did not resolve www.facebook.com
did not resolve community.particle.io
did not resolve notavalidhost.example.com

Perhaps something particular about my WiFi network. I’ll continue to investigate.

Hi @jonlorusso

The static IP setting is very sticky and must explicitly be turned off with WiFi.useDynamicIP(); in order to go back to DHCP.

I would make sure of your IP address before trying much else.

3 Likes

I moved closer to the router, and made sure it’s using a dynamicIP. I’ve gotten it to successfully resolve a single IP:

did not resolve google.com
resolved www.facebook.com: 31.13.65.36
did not resolve community.particle.io
did not resolve notavalidhost.example.com

did not resolve google.com
did not resolve www.facebook.com
did not resolve community.particle.io
did not resolve notavalidhost.example.com

But never more than once (and the same hostname it successfully resolves seems to be quite random).

Hi @jonlorusso

Well, that’s good progress! Can I ask if your DNS setup is complex? Most people use their router/access-point as their DNS server, but other configurations are possible. There have been problems in the past with multilevel DNS server setups.

I am using my router as DNS as well. Actually it’s my DSL modem that passes back its own IP (192.168.0.1) as part of the DHCP lease.

I’m not able to get it to resolve anything any longer.

@bko,

Running a slightly modified version of this, my domain names resolve every time.

–jon

Hi @jonlorusso

Just so we are clear: are you running the sample code I wrote in that thread that uses gethostbyname or are you running @Hootie81 's separate DNS client?

There was problem on the older Spark Core that the MAC address inside the WiFi chip would get messed up and that made DNS not work. I don’t think that can happen on a Photon with its different WiFi module. A lot of the voodoo about what fixed DNS problems was eventually traced back to the MAC issue and writing a new MAC address would fix it (until the next time it broke).

@bko,

I’m using a version of your code that uses gethostbyname. I couldn’t get @Hootie81’s dns client working (there are a few issues, I can’t seem to resolve).

–jon

The timeout for WiFi.resolve() is quite short, 5 seconds, on the Photon. Since the call is blocking I can see why it wouldn’t want to be extremely long, but 5 seconds seems a little short to me. WiFi.resolve() calls inet_gethostbyname() in inet_hal, which calls right into the WICED DNS resolver on the Photon with a timeout of 5 seconds. Also, this means that the DNS resolver is entirely different between the Core, Photon and Electron.

2 Likes

I was looking at this just now and I agree with @rickkas7 assessment that 5 seconds could be a little short.

One other small point: in the test code are you calling gethostbyname() or inet_gethostbyname()?

It makes a big different since the one without the inet_ prefix only compiles for a Core and if you have a Core, we should check your MAC address! If you are compiling for a Photon, I don’t think gethostbyname should compile but I haven’t checked.

1 Like

@bko,

Yes, I’m using inet_gethostbyname since gethostbyname wouldn’t compile. Sorry, I wasn’t clear in my earlier post:

void setup() {
    Serial.begin(9600);
}
void loop() {
    HAL_IPAddress ip_addr;
    network_interface_t t;
    char hostname[] = "www.facebook.com";  //your host name here!
    unsigned long tic = millis();
    int16_t retval = inet_gethostbyname(hostname, strlen(hostname), &ip_addr, t, &t);
    unsigned long toc = millis();
    IPAddress resolvedIP(ip_addr);
    Serial.println("www.facebook.com");
    Serial.println(resolvedIP);
    Serial.println(retval);
    Serial.println(toc-tic);
    delay(5000);
}
1 Like

So I spoke a bit too soon, when I modified the test to output the IP for multiple domain names, it works for the first two, but then proceeds to output the second IP for all subsequent requests:

facebook.com
198.105.254.20
docs.particle.io
8.10.8.21
www.google.com
8.10.8.21
reddit.com
8.10.8.21
facebook.com
8.10.8.21
apple.com
8.10.8.21
www.microsoft.com
8.10.8.21

In my use case I actually only need a single hostname resolved, but it’s still strange.

–jon

OK, none of those are right. I think your ISP is hijacking requests that do not land on host and supplying a “helpful” web address (CenturyLink in the first case) to help you find the host you are looking for.

Something seems wrong in your DNS server. Do other hosts on this router work OK? Can you run the nslookup utility to see what is really happening? In nslookup, use the command set debug and then type a hostname. Note that “facebook.com” is not a hostname but magic converts it to “www.facebook.com” in most cases.