nodemcu-firmware: enduser_setup "Handling POST" failure on 310faf7 and dev

Expected behavior

Calling enduser_setup.start(), connecting trough wifi to captive portal at 192.168.4.1, scanning for AP, entering correct password will connect you to that AP.

Actual behavior

You are returned to empty ‘192.168.4.1/setwifi’ some debug code on failure:

247: 	enduser_setup_check_station
270: 	status=0,chan=13
1469: 	enduser_setup_http_connectcb
1326: 	enduser_setup_http_recvcb
1043: 	enduser_setup_serve_status_as_json
870: 	enduser_setup_http_serve_header
380: 	deferred_close
360: 	handle_remote_close
247: 	enduser_setup_check_station
270: 	status=0,chan=13
1469: 	enduser_setup_http_connectcb
1326: 	enduser_setup_http_recvcb
1123: 	Handling POST
811: 	enduser_setup_http_handle_credentials
820: 	Password or SSID string not found
870: 	enduser_setup_http_serve_header
380: 	deferred_close
360: 	handle_remote_close
360: 	handle_remote_close

Test code

After enabling

#define LUA_USE_MODULES_ENDUSER_SETUP

fire

enduser_setup.start()

NodeMCU version

commit 043046d2ab06fdefdae2a097c7c0f01cdb8da2fb (HEAD -> dev, origin/dev)

Hardware

Generic ESP-07S

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 49 (19 by maintainers)

Most upvoted comments

Can we roll back to the version in 2.2.0.0 for the next drop to master, giving someone with motivation to fix this time thereafter?

Not a good thing to do. We’ve made changes which use SDK 3.0 functionality. Trying to back them out is going to be a real PITA.

Or have I misread this and you are talking about just enduser_setup? In which case, I don’t have a problem.

What I meant was to change the html or better offer an alternative html which uses the already existing route /update to push only ssid and password. From the docs:

/update GET Data submission target. Example: http://example.com/update?wifi_ssid=foobar&wifi_password=CorrectHorseBatteryStaple. Will redirect to / when complete. Note that will NOT update the eus_params.lua file i.e. it does NOT support sending arbitrary parameters. See also: /setwifi.

So I would supply an extra HTML file and a note about it in the documentation.

For arbitrary parameters a GET request is not the right thing as the URL might quickly get too long to guarantee transmission in one segment (and comply to standards)

Using GET in this way also does not comply to the REST standard. But we never claimed it to be a RESTful interface.

Just landed on dev

@KT819GM Just pushed PR #3069 with an htlm for you to try.

I have not looked, so this is purely speculation, but: I suspect that this is not a bug in LwIP TCP handling, but rather a bug in enduser_setup’s use of the network connection APIs: as read/recv and friends will complete upon receipt of packet, it’s very easy to (accidentally) ignore the need to buffer things, because it will very often be that one’s entire payload arrives in a single TCP packet. There’s a fairly complex state machine in mqtt thanks to @stromnet that could serve as an example.

However, this could be a good motivation to replace our enduser_setup C implementation with one in Lua (like my #2819 effort with sntp) and use @TerryE’s lovely pipe module to handle buffering. We do have most of a Lua http server already implemented and committed in-tree, but someone will have to give it some TLC and, more importantly, testing.