Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

esp_netif_get_hostname/esp_netif_set_hostname bugs (IDFGH-2663) #4737

Closed
AxelLin opened this issue Feb 9, 2020 · 10 comments
Closed

esp_netif_get_hostname/esp_netif_set_hostname bugs (IDFGH-2663) #4737

AxelLin opened this issue Feb 9, 2020 · 10 comments

Comments

@AxelLin
Copy link
Contributor

AxelLin commented Feb 9, 2020

IDF version: v4.1-dev-2184-g577abc44728c
My test configuration is disable ESP_NETIF_TCPIP_ADAPTER_COMPATIBLE_LAYER.

The bugs

  1. Before calling esp_wifi_start()
    p_netif->hostname is NULL
    The esp_netif_get_hostname() only checks if (p_netif != NULL) but p_netif->hostname can also be NULL.
    Need to test p_netif->hostname as well.
    Otherwise the user may call printf to show the NULL hostname (because the error code is 0) and got
    Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled.

  2. Before calling esp_wifi_start():

    1. calling esp_netif_get_hostname and it return OK
    2. calling esp_netif_set_hostname and set hostname to "MYTEST1"
    3. calling esp_netif_get_hostname and it return "MYTEST1"
    4. calling esp_netif_set_hostname again and set hostname to "MYTEST2"
    5. calling esp_netif_get_hostname and it return "MYTEST2"
      It looks fine above.
      But after calling esp_wifi_start().
      esp_netif_get_hostname() returns "expressif".
      Check the DHCP client list on my AP, it also shows the client hostname is "expressif".
      i.e. the previous esp_netif_set_hostname() does not work at all.
      Then I calling esp_netif_set_hostname again and set hostname to "MYTEST3"
      esp_netif_get_hostname() returns MYTEST3 but the DHCP client list on my AP is still "expressif".

    i.e. esp_netif_set_hostname() has no effect.

This issue is also reported on https://www.esp32.com/viewtopic.php?f=13&t=14160

@AxelLin
Copy link
Contributor Author

AxelLin commented Feb 9, 2020

Add @david-cermak

@AxelLin AxelLin changed the title esp_netif_get_hostname/esp_netif_set_hostname_api bugs esp_netif_get_hostname/esp_netif_set_hostname bugs Feb 9, 2020
@github-actions github-actions bot changed the title esp_netif_get_hostname/esp_netif_set_hostname bugs esp_netif_get_hostname/esp_netif_set_hostname bugs (IDFGH-2663) Feb 9, 2020
@david-cermak
Copy link
Collaborator

@AxelLin Thanks for the report, going to fix the issues!
The actual issue lies in assigning the hostname default value on wifi/ethernet low level init. After the interface is created the API updates the hostname, but would reflect the new settings after reconnection (in the mentioned dhcp client example)

As of now, I might suggest these workarounds:

  • Setup the desired hostname using system configuration parameter LWIP_LOCAL_HOSTNAME
  • Call the API after the low level init, but before connection -- it is possible to unregister the default on-connection event and register a custom one, such as calling the set-hostname() API and then proceeding with standard wifi_default_action_sta_connected().

@beta-tester
Copy link
Contributor

beta-tester commented Feb 22, 2020

@david-cermak Can you please give me a short code example, how to set the hostname?
i can't find a working example for esp_netif.

i have build some sensor boards with ESP32. in the past each sensor board has its own hostname hardcoded in software and the server gives them a specific IP based on their hostname.
in the past i setup the hostname be using:

tcpip_adapter_init();
...
tcpip_adapter_set_hostname(TCPIP_ADAPTER_IF_STA, HOSTNAME);

but recently i upgraded the ESP-IDF (ESP-IDF v4.2-dev-408-g132cc67c0-dirty) and now those functions are marked as deprecated.
with the new mehtod i can not set the hostname.

esp_netif_init()
...
esp_netif_t *esp_netif = NULL;
esp_netif = esp_netif_next(esp_netif);
esp_netif_set_hostname(esp_netif, HOSTNAME);
???

so all my updated sensor boards gets another IP from the server as they got before, because the don't send the expected hostnames anymore.

