ffreddow

Interessant, 51821 wird in jedem Fall benutzt wenn eine Verbindung über den Fernzurgiff aufgebaut wird. Vielleicht ist dein Router/ISP auch einfach sehr aggresiv, was das schließen von UDP "Verbindungen" (technisch gesehen gibt es die nicht) angeht. Über die Management Verbindung werden nur alle paar Sekunden Pakete hin und her geschickt um das "Loch" in der Firewall offen zu halten. Auf den anderen Ports herrscht viel mehr Verkehr, deshalb werden die eventuell nicht geschlossen. Welchen Router und ISP nutzt du, wenn ich fragen darf?

@Ben77 sorry, ich hatte mich verlesen. Du hattest nach port 51820 TCP gefragt, der wird nicht benutzt. War das nen Tippfehler von dir oder hat das Freigeben von 51820 TCP tatsächlich ein Problem gelöst?

Genau, die Box muss auf 51820 - 51825 UDP raus können. 51820 ist für die Management Verbindung über die die Box aufgefordert wird Verbindungen auf zu machen und die restlichen ports sind für die bis zu fünf Verbindungen, die wir gleichzeitig erlauben. Normalerweise macht WireGuard das Hole-punching von selber, nur wenn man ausgehenden traffic explizit verbietet sollte es da zu problemen kommen. Die Ports müssen dauerhaft erlaubt sein, aber es muss kein Portmapping gemacht werden.

Das heißt der fix, den ich gestern eingebaut habe funktioniert erstmal grundlegend. Manchmal muss sich erst jemand beschweren ;) Kannst du mal die App in den debug modus bringen (Nutzer->Lokale einstellungen-> Debug modus) und wenn es dir zu lange dauert den PCAP-Log speichern (Der Knopf, der unter der Darstellung des Webinterface auftaucht) und mir per PN schicken? Bitte in Sitzungen von denen du einen PCAP-Log erstellst keine Passwörter o.ä. eingeben, da dabei der rohe unverschlüsselte Datenverkehr mitgeschnitten wird und die dementsprechend da drin auftauchen würden. Die funktion haben wir absichtlich deaktiviert, weil wir uns dadurch regelmäßig unbeabsichtigt die Verbindungen geschlossen haben. Da ist und wohl nen Link durch die Lappen gegangen. Normalerweise wollen wir alle externen Links aus der App raus halten, damit sowas nicht passiert. Das ist allerdings etwas, was erst durch ein Firmware-Update gefixt werden kann, da das Webinterface von der Wallbox geladen wird.

Dass die Verbindung neu geladen wird nachdem die App aus dem Hintergrund wieder kommt ist gewollt. Wir hatten Probleme mit Apps, die sporadisch tot waren als sie aus dem Hintergrund kamen und die gesamte App einmal neu zu laden war das einzige was erstmal Abhilfe geschaffen hat. Deinen Usecase hatten scheinbar weder ich noch jemand anderes, der die App bis jetzt genutzt hat. Trotzdem ist das etwas was funktionieren darf und ich werde nochmal Zeit in die Suche nach einer alternative zur einfachen Hau-Drauf-Lösung stecken müssen. Ein Bug dem selben Effekt ist uns bekannt und ist seit kurzem gefixt. Wann hattest du das Problem denn das letzte mal?

Moin, danke für den Hinweis! Wir haben das Problem auch schon bei der Android App festgestellt und versuchen aktuell es zuverlässig zu reproduzieren. War das Menü schon weg bevor du dich zur Wallbox verbunden hast? Und hast du dich direkt davor in der App eigeloggt? Edit: Haben das Problem gefunden und behoben. Kann sein, dass du die App einmal komplett schließen und wieder neu öffnen musst.

Hattest du den Fernzugriff auf der Box schonmal eingerichtet? Habe eben nen Bug gefixt, bei dem sowas passiert wenn man die Box aus dem Fernzugriff nimmt und wieder hinzufügt ohnen neuzustarten. Du meinst das Passwort der Nutzer lokal auf der Wallbox? Wir hatten irgenwann mal nen Autologin für die App diskutiert und es dann aber erstmal beiseite gelegt, weil es doch die ein oder andere Fußangel mit sich gebracht hat. Vielleicht muss man das nochmal aus der Schublade holen.

