TASMOTA - Installation, Anwendung und Diskussion

[eisbaerin]

Dann sollte es auf jeden Fall gehen.

 

[laurent]

Also du erreichst alle deine Tasmota Geräte über VPN?

 

[eisbaerin]

Habe ich noch nicht nötig gehabt.
Ich sehe aber keinen Grund warum es gerade bei den Geräten nicht gehen soll.

Aber ich komme über VPN LAN2LAN bei einem Freund auf seine und er kommt auf meine. Da gab es noch nie Probleme.

 

[PeterPawn]

Ich tippe einfach mal ... die IP-Adressen sind "handkonfiguriert" (also kein DHCP oder zumindest nicht das von der FRITZ!Box) und bei der einen, die funktioniert, ist das Gateway korrekt gesetzt, bei den anderen nicht.

Wäre jedenfalls mein erster Blick - basierend auf der "Fehlerbeschreibung". Um per VPN erreichbar zu sein (im Gegensatz zum lokalen Netz), braucht das Gerät nun mal ein passendes Gateway.

 

[eisbaerin]

Oder sie sind in der FB für Internet gesperrt.

Gib mal bei den Geräten folgende Befehle zum Anzeigen ein:
IPAddress1 = device IP address
IPAddress2 = gateway IP address
IPAddress3 = subnet mask
IPAddress4 = DNS server IP address

 

[laurent]

Die IPs sind über DHCP verteilt worden.
Die sind nicht für Internet gesperrt.

17:18:25 CMD: IPAddress1 = device IP address
17:18:25 RSL: stat/tasmota/RESULT = {"IPAddress1":"(IP unset) 192.168.1.139"}
17:19:03 CMD: IPAddress2 = gateway IP address
17:19:03 RSL: stat/tasmota/RESULT = {"IPAddress2":"192.168.1.1"}
17:19:32 CMD: IPAddress3 = subnet mask
17:19:32 RSL: stat/tasmota/RESULT = {"IPAddress3":"255.255.255.0"}
17:19:57 CMD: IPAddress4 = DNS server IP address
17:19:57 RSL: stat/tasmota/RESULT = {"IPAddress4":"192.168.1.1"}

 

[eisbaerin]

Eigentlich alles OK.
Und das war jetzt ein Gerät welches geht oder nicht?
192.168.1.1 ist deine FB?

 

[laurent]

Ja richtig

 

[eisbaerin]

Und wie sieht es bei einem Gerät aus, welches nicht geht?
Das wäre IMO interessanter.

 

[laurent]

Das ist das Gerät wo nicht geht das ich postete.Ich habe jetzt auch mal die Beta 9.2.06 draufgemacht aber keine Besserung.Das Gerät ist unter VPN nicht erreichbar.

edit da hat wohl auch einer das selbe Problem Klick

 

[eisbaerin]

Wie machst du das VPN?

 

[laurent]

Mit meinem S10+ zur Fritzbox

 

[eisbaerin]

Ein Freund hat mir bestätigt, daß es bei ihm auch geht.
Kannst du die Geräte vom S10+ anpingen?

 

[laurent]

Ping geht aber langsam

 

[eisbaerin]

Dann geht ja die Verbindung.
Woran soll es bei dir dann noch liegen?

 

[laurent]

Wenn ich das wüsste.Das schaut so aus als wird die Seite nicht fertiggeladen.
Weil der Browser mit einem Timeout abbricht.

Wie man hier sieht ist der ping mit einem anderen Tasmota Gerät viel schneller

 

[PeterPawn]

Ich finde ja solche "Unterhaltungen" im Telegramm-Stil toll ... da kann man auch mal eine Woche gar nicht in den Thread sehen und hat anschließend trotzdem keine Probleme, das Versäumte in kürzester Zeit nachzuholen.

Ich bin mal gespannt, wie lange es dauert, bis hier die notwendigen Daten mal in einem einzigen Beitrag alle an einer Stelle versammelt sein werden, so daß man sich die Infos nicht alle erst "zusammensuchen" muß, wenn man helfen wollte (oder zumindest mit auf dem Problem herumdenken möchte).