@beta-tester
Copy link
Contributor

it looks like there is not always "client provides name: ..." available from the ESP.
it is only available at stage DHCPREQUEST.

here the log on the server:

dnsmasq-dhcp[] available DHCP range: 192.168.251.100 -- 192.168.251.250
dnsmasq-dhcp[] DHCPDISCOVER(wlan0) xx:xx:xx:xx:xx:xx 
dnsmasq-dhcp[] tags: wlan0
dnsmasq-dhcp[] DHCPOFFER(wlan0) 192.168.251.101 xx:xx:xx:xx:xx:xx 
dnsmasq-dhcp[] requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
dnsmasq-dhcp[] next server: 192.168.251.1
dnsmasq-dhcp[] sent size:  1 option: 53 message-type  2
dnsmasq-dhcp[] sent size:  4 option: 54 server-identifier  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option: 51 lease-time  infinite
dnsmasq-dhcp[] sent size:  4 option:  1 netmask  255.255.255.0
dnsmasq-dhcp[] sent size:  4 option: 28 broadcast  192.168.251.255
dnsmasq-dhcp[] sent size:  4 option:  3 router  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option:  6 dns-server  192.168.251.1

dnsmasq-dhcp[] available DHCP range: 192.168.251.100 -- 192.168.251.250
dnsmasq-dhcp[] client provides name: sensor_1
dnsmasq-dhcp[] DHCPREQUEST(wlan0) 192.168.251.101 xx:xx:xx:xx:xx:xx 
dnsmasq-dhcp[] tags: known_wlan0_m1, known, wlan0
dnsmasq-dhcp[] DHCPACK(wlan0) 192.168.251.101 xx:xx:xx:xx:xx:xx sensor_1
dnsmasq-dhcp[] requested options: 1:netmask, 3:router, 28:broadcast, 6:dns-server
dnsmasq-dhcp[] next server: 192.168.251.1
dnsmasq-dhcp[] sent size:  1 option: 53 message-type  5
dnsmasq-dhcp[] sent size:  4 option: 54 server-identifier  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option: 51 lease-time  infinite
dnsmasq-dhcp[] sent size:  4 option:  1 netmask  255.255.255.0
dnsmasq-dhcp[] sent size:  4 option: 28 broadcast  192.168.251.255
dnsmasq-dhcp[] sent size:  4 option:  3 router  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option:  6 dns-server  192.168.251.1

in contrast to a raspberrypi, there is at each stage a "client provides name: ..." available:

dnsmasq-dhcp[] available DHCP range: 192.168.251.100 -- 192.168.251.250
dnsmasq-dhcp[] client provides name: raspberrypi

dnsmasq-dhcp[] available DHCP range: 192.168.251.100 -- 192.168.251.250
dnsmasq-dhcp[] client provides name: raspberrypi
dnsmasq-dhcp[] DHCPDISCOVER(wlan0) zz:zz:zz:zz:zz:zz 
dnsmasq-dhcp[] tags: client_is_a_pi, wlan0
dnsmasq-dhcp[] reply delay: 2
dnsmasq-dhcp[] DHCPOFFER(wlan0) 192.168.251.225 zz:zz:zz:zz:zz:zz 
dnsmasq-dhcp[] requested options: 1:netmask, 3:router, 26:mtu, 252, 42:ntp-server, 
dnsmasq-dhcp[] requested options: 15:domain-name, 6:dns-server, 12:hostname
dnsmasq-dhcp[] server name: 0.0.0.0
dnsmasq-dhcp[] next server: 192.168.251.1
dnsmasq-dhcp[] sent size:  1 option: 53 message-type  2
dnsmasq-dhcp[] sent size:  4 option: 54 server-identifier  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option: 51 lease-time  1h
dnsmasq-dhcp[] sent size:  4 option:  1 netmask  255.255.255.0
dnsmasq-dhcp[] sent size:  4 option: 28 broadcast  192.168.251.255
dnsmasq-dhcp[] sent size:  4 option:  3 router  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option:  6 dns-server  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option: 42 ntp-server  192.168.251.1

