openDTU 24.9.27 reboot alle 10min #2314
Comments
|
Welche Hardware läuft bei dir den? Version v24.9.27 läuft hier ohne Auffälligkeiten Chip-Modell |
|
Interessant wäre auch ein Auszug vom Seriellen Log während des Reboots. Damit kann man eher einschätzen was passiert. Wie @rolsch schon sagt, es scheint kein generelles Problem zu sein, da ich es auf meinen diversen Test-DTUs auch nicht nachvollziehen kann. |
|
Kann ich bestätigen, auch die Zeitangabe von ca. 10 Minuten, was ziemlich genau passt. Es waren bei den unten gezeigten Ausfällen jeweils etwas mehr, gut 11 Minuten bis das Web Ifc nicht mehr erreichbar ist. Grund: Offensichtlich ein Speicherleck. Ich kann unter api/system/status zusehen, wie heap_min_free und heap_max_block kleiner werden. Log 1 von OpenDTU b206cee (selbst-kompiliert)Log 2 von OpenDTU b206cee (selbst-kompiliert)Log von OpenDTU-OnBattery (genauen Stand weiß ich nicht mehr, aber b206cee ist ge-merge't)Besonderheiten an diesem schmutzigen Test-Aufbau:
Sonst sollte nichts außergewöhnliches dran sein. Bei mir handelt es sich um Firmware Variante |
|
MQTT ausschalten bringt keine Veränderung. Den nicht-erreichbaren Inverter löschen bringt auch keine Veränderung. Ich sehe auf der Konsole nur noch "Admin AP remaining seconds: 40 / 180" hochzählen, dennoch sinkt |
|
Habe hier aus anderen Gründen gerade einen Test laufen... 10 inverter konfiguriert. keiner erreichbar. mqtt aber erreichbar... --> Klappt erstmal problemlos. Bin gerade bei 15min Uptime. Heap und max Heap sind unverändert. |
Nope alles gut hier.. MQTT ist auf eine IP umgebogen auf der kein broker lauscht. läuft also jedes mal in eine "connection reset by peer". Hast du dabei die Live View offen oder die system view? |
|
Ok, habe jetzt auch noch die Live View offen... Uptime ist bei 15min. 10 Inverter am CMT Modul verbunden. MQTT kann sich nicht verbinden.... Heap ist normal. Werde es jetzt nochmal mit einem esp32s3 testen. |
|
Hm auch keine Probleme mit einem esp32s3 mit w5500. @schlimmchen machst du mir deine config schicken? (wifi credentials usw. bitte vorher entfernen). dann spiele ich die hier mal ein und schaue was passiert. |
|
Scheint, wie @schlimmchen vermutet, am Heap zu liegen. Free geht von irgendwas um die 140.000 nach reboot beginnend konstant runter. Nach 400s ist er um die 75.000.
Das Bootlog nach dem unexpected reboot, diesmal nach etwa 7min abort() was called at PC 0x401a8b23 on core 1 Backtrace: 0x40083d8d:0x3ffb2080 0x4008ee99:0x3ffb20a0 0x400950a9:0x3ffb20c0 0x401a8b23:0x3ffb2140 0x401a8b6a:0x3ffb2160 0x401a8d45:0x3ffb2180 0x401a8e00:0x3ffb21a0 0x400f2833:0x3ffb21c0 0x400f2aef:0x3ffb21f0 0x401c8cf1:0x3ffb2210 0x400f53a6:0x3ffb2230 0x400f5521:0x3ffb2250 0x400f553a:0x3ffb2270 0x40115eb1:0x3ffb2290 ELF file SHA256: 40ab189640df9f1c E (16223) esp_core_dump_flash: Core dump flash config is corrupted! CRC=0x7bd5c66f instead of 0x0 rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) Starting OpenDTU Wie gesagt, die 24.5.6 lief/läuft stabil. |
Tritt auch auf, wenn ich die System Status View anschaue und (soweit ich weiß) kein Browsertab habe, das die Live-View anzeigt.
Ja, gerne, daran habe ich auch schon gedacht. Ging nicht eher.
Display ist übrigens keins angeschlossen, aber konfiguriert. PoE hat ist keins drauf.
Jup, undankbares Problem, aber da es "einfach auftritt" beir mir und universal-dilettant und es auch nicht weg geht, wird wohl was dran sein. Ich hab mal den diff zwischen v24.9.27 und v24.9.26 nach "new" durchsucht, aber da ist mir nichts ins Gesicht gesprungen. Heute Abend wäre dann git bisect angesagt, wenn es sich nur bei mir reproduzieren lässt. Der Themenstarter sagt, er habe die Release-Binary genommen. Wird dann wohl kein platformio cache oder non-clean-build Problem sein, nehme ich an. |
|
@universal-dilettant @schlimmchen was für WR Typen habt Ihr denn konfiguriert auf Euren (Test-) Systemen ? Nur HM oder HMS/HMT oder beides, evtl ein besonderes Modell ? |
|
Gar keinen (mehr), siehe die hochgeladene config oben, das Problem tritt trotzdem auf. |
|
2x HMS-2000-4T |
|
@schlimmchen ich kann das problem mit deiner config nachvollziehen. Den unterschied an den configs konnte ich in der Einstellung mit dem "Allow anonymous readonly access" festmachen. Wenn ich diese Funktion aktiviere klappt alles. Es scheint in der aktuellen version des webservers beim handling der authenfizierung irgendetwas schief zu laufen. |
|
Gute Neuigkeiten. Dann behaupte ich, dass #2316 doch kein weiterer Typ Panic ist, sondern ebenfalls mit dieser Funktion zusammenhängt. Da ist der Kontext ja ebenfalls die Basic-Athentication. Das Problem ist bei mir ebenfalls sofort verschwunden, wenn ich "Allow anonymous readonly access" einschalte. Mit diesem Wissen wäre meine erste Vermutung nun, dass die Einführung von Middlewares beim AsyncWebServer etwas damit zu tun hat. Muss da noch etwas an das neue Schema angepasst werden? |
|
Ich behaupte, dass OpenDTU/src/WebApi_ws_live.cpp Line 49 in b206cee und OpenDTU/src/WebApi_ws_console.cpp Line 34 in b206cee wegen der Einführung von Middlewares umgebaut werden müssen. Ansonsten wird Security.AllowReadonly nur bei Es macht auch Sinn, dass der Speicher kontinuierlich und von selbst sinkt, weil
Aha, okay. Ein Leak ist es nicht wirklich, es werden so lange Middlewares instanziiert und dem Server hinzugefügt, bis kein Speicher mehr da ist. Das erklärt auch den langen Backtrace in #2316. Und das erklärt auch, warum ich den gefühlt immer gesehen habe, wenn ich den Live-View (neu) aufgerufen habe. Ich hab einen Fix gebastelt und scheinbar erfolgreich getestet. Kommt gleich per PR. |
Doch, das sorgte dafür, dass beim Verändern der Option "allow readonly access" die websockets spätestens nach einer Sekunde mit der neuen Einstellung versehen wurden. Das ist ohnehin eine Regression, denn wenn der readonly access einmal ausgeschaltet wurde, ist die Middelware für immer in der Chain und würde auch beim Wiedereinschalten des readonly access dafür sorgen, dass Authentifiziert werden muss (vermute ich, habs nicht getestet). |
|
bestätige @schlimmchen. Mit "Allow anonymous readonly access" = on (war bei mir schon immer off) pendelt der freie Heap um die 150.000. Testweise erneut auf off und der freie Heap ist wieder geschrumpft. Nochmal auf on und er hat sich auf dem dann niedrigen Stand erneut stabilisiert. |
|
@schlimmchen es gibt zwei Punkte bei der Einführung der AuthenticationMiddleware des ESPAsyncWebServer zu beachten:
AuthenticationMiddleware authMiddleware;
// [...]
authMiddleware.setAuthType(AuthenticationMiddleware::AuthType::AUTH_DIGEST);
authMiddleware.setRealm("My app name");
authMiddleware.setUsername("admin");
authMiddleware.setPassword("admin");
// [...]
server.addMiddleware(&authMiddleware); // globally add authentication to the server
// [...]
myHandler.addMiddleware(&authMiddleware); // add authentication to a specific handler
@schlimmchen yes this is the culprit, it will create a new AuthenticationMiddleware for each call to setAuthentication(): AsyncWebHandler& setAuthentication(const char* username, const char* password) {
if (username == nullptr || password == nullptr || strlen(username) == 0 || strlen(password) == 0)
return *this;
AuthenticationMiddleware* m = new AuthenticationMiddleware();
m->setUsername(username);
m->setPassword(password);
m->_freeOnRemoval = true;
addMiddleware(m);
return *this;
};Eventually the memory may get Rest of my train of thoughts follows in english for no reason 😁 We are currently attaching the method to AsyncWebSocket _ws AsyncWebSocket _ws;
...
_ws.setAuthentication(AUTH_USERNAME, Configuration.get().Security.Password);I do not know if adding a BASIC Auth check - actually base64 encoded As you can see it in the following source upstream, for each request the base64 encoded ESPAsyncWebServer.h: // hash is the string representation of:
// base64(user:pass) for basic or
// user:realm:md5(user:realm:pass) for digest
bool authenticate(const char* hash);
bool authenticate(const char* username, const char* password, const char* realm = NULL, bool passwordIsHash = false);As we are using HTTP for the user-interface and REST endpoints of OpenDTU this is kind of superstitious IMHO. |
Das ist richtig. Habe schon gesehen, dass es neben Ich glaube sowas hier würde es tun: void WebApiWsLiveClass::wsCleanupTaskCb()
{
// see: https://github.com/me-no-dev/ESPAsyncWebServer#limiting-the-number-of-web-socket-clients
_ws.cleanupClients();
if (Configuration.get().Security.AllowReadonly == _lastAuthType) {
return;
}
if (Configuration.get().Security.AllowReadonly) {
MessageOutput.println("Remove Auth");
_ws.removeMiddleware(&_authMiddleware);
} else {
MessageOutput.println("Add Auth");
_authMiddleware.setUsername(AUTH_USERNAME);
_authMiddleware.setPassword(Configuration.get().Security.Password);
_ws.addMiddleware(&_authMiddleware);
}
_lastAuthType = Configuration.get().Security.AllowReadonly;
} |
|
@tbnobody prinzipiell ja, vielleicht können wir den Aufruf irgendwie so umbiegen, dass die AuthenticationMiddleware anstelle von BASIC Auth mit username:password nur den von uns gesetzten Hash verwendet (siehe |
An meinem PR finde ich besser, dass die Anpassung der Einstellungen event-driven ist.
Das wäre dann was für ESPAsyncWebserver, weil Thomas und ich gerade den empfohlenen, neuen Weg vorschlagen, wie man so eine Authentication per Middleware umsetzen sollte. Diese AuthenticationMiddleware ist nicht schwergewichtig. Die ruft am Ende maßgeblich auch nur |
|
@schlimmchen Dein PR #2320 ändert auch unser Auth Verfahren von BASIC Auth auf DIGEST Auth, also Username:Realm:Password anstelle von Username:Password und dem entsprechend angepaßten |
Wenn dem so ist, müssen wir drüber sprechen. Wäre aber eine gute Gelegenheit, BASIC wegzuwerfen -- meine Meinung.
Nein, denn es geht nur um die Websockets. |
|
@schlimmchen ja, das Default Verfahren der AuthenticationMiddleware ist auch / sowieso DIGEST Auth. Abgesehen von der etwas komplizierteren Erstellung (MD5 statt base64) eines passenden Tokens / Hashes um den Endpunkt per curl, etc. aufzufrufen spricht m.E. nur dagegen, daß man auch noch eine Realm, bzw. NULL angeben muß und der Aufwand den Request zu bearbeiten dadurch auf Seite des ESP32 noch größer wird. Also einmal das andere Mal sendet der Server (wir) die nonce / das Passwort Und der Client muss dann die Authorization dazu passend berechnen: Wir haben m.E. auch keinen echten Sicherheitsgewinn dadurch, da wir m.W. immer noch per http mit der OpenDTU sprechen, oder täusche ich mich da ? Ich versuche gerade noch zu verstehen, wie man die AuthenticationMiddleware dazu bringt, ggf. nur den Hash zu speichern und gegen diesen zu authentifizieren mit der o.g. Signatur |
|
Wenn man BASIC authentication mitschickt, wird diese auch akzeptiert. Es wird kein Challenge-Response erwzwungen um DIGEST zu machen. Das heißt: Ist ech schon "abwärtskompatibel" und der Hash, vor dessen Berechnung sich @stefan123t fürchtet, wird vermutlich auch nur dann berechnet, wenn der Client auf DIGEST besteht.
Der Punkt ist, dass man bei DIGEST Authentication nicht durch Mithören das Passwort (trivial) bestimmen kann, das überreicht wurde. Das mag nicht "kritisch" sein für unsere Anwendung, aber es ist pauschal Unfug, sowas noch zu tun, finde ich. |
|
@schlimmchen prinzipiell gebe ich Dir Recht dass DIGEST Auth vorzuziehen ist, aber dann bräuchten wir auch pro Client eine eigene Client Nonce die wir bei jedem 401 Request entsprechend aktualisieren. Sonst ist es nur ein etwas komplizierteres BASIC Auth mit fester nonce 😉 Und ich "fürchte" mich nicht vor dem Berechnen des MD5 Hashes bzw. des Base64 Encodierten BASIC Auth tokens 😁, aber der Code zeigt klar, dass dies bei jedem Aufruf von AsyncWebServerRequest::authenticate() in der Unterroutine checkBasicAuthentication() oder checkDigestAuthentication() auf dem Heap erneut zusammen gebastelt und dann erst geprüft wird. Das könnte man sich bei BASIC Auth mit einem quasi über die Zeit fixen Hash/Token prinzipiell sparen. Aber da hast Du natürlich Recht, das gehört eigentlich upstream in der ESPAsyncWebServer Implementierung adressiert und gefixt. |
|
Und was auch richtig ist, man kann in der Tat DIGEST Auth in der AuthenticationMiddleware einstellen und dann aber beim Request nur einen BASIC Auth mitschicken, dann landet der Code in WebRequest.cpp m.E. im BASIC Auth Zweig: bool AsyncWebServerRequest::authenticate(const char* username, const char* password, const char* realm, bool passwordIsHash) {
if (_authorization.length()) {
if (_isDigest)
return checkDigestAuthentication(_authorization.c_str(), methodToString(), username, password, realm, passwordIsHash, NULL, NULL, NULL);
else if (!passwordIsHash)
return checkBasicAuthentication(_authorization.c_str(), username, password);
else
return _authorization.equals(password);
}
return false;
}
|
|
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. |
and others
What happened?
Upgrade von v24.5.6 auf v24.9.23 am 26.9. und auf v24.9.27 am 28.9.
Seit v24.9.26 bootet die openDTU alle 10min (und verliert dabei ihren ac/yieldtotal counter, so habe ich das überhaupt erst bemerkt).
Zum Überprüfen auf die 24.5.6 zurückgegangen und sie läuft wieder stabil (erstmal seit 20min).
Anhand der historischen Daten in InfluxDB (dtu/uptime) lässt sich der Zusammenhang gut belegen.
To Reproduce Bug
siehe oben
Expected Behavior
keine reboots :-)
Install Method
Pre-Compiled binary from GitHub releases
What git-hash/version of OpenDTU?
24.9.27
What firmware variant (PIO Environment) are you using?
generic_esp32
Relevant log/trace output
No response
Anything else?
Falls Logs/Traces/etc benötigt werden, gerne.
Ob der Issue nur mich betrifft oder auch andere, kann ich nicht sagen, würde es aber vermuten.
Please confirm the following
The text was updated successfully, but these errors were encountered: