keine WLAN-Verbindung zum Ziel-WLAN

[rk-sTEk]

What happened?

aktuelles openDTU per git gezogen, fehlerfrei compiliert und geflasht

Der openDTU-AP läuft, ich kann auch alle Daten eingeben. Das Gerät findet allerdings das eingegebene WLAN nicht. Es wurde alles probiert, WPA+WPA2, 2.4GHz-Kanal < 11, einfache SSID ohne Sonderzeichen, einfaches Passwort nur aus Kleinbuchstaben, DHCP und Fest-IP, voreingestellte und eigene Device ID, zwei WLAN-Accesspoints (aktueller Zyxel NWA130BE und Raspi mit RaspAP). Laut AP-log erfolgt nicht einmal ein Einwahlversuch.

In der Info-Übersicht des openDTU-APs werden auch keine Angaben zum WLAN-Netzwerk gemacht.

Ich bin mit meinem Latein leider am Ende.

Das Monitoring via VSC (openIDE und ESP-IDF) bringt nur in Dauerschleife folgendes:

21:53:23.020 > WiFi disconnected 21:53:23.020 > Try reconnecting 21:53:23.023 > Network lost connection

To Reproduce Bug

Normaler Start, Login in openDTU-AP, Dateneingabe des zu nutzdnden WLANs

-> kein Anmelden im WLAN

Expected Behavior

es soll sich anmelden

Install Method

Self-Compiled

What git-hash/version of OpenDTU?

v4.4.7-dirty

Relevant log/trace output

No response

Anything else?

Hardware: ESP32-WROOM32, both USB-powered and with seperate 5V-DC-source (10W)

Please confirm the following

• [X] I believe this issue is a bug that affects all users of OpenDTU, not something specific to my installation.
• [X] I have already searched for relevant existing issues and discussions before opening this report.
• [X] I have updated the title field above with a concise description.

[DPO99]

Nutz doch mal just for fun eine pre compiled und prüfe, obs damit klappt.

[rk-sTEk]

Hab ich nach meinem Post gemacht, selbes Ergebnis. Hab sogar vorsichtshalber das Pin-Layout geladen, somit passt der RF-Chip jetzt auch.

Aber beim WLAN gab es keine Veränderung.

[DPO99]

Hm ich denke da wäre mal ein Kreuztest sinnvoll. Ist ja durchaus nicht auszuschließen, dass es auch mal einen Hardware Defekt gibt.

[stefan123t]

Vielleicht analog zu #2185 und durch #2117 begründet ?

[tbnobody]

Nein.... @rk-sTEk verwendet version 24.6.29.... #2117 ist erst in 24.8.1 eingeflossen....

[rk-sTEk]

Einen Hardwaredefekt schließe ich eigentlich aus, da der ESP-eigene AP ja läuft.

Ich hab leider keien WROOM mehr rumliegen, nur noch die "großen" ESP32-C6, da ich eigentlich alles mögliche mit Zigbee mache. Funzt da auch das "generic" oder sollte ich besser selbst conpilieren?

Und noch eine Verständnisfrage - warum hab ich trotz aktuellem Git-Rep eine ältere Version bekommen? Oder ist die 24.8.1 eine Entwicklerversion?

[schmittv]

Seit ich die Version v24.8.1 installiert habe, bricht die WLAN Verbindung zu meiner Fritz!Box nach ein paar Stunden ab. Die OpenDTU ist nicht mehr erreichbar. Nach einem Neustart läuft sie wieder für ein paar Stunden. Die Version v24.6.29 lief bei gleichem Setup über einen Monat ohne Probleme durch. Bin jetzt wieder auf die alte Version zurück.

[DPO99]

Generic und nicht sollten sich nur vom Pin mapping unterscheiden. Generell wird die generic nicht mehr empfohlen, sondern die esp32 mit Pin mapping. M.e. müsste der c6 auch gehen. Ist ja auch ein esp32 mit wroom.

Die 24.8.1.ist stable. Mir selbst kompilieren kenn ich mich leider nicht aus.

