WiFiManager
WiFiManager copied to clipboard
tzapu
HandleWiFi() Sometimes Doesn't Send Parameters (Question)
I forked this a while back this year off the master (at the time). It's worked flawlessly using a smartphone, but I've recently noticed that when using a Windows computer to connect that it seems to flood the captive portal server and somehow my params are getting dumped out of the html response back to user which allows them to configure my params. Has there been a fix or anything about this? Any insight?
I merged the latest master with my version and am still seeing similar issues. Where can I look to try to understand this better? There seem to be two related but different issues
- Sometimes the captive portal just instantly closes. Maybe too many requests from my iphone (it's what I've been testing with) that just trigger my captive portal to close? Then I have to disconnect and reconnect to the SSID to re-trigger the captive portal and hope it stays alive during it's lifecycle
- Sometimes it doesn't send the full response even though they are just additions to the page string using page +=. I don't understand how it could possibly make it down the list of page += x; page+=y; page+=z then in the response sometimes y isn't in there!
Is there somewhere I can look to better understand what's going on here? Like a wireshark view into the requests that the webserver is actually getting and a log of the responses it's sending?
Why the fork ?
Yeah mine does that, flood, you are supposed to disconnect other connections when using captive portals. I was looking into adding better filtering for specific cp checks, but they are such a moving target and there is no standard, right now we redirect everything.
Also page variable is on heap and not allocated, so it can overflow, I have been meaning to try to pre allocate its size or use a better buffer
Also make sure you are not remembering the ssid for the device, forget network etc
From my understanding the cp check has to get an ip and a response fast enough or it closes, usually it will open back up. But why it is so flaky I have no idea. I think if we specifically listed for apples cp check maybe it will help.
There are some other cp projects that have attempted this, might be worth checking, maybe espeasy or something I forget
I forked it just because I'm not a good enough programmer to make everything elegant so I hack my way through my forked copy making WM work to suit my needs by just modifying things directly, changing HTML directly, etc. I do understand most of these concepts, just not elegant in making them simple and minimum. If a number of simultaneous requests come in that get redirected, are they handled sequentially and then destroyed before the next request is handled? Or are they more concurrent causing memory issues?
As further troubleshooting, here is my code and output. I had the problem when using getParamsOut() before, then I removed the params altogether to embed my HTML config directly into WM (not elegant, but easier to edit the HTML directly rather than build through params).
Sometimes pitem gets added in, then sometimes it doesn't!!! How can this be? I added size checks below to show that pitem is not empty but somehow doesn't get added to page via page += pitem
page += FPSTR(HTTP_FORM_WIFI_END);
pitem = getBwjohns4StoredHTML(FPSTR(HTTP_CONFIG_HTML), useDefaults);
Serial.print("Size of Pitem: ");
Serial.println(pitem.length());
Serial.print("Page Size Before: ");
Serial.println(page.length());
page += pitem;
Serial.print("Page Size After: ");
Serial.println(page.length());
page += FPSTR(HTTP_FORM_END);
page += FPSTR(HTTP_BACKBTN);
page += FPSTR(HTTP_END);
Then here is the output:
*wm:[2] AP: -86 Deathstar *wm:[2] AP: -86 SpectrumSetup-18 *wm:[2] AP: -87 SpectrumSetup-04 Size of Pitem: 7776 Page Size Before: 6230 Page Size After: 6230 *wm:[2] <- Request redirected to captive portal *wm:[2] <- HTTP Root *wm:[2] <- Request redirected to captive portal *wm:[2] <- HTTP Root
I don't think it's a limit at the packet level, but rather a memory limit when trying to concat large strings when building the response string with a lot of adding onto the end of page. Chunking it allows to first send the wifi scan results, then send the parameters (if there are any) and then whatever is left after that. That way, String page can be reset to page = "" periodically so that it doesn't grow to be too large. I submitted a pull request based upon how I fixed it. This will actually be my first PR, so let me know if I didn't do that correctly.
ESP8266Webserver... What compile errors are you getting? Has the master changed webservers?
I see that now. I'll look into how to reconcile that for ESP32 as well and then push that.