ESP8266 Community Forum

- Thu Sep 07, 2017 1:16 pm #69798 Thank you for sharing you work! I have a problem.
It is possible to disable Firewall?
My webserver is 192.168.4.2, my sensor is 192.168.4.3 (esp and ds18b20), but I can not send the data to the webserver(directly to 192.168.4.2), i think because of it firewall.
If I set the sensor to send data over the internet to my server, everything is ok
When the server and sensor are in the main router, everything works ok.
Can you help me? Thank you

- Mon Sep 18, 2017 12:47 pm #70087 i really like that project, it works like a charm now! Thank you!
but i was wondering, did you consider adding mesh functionality or is this too much for the esp?

- Tue Sep 19, 2017 10:19 am #70105 Still interested in this, specially the "do not expose admin interface in the WAN side". I use this project to isolate me from hostile open networks like hotel or starbucks .

Thank you for your feedback.

About your issues:
- You are right: the standalone branch misses some of the latestst changes. Think, I will merge them and make the master branch "standalone". Will do that next week, when I am back from summer vacation.

- Will think about the security model. Currently the assumption is, that the owner of the uplink WiFi is the good guy and that this WiFi has to be protected from the clients of the SoftAp side. Probably it is a good idea to be able to restrict admin access either to the uplink side or to the SoftAP side only.

- It would be easy to include "reset [factory]" in the list of "locked" commands, however then you have to reflash the config, once you have forgotten the lock pw. Perhaps it would be a compromise to allow it at the serial console even in locked state.

- If the uplink side has no password, you can still set one to use it as lock password. But optionally saparating these two passwords might still be a good idea. The ratio behind the current logic is a) the security model and b) that it is easier to remember one PW for WiFi.

- My experience is, that running the CPU at 160 MHz is a good idea. The additional power consumption is marginal (had about 5% less battery time), stability and heat are not an issue, and actual computations are about 50% faster. Think, this is the case as the router CPU idles most of the time anyway.

- Wed Sep 20, 2017 10:49 am #70154 The security-thing has been added to the latest release, see:
set config_access mode: controls the networks that allow config access for console and web (0: no access, 1: only internal, 2: only external, 3: both (default))