[home-cloud]

Seit ich die Version v24.8.1 installiert habe, bricht die WLAN Verbindung zu meiner Fritz!Box nach ein paar Stunden ab. Die OpenDTU ist nicht mehr erreichbar. Nach einem Neustart läuft sie wieder für ein paar Stunden. Die Version v24.6.29 lief bei gleichem Setup über einen Monat ohne Probleme durch. Bin jetzt wieder auf die alte Version zurück.

Sieht bei mir genauso aus. Die WLAN Verbindung geht nach ein paar stunden verloren. Neustart dann wieder das gleiche nach ein paar Stunden. Hab jetzt die letzte vor der aktuellen am laufen. Da sind keine Probleme.

[rk-sTEk]

Okay...ich habe etwas herausgefunden und bin der Lösung auf der Spur:

Es liegt am Verschlüsselungstyp der WLAN-verbindung. Stelle ich auf WPA2-CCMP anstatt WPA2-TKIP+CCMP, funktioniert es tadellos! Es scheint also ein Fehler in der der Espressif-IDE zu sein. Da die nach meinen Erfahrungen dort oft extrem runfummeln und nix dazu schreiben, kann es also sein, dass da im Hintergrund etwas verändert wurde.

Ich werde den source-Code mal in Richtung debugging ändern und versuche herauszufinden, was da schief geht.

[DPO99]

Ist tkip nicht eh "veraltet"? Vermutlich nutzen viele wpa2 ccmb und deswegen läuft's.

[rk-sTEk]

Das Nichtnutzen von TKIP klappt zumindest bis zur vorletzten (24.6.29) Version - in der aktuellen gibt es wohl noch ein anderes/ weiteres Problem!

Problem ist hier beschrieben und existiert wohl schon 'ne ganze Weile...

Für RaspAP: Beim Hotspot die Einstellung "Hotspot > Sicherheit - Verschlüsselungstyp" auf "CCMP" zu stellen. Sonstige wie Fritzbox und Co.: Wenn man TKIP auswählen bzw.abwählen kann, das machen. Bei meinem Zyxel bspw. heißt das WPA2-mixed, das ist kategorisch nicht zu wählen!

[DPO99]

Die Fritzbox macht glaub ich gar kein tkip mehr. Aber schön, dass es jetzt läuft.

[rk-sTEk]

Zum Problem "Kein Connect bei release v24.8.1":

Okay...wie tbnobody in den Changelog zum aktuellen Release schrieb, gab es den[ Wechsel von espressif32 von Version 6.7.0 auf 6.8.1](Update espressif32 from 6.7.0 to 6.8.1). Und genau da gab es auch einen Wechel der ESP-IDF von 5.2.1 auf 5.3.0. Hier gab es auch Änderungen im Wifi-Abteil.

Merkwürdigerweise ändert ein Wechel der zu nutzenden Plattform zurück zu 6.7.0 nichts - es findet kein Connect mit selben Fehlermeldungen statt. Also muss es noch einen anderen Grund geben.

Also Versuch des Wechsels auf Plattform 6.8.1 in der v24.6.29 - das Wifi verbindet. Es liegt also nicht an der Espressif-IDF. Ich forsche weiter...

[tbnobody]

Wie du schon schreibst hat sich nur das IDF von 5.2.1 auf 5.3.0 geändert. Das Arduino Framework blieb wie gehabt auf 2.0.17 und damit bei ESP-IDF v4.4.7

[rk-sTEk]

Da möchte ich mich entschuldigen, habe das "supported framework" glatt überlesen und als "based on" interpretiert. Asche auf mein Haupt.

Herausgefunden hatte ich aber noch folgendes: Es liegt an irgendeiner Änderung im Verzeichnis Webapp. Tausche ich das mit dem der Vorgängerversion aus (ich weiß, das ist unsauber und da gibt es garantiert jede Menge Zusammenhänge mit dem Rest), läuft der Code zumindest bzgl. Wifi-Anmeldung einwandfrei.