dnsmasq-dhcp[] available DHCP range: 192.168.251.100 -- 192.168.251.250
dnsmasq-dhcp[] client provides name: raspberrypi
dnsmasq-dhcp[] DHCPREQUEST(wlan0) 192.168.251.225 zz:zz:zz:zz:zz:zz 
dnsmasq-dhcp[] tags: client_is_a_pi, wlan0
dnsmasq-dhcp[] DHCPACK(wlan0) 192.168.251.225 zz:zz:zz:zz:zz:zz raspberrypi
dnsmasq-dhcp[] requested options: 1:netmask, 3:router, 26:mtu, 252, 42:ntp-server, 
dnsmasq-dhcp[] requested options: 15:domain-name, 6:dns-server, 12:hostname
dnsmasq-dhcp[] server name: 0.0.0.0
dnsmasq-dhcp[] next server: 192.168.251.1
dnsmasq-dhcp[] sent size:  1 option: 53 message-type  5
dnsmasq-dhcp[] sent size:  4 option: 54 server-identifier  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option: 51 lease-time  1h
dnsmasq-dhcp[] sent size:  4 option:  1 netmask  255.255.255.0
dnsmasq-dhcp[] sent size:  4 option: 28 broadcast  192.168.251.255
dnsmasq-dhcp[] sent size:  4 option:  3 router  192.168.251.1
dnsmasq-dhcp[] sent size:  4 option:  6 dns-server  192.168.251.1
dnsmasq-dhcp[] sent size:  9 option: 12 hostname  raspberrypi
dnsmasq-dhcp[] sent size:  4 option: 42 ntp-server  192.168.251.1

@david-cermak
Copy link
Collaborator

Hi @beta-tester

I believe that what you're seeing is another issue, related to the DHCP discover packets. Please subscribe to that issue to get notified when it gets resolved.

As for the usage example, please refer to the test case added to check the fixed issue: https://github.com/espressif/esp-idf/blob/master/components/esp_netif/test/test_esp_netif.c#L248

@beta-tester
Copy link
Contributor

@david-cermak , thank you for your hint...
and i subscribed #4685

@beta-tester
Copy link
Contributor

my issue is fixed now... thank you
espressif/esp-lwip#9
espressif/esp-lwip@13665c1

espressif-bot pushed a commit that referenced this issue Mar 24, 2021
On startup of the common interface (ethernet, wifi), the lwip netif hostname was assigned to confg value .
Fixed to assign to esp-netif hostname if it exists

Closes #4737
@ProductOfAmerica
Copy link

ProductOfAmerica commented Jan 2, 2025

Is there a solution for this? Trying to use

esp_netif_t *sta_netif = esp_netif_create_default_wifi_sta();
ESP_ERROR_CHECK(esp_netif_set_hostname(sta_netif, "custom"));

and it's not working. Using ESP-IDF v5.3.2

@david-cermak
Copy link
Collaborator

This should work normally, see the test code here:

// specific hostname set and get
TEST_ASSERT_EQUAL(ESP_OK, esp_netif_set_hostname(esp_netif, "new_name"));
TEST_ASSERT_EQUAL(ESP_OK, esp_netif_get_hostname(esp_netif, &hostname));
TEST_ASSERT_EQUAL_STRING(hostname, "new_name");

Does the esp_netif_set_hostname() return any error code? Is it possible that the interface hasn't been started yet? (returns ESP_ERR_ESP_NETIF_IF_NOT_READY ?)

@ProductOfAmerica
Copy link

This should work normally, see the test code here:

// specific hostname set and get
TEST_ASSERT_EQUAL(ESP_OK, esp_netif_set_hostname(esp_netif, "new_name"));
TEST_ASSERT_EQUAL(ESP_OK, esp_netif_get_hostname(esp_netif, &hostname));
TEST_ASSERT_EQUAL_STRING(hostname, "new_name");

Does the esp_netif_set_hostname() return any error code? Is it possible that the interface hasn't been started yet? (returns ESP_ERR_ESP_NETIF_IF_NOT_READY ?)

Sorry, my mistake, seems to be working, DHCP client list on my AP was cached and wasn’t updating correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants