Closed universal-dilettant closed 2 weeks ago
Welche Hardware läuft bei dir den?
Version v24.9.27 läuft hier ohne Auffälligkeiten
Chip-Modell ESP32-D0WD-V3 2 240 MHz 4.194.304 Byte (4 MB)
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.
Besonderheiten an diesem schmutzigen Test-Aufbau:
Sonst sollte nichts außergewöhnliches dran sein. Bei mir handelt es sich um Firmware Variante generic_esp32s3_usb
auf einem Fusion Board.
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 heap_min_free
.
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. @schlimmchen was ist denn dein MQTT Poll Intervall? Welches RF Modul ist im Einsatz? Werde jetzt noch einen Versuch machen und den MQTT broker deaktivieren.
Ich sehe auf der Konsole nur noch "Admin AP remaining seconds: 40 / 180" hochzählen, dennoch sinkt heap_min_free.
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. Habe jetzt auch nochmal die version 24.9.27 geflashed um auszuschließen das es an meinen lokalen änderungen liegt. Klappt immer noch alles.
@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.
Auf dem Chip steht esp-32s
Das Bootlog nach dem unexpected reboot, diesmal nach etwa 7min `Request SystemConfigPara [536055][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [536774][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [537784][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [538784][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [539784][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [540793][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [541793][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [542793][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [543793][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [544794][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [545794][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [546807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [547807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [548807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [549807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [550807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [551807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [552807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [553807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [554807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [555807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [556807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [557807][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [558822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [559822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [560822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [561822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [562822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [563822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [564822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [565822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [566822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [567822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [568822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [569822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" [570822][E][WiFiClient.cpp:429] write(): fail on fd 49, errno: 11, "No more processes" Disconnected from MQTT. Disconnect reason:TCP_DISCONNECTED TX ChannelChangeCommand 868.00 MHz --> 56 80 15 51 94 80 11 19 80 02 15 21 14 14 38 RX Period End All missing Nothing received, resend whole request TX ChannelChangeCommand 868.00 MHz --> 56 80 15 51 94 80 11 19 80 02 15 21 14 14 38
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 Rebooting... ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:1184 load:0x40078000,len:13192 load:0x40080400,len:3028 entry 0x400805e4 E (691) esp_core_dump_flash: No core dum▒▒▒▒ѥѥ▒▒▒found! E (691) esp_core_dump_flash: No core dump partition found!
Starting OpenDTU Initialize FS... done Reading configuration... done Reading PinMapping... found valid mapping done Initialize Network... done Setting Hostname... Configuring WiFi STA using new credentials... done Initialize NTP... done Initialize SunPosition... done Initialize MqTT... done Initialize WebApi... done Initialize Display... done Initialize LEDs... done Check for default DTU serial... done Initialize Hoymiles interface... CMT: Connection successful Setting country mode... Setting CMT target frequency... Setting radio PA level... CMT TX power set to 20 dBm Setting DTU serial... Setting poll interval... Adding inverter: 1164801xxxxx - WR1 done Adding inverter: 1164801yyyyy - WR2 done done Switch to WiFi mode Setting Hostname... done Configuring WiFi STA using new credentials... done Configuring WiFi STA static IP... done Fetch inverter: 116480155194 TX RealTimeRunData 865.00 MHz --> 15 80 15 51 94 80 11 19 80 80 0B 00 66 FA 2E DA 00 00 00 00 00 00 00 00 63 88 45 RX Period End All missing Nothing received, resend whole request TX RealTimeRunData 865.00 MHz --> 15 80 15 51 94 80 11 19 80 80 0B 00 66 FA 2E DA 00 00 00 00 00 00 00 00 63 88 45 WiFi connected WiFi got ip: 192.168.0.229 Network connected Connecting to MQTT... Connected to MQTT. RX Period End All missing`
Wie gesagt, die 24.5.6 lief/läuft stabil.
Hast du dabei die Live View offen oder die system view?
Tritt auch auf, wenn ich die System Status View anschaue und (soweit ich weiß) kein Browsertab habe, das die Live-View anzeigt.
machst du mir deine config schicken?
Ja, gerne, daran habe ich auch schon gedacht. Ging nicht eher.
config1_pretty.json
ist die Version, die OpenDTU geschrieben hat, nachdem ich den AP timeout heruntergesetzt habe. config_pretty.json
(ohne 1) ist jene von OpenDTU-OnBattery, die im flash übrig blieb nach dem Flashen von OpenDTU. Hab die Büchse dann nochmal neu gestartet mit der "reinen" OpenDTU Konfig, und das Problem besteht wie erwartet weiterhin.
Display ist übrigens keins angeschlossen, aber konfiguriert. PoE hat ist keins drauf.
Klappt immer noch alles.
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
und
wegen der Einführung von Middlewares umgebaut werden müssen.
Ansonsten wird Security.AllowReadonly nur bei checkCredentialsReadonly()
verwendet, doch dort wird bei ausgeschalteten "allow readonly access" lediglich Code durchlaufen, der ansonsten in checkCredentials()
ebenfalls und häufig durchlaufen wird und keine Probleme zu machen scheint.
Es macht auch Sinn, dass der Speicher kontinuierlich und von selbst sinkt, weil setAuthentication()
periodisch aufgerufen wird. Das ist vielleicht auch keine Absicht?
setAuthentication()
gibt es ja noch....
AsyncWebHandler& 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;
};
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.
weil setAuthentication() periodisch aufgerufen wird. Das ist vielleicht auch keine Absicht?
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. (war jetzt nur ein quick&dirty Test)
@schlimmchen es gibt zwei Punkte bei der Einführung der AuthenticationMiddleware des ESPAsyncWebServer zu beachten:
How to use authentication with AuthenticationMiddleware Do not use the
setUsername()
andsetPassword()
methods on the handlers anymore. They are deprecated. These methods were causing a copy of the username and password for each handler, which is not efficient. Now, you can use the AuthenticationMiddleware to handle authentication globally or per handler.
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
Migration to Middleware to improve performance and memory usage
AsyncWebHandler.setAuthentication(...)
=> do not use this method anymore: add a common AuthenticationMiddleware to the handler or server
@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 _freeOnRemoval
though only when the AsyncWebHandler has been handled and the request processed. So the handlers may queue up and fill up the memory.
Rest of my train of thoughts follows in english for no reason :grin:
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 username:password
string comparison - to OpenDTU using a complex AuthHandler class with an overcomplex AuthenticationMiddleware is actually a good-idea (tm) in the first place ?
As you can see it in the following source upstream, for each request the base64 encoded username:password
hash will be encoded again, even though this Token does not change, once the Attributes are set. And the actual comparison memcmp(hash, encoded, encodedLen) == 0
only takes place in line 59.
https://github.com/mathieucarbou/ESPAsyncWebServer/blob/main/src/WebAuthentication.cpp#L34-67
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 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).
Das ist richtig. Habe schon gesehen, dass es neben addMiddleware
auch ein removeMiddleware
gibt. In der "alten" API war es so, dass setAuthentication
mit leeren Parametern die Authentifizierung wieder deaktiviert hat.
Entsprechend
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 bool authenticate(const char* hash);
oben) ?
Dann könnten wir uns das aufwendige neu berechnen des hashes bei jedem Aufruf sparen.
Ich glaube sowas hier würde es tun:
An meinem PR finde ich besser, dass die Anpassung der Einstellungen event-driven ist. _lastAuthType
braucht man dann nicht.
Dann könnten wir uns das aufwendige neu berechnen des hashes bei jedem Aufruf sparen.
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 request->authenticate()
auf, aber beherrscht inbesondere die Handhabung des Middleware-Konzeptes, was wir sonst nachimplementieren müssten.
@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 X-Authentication: DIGEST username:realm:md5(username:realm:base64)
Header.
Das müssten dann alle Nutzer der REST API auch berücksichtigen.
Dein PR https://github.com/tbnobody/OpenDTU/pull/2320 ändert auch unser Auth Verfahren von BASIC Auth auf DIGEST Auth
Wenn dem so ist, müssen wir drüber sprechen. Wäre aber eine gute Gelegenheit, BASIC wegzuwerfen -- meine Meinung.
Das müssten dann alle Nutzer der REST API auch berücksichtigen.
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.
$ echo 'username:password' | base64 -
dXNlcm5hbWU6cGFzc3dvcmQK
$ echo 'username:realm:password' | md5sum -
a7c190273e23666520d7ccfec748de18 -
Also einmal
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQK
das andere Mal sendet der Server (wir) die nonce / das Passwort
WWW-Authenticate password
Und der Client muss dann die Authorization dazu passend berechnen:
Authorization: Digest username:realm:a7c190273e23666520d7ccfec748de18
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 bool authenticate(const char* hash);
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.
Wir haben m.E. auch keinen echten Sicherheitsgewinn dadurch
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 :wink:
Und ich "fürchte" mich nicht vor dem Berechnen des MD5 Hashes bzw. des Base64 Encodierten BASIC Auth tokens :grin:, 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;
}
_isDigest
und _hash
bzw. passwordIsHash
werden beim parsen des Request Headers einfach blind übernommen und mit den Client Werten aus dem Request Header gefüllt. D.h. man kann (aktuell) m.E. auch bei DIGEST Auth einen BASIC Auth Request absetzen.
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