ESP32 Forum

I noticed since upgrading to ESP-IDF v4.0-beta2 from v3.2 that my calls to tcpip_adapter_{get,set}_hostname now fail. The error code for getting the hostname is ESP_ERR_TCPIP_ADAPTER_INVALID_PARAMS and for setting it is ESP_ERR_TCPIP_ADAPTER_IF_NOT_READY, though I can say with confidence that in both cases the error is because p_netif within the IDF TCPIP/LWIP code ends up as NULL.

My code works somewhat as follows:

• Create default event loop and register handler for WIFI_EVENT and IP_EVENT groups

• Code: Select all

  tcpip_adapter_init()

• Code: Select all

  esp_wifi_init(WIFI_INIT_CONFIG_DEFAULT());
  esp_wifi_set_storage(WIFI_STORAGE_RAM);
  esp_wifi_set_mode(WIFI_MODE_STA);
  

  (each statement is error-checked)
• In WiFi/IP event handler:

  Code: Select all

  switch(event_id) {
  	case WIFI_EVENT_STA_START:
  		tcpip_adapter_set_hostname(TCPIP_ADAPTER_IF_STA, [hostname])
  		break;
  	[...]
  }
  

Am I missing a step here or is it a bug in the IDF? This code worked perfectly fine with v3.2 (except that I had to change the loop handler to use the new esp_event component).

Have a log output at debug log level?

Sure thing

https://privatebin.net/?239d6ac0b61a402 ... GsALbqeBCt

I removed some irrelevant parts and personal log information that had nothing to do with the WiFi subsystem.

I guess it could be because WIFI_EVENT_STA_START dispatches the tcpip_adapter_start to a worker thread and then calls your event handler so it is possible the worker thread hasn't actually created the netif when your function is called. Maybe a retry loop with a vtaskdelay(1)?

I am seeing the same problem, however it was intermittent. This makes me think there is a timing or race condition causing the problem. At my current app code level though, it is failing every time. I am on the ESP-IDF Pre-release v4.0-beta2.

The correct place to set the host is after start and before connect, so I believe the call is in the right place.

Since the IDF Default-Event-Loop does the event dispatch, the notion of doing a busy-delay in a handler is not a good idea as a solution.

In any case I did try a variety of spin loop counts, with varying delays, and all attempts come back with 0x5002 ESP_ERR_TCPIP_ADAPTER_IF_NOT_READY.

I was able to trim my app down to only the wifi handling and interestingly the host name setting is working At this point the major difference after a number of trim down exercises is running the webserver. Not sure how this changes things but that's the delta between working and not working.