[GH-ISSUE #265] IP Address #222

Closed
opened 2026-02-28 01:24:10 +03:00 by kerem · 6 comments
Owner

Originally created by @sergionaf on GitHub (Dec 16, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/265

Is possible to show the IP Address assigned to ESP from the DHCP server of the connected wireless network ?

Originally created by @sergionaf on GitHub (Dec 16, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/265 Is possible to show the IP Address assigned to ESP from the DHCP server of the connected wireless network ?
kerem closed this issue 2026-02-28 01:24:10 +03:00
Author
Owner

@Humancell commented on GitHub (Dec 29, 2016):

I don't believe this has anything to do with the WiFi Manager library ... you can always use:

Serial.println(WiFi.localIP());

<!-- gh-comment-id:269688781 --> @Humancell commented on GitHub (Dec 29, 2016): I don't believe this has anything to do with the WiFi Manager library ... you can always use: Serial.println(WiFi.localIP());
Author
Owner

@skx commented on GitHub (Feb 1, 2017):

Agreed. This bug report should be closed :)

<!-- gh-comment-id:276767873 --> @skx commented on GitHub (Feb 1, 2017): Agreed. This bug report should be closed :)
Author
Owner

@DaleMitchell commented on GitHub (Dec 21, 2018):

I disagree. The purpose of WiFiManager is to help a user connect to their WiFi network. Part of connecting is getting an IP address. Maybe this proposed feature of displaying the IP address obtained by DHCP is useful to a minority of issues, but it is still a good feature for some including me. I think this is worth pursuing. At the moment, it appears that the page displayed after saving WiFi credentials has a redirect to the /i page, so if the wireless device fails to connect to the AP (usually due to incorrect credentials), the user will get redirected to the /i page where it shows the local IP of the wireless device, which at the moment happens to be the IP for accessing the main page of an instance of WiFiManager. Why does it not redirect to a page such as Connecting to the ESP failed, redirecting to the main menu... so then the user can retry? It seems like someone was trying to get the info page to actually show the local IP obtained from DHCP after connecting to the desired AP. Hopefully someone can beat me to a pull request, this would be a nice feature.

<!-- gh-comment-id:449450891 --> @DaleMitchell commented on GitHub (Dec 21, 2018): I disagree. The purpose of WiFiManager is to help a user connect to their WiFi network. Part of connecting is getting an IP address. Maybe this proposed feature of displaying the IP address obtained by DHCP is useful to a minority of issues, but it is still a good feature for some including me. I think this is worth pursuing. At the moment, it appears that the page displayed after saving WiFi credentials has a redirect to the `/i` page, so if the wireless device fails to connect to the AP (usually due to incorrect credentials), the user will get redirected to the `/i` page where it shows the local IP of the wireless device, which at the moment happens to be the IP for accessing the main page of an instance of WiFiManager. Why does it not redirect to a page such as `Connecting to the ESP failed, redirecting to the main menu...` so then the user can retry? It seems like someone was trying to get the info page to actually show the local IP obtained from DHCP after connecting to the desired AP. Hopefully someone can beat me to a pull request, this would be a nice feature.
Author
Owner

@tablatronix commented on GitHub (Dec 21, 2018):

after connecting to the desired ap, there is no portal , so what is the point, the softap closes when save succeeds. you are talking about client refresh and checking , the server is not available when connecting to a saved wifi, there are many issues to work around to get a clean solution to that

<!-- gh-comment-id:449457568 --> @tablatronix commented on GitHub (Dec 21, 2018): after connecting to the desired ap, there is no portal , so what is the point, the softap closes when save succeeds. you are talking about client refresh and checking , the server is not available when connecting to a saved wifi, there are many issues to work around to get a clean solution to that
Author
Owner

@DaleMitchell commented on GitHub (Dec 21, 2018):

You're correct. The SoftAP closes after the ESP successfully connects. Yes, the server is not available when connecting to the user's saved SSID, that is a remarkable challenge. But that doesn't mean it can't reopen the SoftAP for a brief period of time to report back to the user, and then once the ESP acknowledges the user received an updated info page, then it can close the SoftAP and reconnect to the user's saved WiFi SSID. Remember that DHCP assigns IP addresses with a lease, which should always be plenty more than sufficient time for retaining the same IP address.

<!-- gh-comment-id:449473331 --> @DaleMitchell commented on GitHub (Dec 21, 2018): You're correct. The SoftAP closes after the ESP successfully connects. Yes, the server is not available when connecting to the user's saved SSID, that is a remarkable challenge. But that doesn't mean it can't reopen the SoftAP for a brief period of time to report back to the user, and then once the ESP acknowledges the user received an updated info page, then it can close the SoftAP and reconnect to the user's saved WiFi SSID. Remember that DHCP assigns IP addresses with a lease, which should always be plenty more than sufficient time for retaining the same IP address.
Author
Owner

@tablatronix commented on GitHub (Dec 21, 2018):

Then we have to add js checking, captiveportals might close down on the user, dropped ap connections can be a problem if reconecting to fast regardless. And then you are assuming the ip is the same. Its on the roadmap.

Ideally we connect to the router in sta+ap mode then there is no problem, but that is unstable and can be a problem, so it needs to address all this and have good design or else it will introduce bugs.

<!-- gh-comment-id:449509766 --> @tablatronix commented on GitHub (Dec 21, 2018): Then we have to add js checking, captiveportals might close down on the user, dropped ap connections can be a problem if reconecting to fast regardless. And then you are assuming the ip is the same. Its on the roadmap. Ideally we connect to the router in sta+ap mode then there is no problem, but that is unstable and can be a problem, so it needs to address all this and have good design or else it will introduce bugs.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/WiFiManager#222
No description provided.