Moin, vermutlich wird das daran liegen. Der Fernzugriff ist was die Netzwerkqualität angeht leider recht sensibel. Ich gehe mal davon aus, dass der reine Verbindungsaufbau klappt, aber das laden des Webinterfaces ziemlich lange dauert. Wie lange hast denn gewartet? Eventuell wäre es auch eine Idee die Animation zu wechseln wenn der Verbindungsaufbau erfolgreich war und das Webinterface geladen wird. Erkennen, dass man sich im Heimnetzwerk befindet ist schwierig bis unmöglich, da jedes Heimnetz anders aussieht. Man könnte eventuell versuchen den auf der Wallbox konfigurierten Hostnamen lokal aufzulösen. Ich rieche aber schon Probleme wenn man sich in öffentlichen Netzen befindet, da muss ich mit den Kollegen mal drüber quatschen wenn die aus dem Urlaub wieder da sind.

E-Mail-Adressen sind komplizierter, als sie aussehen: Grundsätzlich sind sie Case-Sensitiv, ABER sie können case-insensitiv verglichen werden, was wir auch tun (aBc@c.de ist aus Sicht des Servers das gleiche wie abc@c.de). Dass wir diese Konvertierung machen müssen hab ich beim schreiben der Account-Synchronisierung und der Tests übersehen/vergessen, was dazu führt, dass der Server in deinem Fall dachte, dass er den Nutzer nicht kennt und die Wallbox hat ihn darauf hin rausgeschmissen. Vor dem Update hat es keinen Unterschied gemacht, da die Account-Synchronisierung noch nicht existierte. Danke für die Rückmeldung mit dem Workaround, das hat mir einiges an Sucherei erspart 😅 TL;DR: Es sollte auch weiterhin funktionieren, ist aber einfach auf unserer Seite kaputt.

Moin, das ist natürlich gelinde gesagt äußerst unschön. Ich konnte zu deiner Wallbox auch keinen zugeordneten Nutzer auf dem Server finden. Hab sie jetzt vom Server entfernt, versuch bitte mal den fernzugriff zu deaktivieren, dann neustarten und nochmal wieder hinzufügen. Werde mich derweil auf die Suche nach der Ursache begeben.

Der Knopf taucht erst auf wenn der Slot blockiert

Moin, wir sind noch auf einige Bugs speziell mit/in der App gestoßen, die das ganze Verzögert haben. Aktuell laufen wieder Tests, wenn diese erfolgreich sind gehts weiter.

Eine richtige Nutzerverwaltung im Webinterface der Wallbox wird schwiering, da wir dafür erst Role Based Access Control auf der Wallbox selber implementieren müssten. Eine Nutzerverwaltung für den Fernzugriff ist geplant, ergibt aber erst wirklich Sinn sobald mehrere Nutzer Fernzugriff auf eine Box haben. Was genau meinst du mit Standorte? Einfach ein Freitext-Feld zum notieren des Standortes? Normalerweise bewegt sich so eine Wallbox in ihrem Leben ja nicht ganz viel (Und falls doch wüsste ich gerne was du damit machst ;) ) Meinst du damit zum Anmelden der Wallbox beim Fernzugriff? Falls nein: Bei Jemandem, der die Wallbox ohne OCPP per API übers Internet steuern will würde ich jetzt einfach mal vorraussetzen, dass er weiß wie man den Nutzerkonfigurierbaren Wireguard-Zugang konfigurieren kann. Falls Ja: Für das Einrichten sobald es mehrere Fernzugriffsnutzer für eine Box gibt ist es tatsächlich eine gute Idee Einmalcodes zum Einrichten zu generieren. Bei aktuell einem Nutzer bietet es aus meiner Sicht wenig bis keinen Mehrwert, da sich intern sowieso jede Wallbox individuelle Zugangsdaten mit dem Server aushandelt und das Passwort nicht auf der Box gespeichert wird. Der Zugriff mit mehreren Nutzern auf eine Box sollte allerdings nicht mehr lange auf sich warten lassen, da das ein oder andere interne Projekt daran hängt und es dementsprechend eine recht hohe Priorität hat.

Das war so weit erwartet, da es (wie im Changelog im ersten Post beschrieben) brechende Änderungen gab. Vielleicht nochmal als kleiner Disclaimer, da es im Post nicht explizit drin steht (passe ich an): Der Fernzugriff sollte während er noch nicht in einer "offiziellen" Firmware veröffentlicht ist auf keinen Fall als einziger Zugang zur Wallbox benutzt werden, da es immer wieder zu brechenden Änderungen kommen kann (auch wenn wir versuchen das zu vermeiden). Das Hört sich doch super an! Dann hing der PDF-Bug wirklich wie erwartet mit den allgemeinen Safari-Problemen zusammen.

Das update ist ausgerollt