Leider hat sich die Syntax teilweise erheblich geändert (Befehlsende auf einmal mit Simikolon, " zu ', 11 andere dependencies, Formatvorgaben, ...), sodass es mir gerade an Zeit fehlt, den "Übeltäter" rauszufischen. Ich kann mir aber vorstellen, dass es da vlt. ein kleines Problem mit der Übertragung der Zugangsdaten gibt, denn der Fehler "AUTH_EXPIRE" könnte auch damit zusammenhängen.

[tbnobody]

Tausche ich das mit dem der Vorgängerversion aus

Hast du die WebApp auch neu kompiliert? Sonst landet rein garnichts aus dem webapp Verzeichnis unter webapp_dist und damit auch nicht in der Firmware.

Die WebApp ist auch ausschließlich ein Binärblob der zum WebClient übertragen wird. Der Code da drin hat keinerlei Einfluss auf eine Reconnect logic o.ä. Es wird ausschließlich auf die API Endpunkte zum ändern der Config zugegriffen. (Und auch nur wenn man irgendwo auf speichern drückt).

[rk-sTEk]

Nun, ich hatte immer unter Default ein "Full clean all" mit anschließendem "Build all" gemacht.

Aber Deine Antwort hat mich noch auf eine andere Idee gebracht.

Tatsächlich kann ich mich auch mit der alten Firmware erst im WLAN connecten, wenn ich den Flash komplett gelöscht habe und die Daten im AP der alten Firmware neu eingebe. Mit den eingegebenen Daten in der aktuellen Firmware klappt es nicht. Wenn ich also erst die 24.6.29 auf einen leeren/ leer gemachten Chip flashe, die Netzwerkdaten eingebe, dann erst auf die neue FW flashe und die Netzwerkdaten nicht anfasse, funktioniert es tadellos!

[tbnobody]

Nun, ich hatte immer unter Default ein "Full clean all" mit anschließendem "Build all" gemacht.

Das kompiliert nur den C/C++ Code neu. Der Typescript code (was ja die WebApp ist) wird dabei nicht angefasst. Diese muss manuell kompiliert werden (siehe Readme.md im webapp Verzeichnis)

Wenn ich also erst die 24.6.29 auf einen leeren/ leer gemachten Chip flashe, die Netzwerkdaten eingebe, dann erst auf die neue FW flashe und die Netzwerkdaten nicht anfasse, funktioniert es tadellos!

Werde ich testen...

[tbnobody]

Habe gerade einen ESP komplett neu aufgesetzt und mit dem Wlan verbunden. Klappt mit dem letzten Source Stand problemlos. (zumindest mit der Version die ich heute Abend noch releasen werde. Normal sollte #2185 hier aber nicht einspielen)

[stefan123t]

@rk-sTEk hast Du neue Erkenntnisse oder Erfahrung mit der v24.08.05 gesammelt ?

Vor allem ist das Problem dass per STA keine Verbindung zum WLAN aufgebaut wird noch bestehend bzw dass das nur bei bestimmten Verschlüsselungs Einstellungen klappt.

Wenn ich einige Posts hier lese denke ich bei denen klappt der Verbindungsaufbau ja prinzipiell, nur nach einigen Stunden ist die Verbindung halt weg, aber das kann viele Ursachen haben und scheint mir nichts mit Deinem grundlegenden Problem zu tun haben.

[rk-sTEk]

@stefan123t Sodele... v24.08.05 läuft nun seit einem knappen Monat störungsfrei.

Allerdings muss ich den ESP bei meinem Zyxel-Hotspot anmelden. In einem AccessPoint auf einem Raspi habe ich keine Chance. Da gibt sich immer wieder das alte Fehlerbild - das WLAN wird einfach nicht gefunden. Allerdings bekomme ich auch andere ESP-Projekte nicht über WiFi an den Raspi-AP mit Networkmanager dran - es scheint also ein generelles Problem zwischen der ESP32-IDF und einem AP via Networkmanager zu sein.