kernel panic / crash when using two ElegantOTA instances and Soft AP about elegantota HOT 6 CLOSED

If using both sta and ap, I don't think you need to have 2 instances of each.
You can create a normal ws instance bound on 0.0.0.0 and have it serve both.
To decide which endpoint is served you can use filtering and rewriting.

ElegantOTA is a static class, not an object that can be instantiated so there can only be one instance.
The consecutive begin calls would overwrite each other.

from elegantota.

Sorry for the poor words. I meant to say that ElegantOTA has is provided as a static class for a reason: it is using under the hood resources which cannot be shared with 2 ElegantOTA instances.

It is not impossible what you do, but there is no synchronisation point to make sure there is no concurrent upload at any point in time or even reboot.

In my project, I am using one (ESPAsyncWebServer) instance, it works on both AP and STA mode (but not at the same time) and I am using filters and rewrite to decide which endpoint is activated on which WiFi mode and where it points to.

This is using far less resources (stack and heap) then duplicated all these instances.

from elegantota.

Thanks for the response!

I realized I made an incredibly dumb mistake: the declaration of the second ElegantOTAClass object is inside setup() so it is lost on exit of that function... when I move it outside, everything works as expected.

I started out with a central webserver for both but couldn't find a guaranteed way to discriminate between calls to one or the other... it seemed theoretically possible that the Soft AP IP and the WLAN IP could be the same, even if near-zero chance, but maybe that's not true. In hindsight I suppose I could have just used that...

I'm not sure what you meant by "ElegantOTA is a static class"? -- I believe there is an instance of the ElegantOTAClass declared at the end of ElegantOTA.cpp? It seems like the entire class has no static variables or methods? I'm doing:
ElegantOTAClass ElegantOTA2; and it seems to be fine now.

Corrected code:

#include <Arduino.h>
#include <WiFi.h>
#include <WebServer.h>
#include <ElegantOTA.h>

WebServer *APwebserver, *STAwebserver;

void handleurlSTA()
{
  if (!STAwebserver->authenticate("username", "password"))
  {
    STAwebserver->requestAuthentication();
    return;
  }

  STAwebserver->send(200, "text/html", "STA webserver");
}

void handleurlAP()
{
  if (!APwebserver->authenticate("username", "password"))
  {
    APwebserver->requestAuthentication();
    return;
  }

  APwebserver->send(200, "text/html", "AP webserver");
}

ElegantOTAClass ElegantOTA2;

void setup()
{
  Serial.begin(115200);
  while (!Serial) delay(10);

  WiFi.mode(WIFI_AP_STA);
  WiFi.softAP("softap", "password");
  WiFi.begin("wifiusername", "wifipassword");

  while(WiFi.status() != WL_CONNECTED)
  {
    Serial.print(".");
    delay(200);
  }

  Serial.println(" connected");
  Serial.printf("STA IP: %s\n", WiFi.localIP().toString().c_str());
  Serial.printf("Soft AP IP: %s\n", WiFi.softAPIP().toString().c_str());

  APwebserver = new WebServer(WiFi.softAPIP(), 80);
  STAwebserver = new WebServer(WiFi.localIP(), 80);
  APwebserver->on("/", handleurlAP);
  STAwebserver->on("/", handleurlSTA);

  ElegantOTA.begin(STAwebserver, "username", "password");
  ElegantOTA2.begin(APwebserver, "username", "password");

  STAwebserver->begin();
  APwebserver->begin();
}

void loop()
{
  STAwebserver->handleClient();
  APwebserver->handleClient();
}

from elegantota.

I appreciate the thoughts -- I think in my case it may be tolerable because WebServer is single threaded (with the project's loop() thread being the thread via handleClient()); I didn't see any under-the-hood resources that are shared by multiple ElegantOTAClass instances (ElegantOTAClass, WebServer, WiFiServer, and Server are all fully-self-contained) with the exception of the Update instance that it holds, which could get the wrong MD5 after URL ota/start if a different client subsequently writes via ota/upload. I suppose the Update.begin()/end() calls could also get things confused, but it seems like the worst that could happen is the update fails and has to be redone. (If this was a commercial product I would think otherwise, since I don't understand how the partitioning stuff works.) And of course I need to be sure that my onStart( ) and onEnd() are aware that multiple clients could call them in unexpected orders.

Let me know if I've missed anything!

May I ask how you do your filtering/rewriting? In my case I have 15 URL endpoints that all come to either webserver. The main difference is requiring HTTP auth for the STA connections. As mentioned, my original idea was to discriminate based on the server IP, but I went the way I did because I wasn't certain those were guaranteed to be unique.

from elegantota.

but it seems like the worst that could happen is the update fails and has to be redone

I don't know how the Update class is synchronised and how it copes with concurrent writes and handle md5 computing, but yes this is the shared resource I was talking about.

May I ask how you do your filtering/rewriting?

https://github.com/yubox-node-org/ESPAsyncWebServer?tab=readme-ov-file#using-filters

With ESPAsyncWebServer, there are some filters which can be added to handlers, and handlers can be rewrites. So these 2 combine give a lot of flexibility to change the rules and destination of the endpoints based on any contextual data.

For exemple, in my case I have these handlers:

• /dashboard

• /espconnect

• / which is a rewrite to /dashboard and with a filter only allowing when sta mode or ap mode are connected

• / which is a rewrite to /espconnect and with a filter only allowing when captive portal is activated (special ap mode)

from elegantota.

Thanks! Looks like they are just comparing IPs as well... maybe my paranoia is unfounded. :-)

from elegantota.