Ich würde mir ja wünschen, daß es mal diesen einen Beitrag gäbe, in dem die Angaben der IP-Konfiguration für die funktioniernde und mind. eine der beiden nicht funktionierenden Steckdosen gegenüber gestellt werden - und ebenso die Versuche, die Geräte jeweils per ping aus dem LAN und über VPN zu kontaktieren; mit den MAC-Adressen der Geräte - quasi als Topping - oben drauf (am besten sogar mit einem Screenshot der Anzeige in der FRITZ!Box).

Denn so, wie der Screenshot vom ping oben aussieht, kann man das ja kaum als "reliable connection" verstehen ... der Blick auf die Sequence-Nummern der Pakete, auf die eine Antwort einging, verrät da ja einiges. Nur kann man auf diesem Weg halt auch nicht erkennen, ob die Request- oder die Reply-Pakete verloren gehen - aber daß da schon mit der VPN-Verbindung etwas nicht stimmt, dürfte offensichtlich sein.

Selbst wenn man die Lücke zw. 1 und 201 ignorieren wollte als "Verbindungsaufbau" (was die späte Antwort auf Seq=1 erklären könnte, denn das erste Paket wird eben zurückgehalten, bis die VPN-Verbindung steht und dann doch noch gesendet - also gibt es dafür auch noch die Chance einer Antwort), fehlen die nächsten zwei Pakete (202 und 203) ja schon wieder. Um erkennen zu können, ob sich das so fortsetzt oder nur noch ein "Schluckauf" nach dem Aufbau der SAs ist, müßte man das ping danach schon noch ein wenig laufen lassen.

