Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix issue #5507 "Constructor WebServer::WebServer(IPAddress addr, int… #5509

Merged
merged 6 commits into from
Aug 23, 2021

Conversation

timr49
Copy link
Contributor

@timr49 timr49 commented Aug 8, 2021

… port) produces an unexpected result"

"The class Webserver is declared with two explicit constructors, one with signature:
WebServer::WebServer(IPAddress addr, int port)
Using this results in a server listening on the port number obtained by converting the value of the IPAddress addr argument (in host byte order) to a uint32_t and then to a uint16_t, which is manifestly not the result that would be expected.
...
As for a fix, we can assume from these results that this constructor is not being used and therefore could simply be deleted."


This entire section can be deleted if all items are checked.

By completing this PR sufficiently, you help us to improve the quality of Release Notes

Checklist

  1. Please provide specific title of the PR describing the change, including the component name (eg."Update of Documentation link on Readme.md")
  2. Please provide related links (eg. Issue, other Project, submodule PR..)

Summary

Fix issue #5507 "Constructor WebServer::WebServer(IPAddress addr, int port) produces an unexpected result"

Impact

This change deletes the declaration and invalid definition of an apparently unused constructor of class WebServer. The intended/expected impact is that (attempted) use of this constructor will result in a compile-time error rather than erroneous run-time behaviour.

…addr, int port) produces an unexpected result"

"The class Webserver is declared with two explicit constructors, one with signature:
WebServer::WebServer(IPAddress addr, int port)
Using this results in a server listening on the port number obtained by converting the value of the IPAddress addr argument (in host byte order) to a uint32_t and then to a uint16_t, which is manifestly not the result that would be expected.
...
As for a fix, we can assume from these results that this constructor is not being used and therefore could simply be deleted."
@Rotzbua
Copy link
Contributor

Rotzbua commented Aug 10, 2021

Wouldn't it be better to implement the missing function like in old esp:
https://github.com/esp8266/Arduino/blob/3.0.2/libraries/ESP8266WiFi/src/WiFiServer.h#L80

Furthermore removing maybe break derived classes.. so better fix , _server(addr, port) and print a warning at runtime?

@me-no-dev
Copy link
Member

I agree with @Rotzbua . Issue should be fixed in WiFiServer

@timr49
Copy link
Contributor Author

timr49 commented Aug 12, 2021

I agree with @Rotzbua . Issue should be fixed in WiFiServer

I would readily agree if there was evidence that the ESP8266 version was in use and known to work and we were able to properly test an ESP32 version. I can't see any examples (ESP8266 or ESP32) that use it and note that a server binding a specific IP address (as opposed to INADDR_ANY) is really only useful, and can only be tested, if you have a device with multiple network interfaces, e.g. one WiFi plus one ETH.
As a compromise, we could test it with a single network interface (e.g. WebServer(WiFi.localIP(),80), note in the code&doc that testing is limited to that, and leave full testing with multiple interfaces to anyone who has such a device. Would that be acceptable?

@me-no-dev
Copy link
Member

@timr49 even though there are no examples, in reality we can/should add this functionality, because ESP-IDF supports it and could be useful in some cases. ESP32 can have more than 3 interfaces at the same time :) For now the code can just go to the other constructor.

timr49 added 2 commits August 13, 2021 05:40
Reverse changes in commit bee1e70 after discussion.
Alternative fix to be done.
@timr49
Copy link
Contributor Author

timr49 commented Aug 12, 2021

@timr49 even though there are no examples, in reality we can/should add this functionality, because ESP-IDF supports it and could be useful in some cases. ESP32 can have more than 3 interfaces at the same time :) For now the code can just go to the other constructor.

It occurred to me after commenting above that the ESP WiFi can have two IP interfaces, one the station and one the soft AP. So, we do have a way of testing multi-homed servers, at least for n=2.

…addr, int port) produces an unexpected result"

This change adds support for multi-homed servers to libraries/WiFi.  It was assumed to be there already by libraries/WebServer, but was not.
This led to unexpected results when the IP address-specific constructor of class WebServer was used (see issue 5507).

This change was tested using three concurrent instances of WebServer, one bound to the WiFi station address, one bound to the WiFi soft AP address,
and one bound to INADDR_ANY.  See libraries/WebServer/examples/MultiHomedServers for the test method.
@timr49
Copy link
Contributor Author

timr49 commented Aug 12, 2021

I have pushed a different change onto the same branch, which adds support for multi-homed web servers. It includes a new examples script (WebServer/MultiHomedServers), which tests this change. The testing method is in the comments. The expected results were achieved.

At about the same time as my push, I got some error notifications from CI, but am not sure whether they are related to my previous fix or this one. Unfortunately, my GitHub skills are new, so am not sure what to do next.

…addr, int port) produces an unexpected result" (cont.)

This fixes what I think might be the cause of CI failures on GitHub for the previous commit, namely the absence of an include file
in examples/MultiHomedServers.
@timr49
Copy link
Contributor Author

timr49 commented Aug 13, 2021

At about the same time as my push, I got some error notifications from CI, but am not sure whether they are related to my previous fix or this one. Unfortunately, my GitHub skills are new, so am not sure what to do next.

I successfully guessed what I had done wrong and fixed it in a further commit to the pull request branch ("All checks have passed").

I believe that this change is now ready for review.


server0 = new WebServer(8080);
server1 = new WebServer(WiFi.localIP(), 8081);
server2 = new WebServer(WiFi.softAPIP(), 8082);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for this test to be valid, both servers should be on the same port. That is how you can make sure that the functionality works.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed port numbers as suggested. Expected results returned by test script. Pushed new commit. "All checks have passed".

…addr, int port) produces an unexpected result" (cont.)

Change port numbers in examples/MultiHomedServers per pull-request comment from me-no-dev ...
"for this test to be valid, both servers should be on the same port. That is how you can make sure that the functionality works."
@me-no-dev me-no-dev merged commit 29455a0 into espressif:master Aug 23, 2021
@me-no-dev
Copy link
Member

Thanks @timr49 !!! all merged :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants