"[HTTP] GET... failed, error: connection refused" when using Static IP

PlatformIO IDE
1

Hardware:

Board: ESP32 DEVKIT1
Core Installation version: 1.0.1-git this one
IDE name: PlatformIO IDE
Flash Frequency: 80Mhz
PSRAM enabled: no
Upload Speed: 921600
Computer OS: Linux Mint 19.1 Mate

Hello there !

I’m having troubles receiving the response from a URL when using Static IP. All works perfectly fine using DHCP IP.
I assume the ESP32 connects to the internet because I can access the webpage (which has a HTML input form where one can enter the URL) using the Static IP.

Long story short I am reading lines from a SPIFFS file and storing them in an String array x[].

void setup () {
  if(x[0] != NULL &&      // SSID
     x[0].length() != 0 &&
     x[1] != NULL &&      // Password
     x[1].length() != 0 &&
     x[2] != NULL &&      //Local IP
     x[2].length() != 0 &&
     x[3] != NULL &&      // Gateway
     x[3].length() != 0 &&
     x[4] != NULL &&      // Subnet
     x[4].length() != 0) {
       IPAddress local_IP_STA, gateway_STA, subnet_STA;
       local_IP_STA.fromString(x[2]);
       gateway_STA.fromString(x[3]);
       subnet_STA.fromString(x[4]);
       IPAddress primaryDNS(8, 8, 8, 8);
       IPAddress secondaryDNS(8, 8, 4, 4);
       WiFi.begin(x[0].c_str(),x[1].c_str());
       delay(50);
       if(!WiFi.config(local_IP_STA, gateway_STA, subnet_STA, primaryDNS))
       Serial.println("Couldn't configure STATIC IP ! Starting DHCP IP !");
       delay(50);
}
void loop() {
if ((WiFi.status() == WL_CONNECTED)) {
HTTPClient http;
http.begin(URL);
      int httpCode = http.GET(); //Make the request
  
      if (httpCode > 0) { //Check for the returning code
          Serial.printf("[HTTP] GET... code: %d\n", httpCode);
          if(httpCode == HTTP_CODE_OK) {
              String payload = http.getString();
              Serial.println(payload);
            }
        } else {
            Serial.printf("[HTTP] GET... failed, error: %s\n", http.errorToString(httpCode).c_str());
          }
  
      http.end();
   } // while
delay(10000);
}

WiFi.config(local_IP_STA, gateway_STA, subnet_STA, primaryDNS) or
WiFi.config(local_IP_STA, gateway_STA, subnet_STA, primaryDNS, secondaryDNS) returns

[E][WiFiGeneric.cpp:658] hostByName(): DNS Failed for jsonplaceholder.typicode.com
[HTTP] GET... failed, error: connection refused

I’ve also moved WiFi.config() before and after the WiFi.begin() but nothing changed.

What do you think the problem is ?

2

And the ... refers to which hostname exactly? Your local server name?

3

The … refers to the URL’s host.

4

So is this an IP or the hostname?

5

I’ve commented among the lines explaining what is what and the names are pretty self explanatory. Or so I’ve thought. I am sorry for any misunderstanding.

  if(x[0] != NULL &&      // SSID
     x[0].length() != 0 &&
     x[1] != NULL &&      // Password
     x[1].length() != 0 &&
     x[2] != NULL &&      //Local IP
     x[2].length() != 0 &&
     x[3] != NULL &&      // Gateway
     x[3].length() != 0 &&
     x[4] != NULL &&      // Subnet
     x[4].length() != 0) {
       IPAddress local_IP_STA, gateway_STA, subnet_STA;
       local_IP_STA.fromString(x[2]);
       gateway_STA.fromString(x[3]);
       subnet_STA.fromString(x[4])

And I’ve written WiFi.config(local_IP_STA, gateway_STA, subnet_STA, primaryDNS)

Here is what’s written inside WiFiSTA.cpp :

/**
 * Change IP configuration settings disabling the dhcp client
 * @param local_ip   Static ip configuration
 * @param gateway    Static gateway configuration
 * @param subnet     Static Subnet mask
 * @param dns1       Static DNS server 1
 * @param dns2       Static DNS server 2
 */
bool WiFiSTAClass::config(IPAddress local_ip, IPAddress gateway, IPAddress subnet, IPAddress dns1, IPAddress dns2)

So, local_IP_STA is the static IP you can set yourself and by which you acces the server that’s on the ESP.

Also, I’ve updated my main post.

6

No, you can only assume that the ESP32 has connected to your router… something could still be wrong in the configuration. i.e. If the gateway is wrong, it won’t talk to the internet (since the gateway IP should be that of your modem/router)… not sure the impact of wrong subnet here.

Why don’t you hard-code the variables for now - get that working, and then fix up the SPIFF file once you know the parameters are correct? Where the local IP and the gateway IP (and subnet if different) are naturally your own…

IPAddress local_IP_STA(1, 2, 3, 4); //.fromString(x[2]);
IPAddress gateway_STA(1, 2, 3, 4); //.fromString(x[3]);
IPAddress subnet_STA(255, 255, 255, 0); //.fromString(x[4]);
IPAddress primaryDNS(8, 8, 8, 8);
IPAddress secondaryDNS(8, 8, 4, 4);

ESP32 example for static IP shows that you should do the config before trying to connect .begin to the wifi access point. Doing it the other way should start up in DHCP and reconfigure to static, which is pointless since you’re allocating all the parameters that DHCP would set.

Do you have any code like …

  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());
  Serial.print("Subnet Mask: ");
  Serial.println(WiFi.subnetMask());
  Serial.print("Gateway IP: ");
  Serial.println(WiFi.gatewayIP());
  Serial.print("DNS: ");
  Serial.println(WiFi.dnsIP());

… just to double check that everything is being configured as you expected?

1 Like
7

Thank you for your reply !

I’ve taken the DHCP’s local IP, Gateway and Subnet and then used those to set up the ESP with Static IP and the HTTP GET worked perfectly. I’ve played with different IPs, but with the same gateway.
I assume now that I didn’t do a proper subnetting.

ESP32 example for static IP shows that you should do the config before trying to connect .begin to the wifi access point. Doing it the other way should start up in DHCP and reconfigure to static, which is pointless since you’re allocating all the parameters that DHCP would set.

I’ve also thought of that being the logical way to do things. First you config then you begin. But, searching for answers to this issue on GitHub, I’ve found replies from users stating that writing begin before config fixed their similar issue.

And yes, I’ve used WiFi.localIP() , WiFi.subnetMask() , WiFi.dnsIP() to check for the settings I was making.

1 Like
8

So I take it you are still having problems? Just wondering as my response was marked as the solution.

And yeah, .begin() and .config() can be annoying… as you say, some people say changing the order works for them… although at times its hard to tell if it was coincidental as they made multiple changes without incremental testing. Just have to try different things and see what finally does work.

1 Like
9

I’ve only tried the Static IP method using the local IP, Gateway and Subnet that the DHCP method sets. I haven’t done any subnetting of my own.

Modifying only the local IP, and keeping the subnet and gateway from DHCP method works.

Let’s say I have

IP address: 192.168.1.104
Gateway: 192.168.10.1
Subnet: 255.255.255.0
DNS: 192.168.10.1

Modifying only the IP address to, lets say, 192.168.1.110 and letting the others as they are works just fine.

1 Like
10

Well, you don’t want to change the subnet unless you know what you are doing, because the subnet basically tells the device how much of the network it can talk to and see… and all devices on the same subnet should the same setting… so in your case, it will talk to anything on 192.168.1.x (since the IP is 192.168.1.104 with a subnet of 255.255.255.0). If you get that wrong, it either won’t talk to anything, or will seem intermittent. Ideally your gateway (modem/router IP) and at least the secondary DNS would be the same, as your modem/router will often do DNS or defer to your ISP, but you could set the primary DNS to something different like 1.1.1.1 (cloudflare) or 8.8.8.8 (google) for speed/reliability.

But it sounds like it’s working now, so all good! :slight_smile:

1 Like
11

Wait a minute… just realised there is either a typo or an issue with your earlier snippet…

Is the IP address 192.168.1.104 or 192.168.10.104… as if it is the latter, all is good, but if it is the former, you’ll need a different subnet mask for that to work. In other words, with a 255.255.255.0 subnet mask, the first three octets really should be the same as the gateway… else that is is most likely what is causing your ESP32 to not see the internet… you can see it, but it can’t talk to the gateway. because 192.168.10.1 is not on the same subnet as 192.168.1.104 when using a 255.255.255.0 mask.

2 Likes
12

I think it’s my bad. It’s actually:

IP address: 192.168.1.104
Gateway: 192.168.1.1
Subnet: 255.255.255.0
DNS: 192.168.1.1
1 Like
13

No problem, just wanted to make sure before it became an issue! :wink: Yeah, that looks more like it! :slight_smile:

1 Like