Sollte sich das so manifestieren, daß auf der VPN-Verbindung regelmäßig Pakete verloren gehen, kann das am Ende sogar daran liegen, daß der Provider UDP-Pakete (in denen die verschlüsselten Daten transportiert werden) wg. Überlastung nicht transportiert und verwirft (das darf er bei UDP nun mal einfach so machen, wenn's notwendig erscheint). Passiert das aber tatsächlich nur mit bestimmten Geräten, während es mit anderen reibungslos klappt, käme wieder ein LAN-Problem in Frage.

Denn für diese Art von "Einwählverbindungen", wie sie das Smartphone vermutlich nutzt, kriegt der VPN-Client ja eine eigene IP-Adresse aus dem Netzwerk-Segment der FRITZ!Box. Bei IP ist es ja so, daß ein Client erst einmal ermittelt, ob sich ein Ziel in seinem lokalen Netzwerk befindet (das wird duirch den Vergleich der eigenen IP-Adresse und der IP-Adresse des Ziels - jeweils mit der Netzwerk-Maske "maskiert" (deshalb heißt die auch so) - ermittelt) und wenn dieser Vergleich einen Unterschied ergibt, wird so ein Paket an das lokale Gateway zur Weiterleitung übergeben, weil der Client gar keine Infos hat, wo das Ziel liegen könnte.

Aber wenn der Vergleich keinen Unterschied ergibt, dann liegt das Ziel im eigenen Netzwerk-Segment und damit wird gar kein Gateway genutzt, sondern es wird mit dem "Address Resolution Protocol" (ARP) per Broadcast-Paket nach der MAC-Adresse des einen lokalen Gerätes gefragt, das die IP-Adresse des gewünschten Ziels benutzt. Nur werden solche Broadcast-Pakete eben über eine AVM-VPN-Verbindung nicht übertragen (dazu bräuchte es eine Layer2-Bridge) und damit erhält der "suchende" Client vom tatsächlichen Ziel auch nie eine Antwort. So würde das also überhaupt nicht funktionieren und so geht man bei AVM in diesem Falle hin und verwendet eine Technik, die sich "Proxy-ARP" nennt. Hier antwortet dann die FRITZ!Box mit ihrer eigenen MAC-Adresse auf die ARP-Anfrage - sie behauptet also (aus Sicht des Clients), daß sie selbst die gesuchte IP-Adresse benutzen würde - daher setzt der Client dann die MAC-Adresse der FRITZ!Box in das zu sendende Paket ein (als L2-Ziel) und schickt das Paket auf die Reise.

Die FRITZ!Box kriegt jetzt das Paket, stellt anhand der IP-Adresse fest, daß es eigentlich für den VPN-Client gedacht ist und schickt das durch den Tunnel zu diesem. Und hier kann dann das Problem auch noch liegen ... gerade dann, wenn das im LAN (also im lokalen Netzwerksegment) alles reibungslos klappt und über VPN nicht. Denn - auch wenn ich es zuerst anders verstanden hatte - hier erfolgt die Kommunikation mit dem Smartphone (anders als die Kommunikation in einer LAN-LAN-Kopplung) eben gerade nicht anhand der IP-Adresse des Gateways, sondern hier muß Proxy-ARP einwandfrei funktionieren (und von der Software auf dem IoT-Device auch 100% umgesetzt/genutzt werden), weil die "Gegenstelle" für das IoT-Device eben im eigenen Netzwerk zu liegen scheint. Insofern gehen zwar VPN-Verbindungen auch in beiden Fällen (conntype_lan und conntype_user) über dasselbe Gerät (nämlich die FRITZ!Box), sie nehmen aber unterschiedliche Wege dorthin bzw. zumindest verwenden sie unterschiedliche Mechanismen.

Daher kann man auch die Erfahrungen von @eisbaerin (zumindest die aus #263) nur begrenzt mit denen vergleichen, die eine "Einwahlverbindung" für das VPN benutzen - aber wer aufgepaßt hat und irgendwie eine LAN-LAN-Verbindung zum Vergleichstest zur Verfügung hat, der erkennt darin auch eine Chance, das Problem weiter einzugrenzen. Denn sollte es mit einer LAN-LAN-Verbindung einwandfrei klappen, müßte man sich wohl den Proxy-ARP-Mechanismus (und die Reaktion von Tasmota-Devices darauf) genauer ansehen.

Und nur mal so "zum Spaß" und als abschließende Bemerkung meinerseits ... hat sich hier schon mal jemand die Frage gestellt (der das nicht wissen kann), ob es sich bei den berichteten "drei Tasmota-Geräten" auch um identische Geräte handelt und ob die auch alle dieselbe Firmware-Version benutzen? Ich habe nichts gefunden und ich habe auch von @laurent nichts dazu gelesen. Das ist wohl eine bisher unbestätigte Annahme und wenn sich am Ende herausstellen sollte (ich weiß es ja auch nicht), daß es da auch noch Unterschiede gibt, dann geht das hier vermutlich noch eine Weile so hin und her.

PS: Der mittlerweile nachgereichte Screenshot des ping für das andere Gerät zeigt dann ja auch wieder "lückenlose" Sequenznummern der ICMP-Kommunikation - so muß das dann tatsächlich aussehen, wenn überhaupt eine verläßliche Paket-Übertragung (die für TCP-Verbindungen wie beim HTTP unabdingbar ist) stattfindet.

 

[laurent]

Es sind drei Unterschiedliche Geräte mit dem gleichen Firmwarestand.

Gosund P1 = funktioniert nicht mit vpn
Gosund SP112 USB = funktioniert mit vpn
Sonoff TX T1 EU2C = funktioniert mit vpn

 

[Micha0815]

Gosund P1 = funktioniert nicht mit vpn

Ich habe das gerade mal mit einem POCOF2Pro und Android10 getestet. Sowohl über fremdes WLAN, Mobilfunk D1 und auch über LAN2LAN-VPN (als dortiger WLAN-Client) gibt es kein Problem. Hast Du für die P1-GUI eine User/PW-Kombi vergeben?
LG

 

[laurent]

Nein Passwort habe ich nicht vergeben.