mirror of
https://github.com/tzapu/WiFiManager.git
synced 2026-04-27 00:55:52 +03:00
[GH-ISSUE #688] DNS lookups fail if config portal was up. #571
Labels
No labels
📶 WiFi
🕸️ HTTP
Branch
DEV Help Wanted
Discussion
Documentation
ESP32
Example
Good First Issue
Hotfix
In Progress
Incomplete
Needs Feeback
Priority
QA
Question
Task
Upstream/Dependancy
bug
duplicate
enhancement
invalid
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/WiFiManager#571
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @liebman on GitHub (Aug 6, 2018).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/688
Basic Infos
Development branch (current development branch git)
Hardware
WiFimanager Branch/Release: Development
Esp8266/Esp32: esp8266
Hardware: ESP-12e
Core Version: current master from git
Description
DNS name resolution fails if config portal was up. When autoconnect without portal DNS name resolution works fine.
Settings in IDE
Module: NodeMcu
Additional libraries: None
Sketch
Debug Messages
Reset with pin 14 LOW - force config portal - DNS lookups fail.
Reset with pin 14 HIGH - use auto connect, DNS works.
@tablatronix commented on GitHub (Aug 6, 2018):
Cannot reproduce
@tablatronix commented on GitHub (Aug 6, 2018):
Can you add a
Serial.println(wm.getModeString(WiFi.getMode()));to make sure you are connected to sta when coming out of configportal, also does using configportaltimeout (and letting it timeout NOT saveing ) result in the same behavior ?@tablatronix commented on GitHub (Aug 6, 2018):
only this I could find with this offer_error is this
https://github.com/nodemcu/nodemcu-firmware/pull/1985
@liebman commented on GitHub (Aug 6, 2018):
I'll give the above print a try when I get home.
EDIT: i did notice that:
was started a second time as the config portal was exiting....
@tablatronix commented on GitHub (Aug 6, 2018):
ok let me enable debugging and see if mine does also , I think that happens when you restart sta or change modes. Ill see if its related
@tablatronix commented on GitHub (Aug 6, 2018):
I tried it with sta failing and saved, both work, although I did get 1 error, probably a timing issue,
Might be a lib, bug, let me know which esp version you are compiling when you can
@liebman commented on GitHub (Aug 6, 2018):
I'm getting "STA+AP" - even if I add
WiFi.mode(WIFI_STA);before starting the config portal.Adding a 30 second timeout yields this where it fails a few times then says its connected and starts working.
@liebman commented on GitHub (Aug 6, 2018):
And adding
WiFi.mode(WIFI_STA);after the return from config portal also works.@tablatronix commented on GitHub (Aug 7, 2018):
Can you test one more thing?
Add a 2 second delay before when starting configportal to give esp time to connect, autoconnect=true?
@liebman commented on GitHub (Aug 7, 2018):
Still fails. (autoconnect is true) Found also that After
startConfigPortal()returns it's ALWAYS in 'STA+AP' Even if I had calledWiFi.mode(WIFI_STA);before the delay before startConfigPortal()`.Current sketch:
Results:
@tablatronix commented on GitHub (Aug 7, 2018):
Thats because there was a bug and I had to remove this
@tablatronix commented on GitHub (Aug 7, 2018):
How did you output this ?
@tablatronix commented on GitHub (Aug 7, 2018):
Also it looks like your lookup failures have changed to a different error.. hmm
@liebman commented on GitHub (Aug 7, 2018):
I'm using Debug port: Serial & Debug Level: WiFi
I wonder if the DNS issue is because AP is enabled and somehow the DNS lookup is being set there (and fails of course). https://github.com/esp8266/Arduino/issues/4949 mentions this possibility in one of the comments. Would explain why it works if I set STA after the config portal exits.
@tablatronix commented on GitHub (Aug 7, 2018):
Maybe, But I was in not seeing issues with the same mode. Shouldn't dns work on both interfaces?
Or are we breaking it when we do
dnsServer.reset();@tablatronix commented on GitHub (Aug 7, 2018):
ok so if the subnets are the same, the loopback dns will be hit it seems.
Is this what you are seeing, is your sta ap dns the same subnet as your softap ?
@liebman commented on GitHub (Aug 7, 2018):
Nope - 192.168.0.0/24 vs 192.168.4.0/24 Maybe there is something odd about how my router sends teh DNS server? (But it works in STA only mode)
@tablatronix commented on GitHub (Aug 7, 2018):
strange I will try to see of that bug can be fixed for now, if that issue is still a problem or not