Hallo zusammen,
hat hier jemand tiefgreifende Netzwerkkentnisse? Ich bin mit meinem Latein am Ende.
Folgendes Problem: Alles fing damit an das ein Tasmota Gerät keine Verbindung mehr zum MQTT Broker aufbauen kann. Nur eines, andere funktionieren, dieses hat auch schon mal funktioniert und ich habe natürlich nix gemacht ;D
Angebunden ist das Teil über WLAN. IP bekommt das Gerät. Der Webserver des Geräts funktioniert auch. Konsole gibt diese Fehlermeldung aus:
19:54:35 MQT: Verbindung fehlgeschlagen aufgrund von MQTTServer:1883, rc -2. Wiederversuch in 10 s
19:54:35 UPP: Multicast (wieder-)verbunden
Der rc=-2 sagt aus dass der den Server nicht erreicht.
Und jetzt kommt der Teil an dem ich aussteige:
Ein Ping zu dem Gerät aus dem WLAN funktioniert nicht aber aus dem LAN. Mein MQTT Broker ist per LAN angebunden. Also wird wohl zwischen WLAN und LAN was nicht durchgereicht?
Die anderen Geräte lassen sich problemlos pingen. FritzBox habe ich restartet. MAC aus dem MAC Filter genommen und neu rein. Hat nix gebracht.
Firmware habe ich rauf und runter geflasht - Bringt nix.
Firewall habe ich keine in meinem Heimnetz aktiv.
Freiwillige vor - hatte jemand schon mal so ein Problem bzw. jemand eine Idee was das sein kann?
Viele Grüße
Christian
Wie viele DHCP-Clients sind im Netz und sind da auch Repeater?
Ciao, -MN
Bei mir läuft alles über DHCP - Allerdings bei diesem Geät statisch. Aktuell sind 14 Geräte aktiv.
Keine Repeater.
Vielleicht hat ein Gerät über DHCP Deine statische IP bekommen und die ist jetzt doppelt im Netz?
Oder hast Du diese statische IP aus dem DHCP-Vergabe-Bereich ausgenommen? Mach das Gerät mal stromlos, und schau, ob die IP immer noch pingbar ist
Ich habe die statische auch schon getauscht bzw. eine dynamische vergeben lassen. Das Gleiche in Grün
Fritzboxen sind bekannt für Probleme mit vielen DHCP Clienten.
Hast Du einen RPi übrig, auf dem Du pihole mit DHCP-Server installieren kannst?
Ist Dein MQTT Server überlastet und kann nicht antworten?
Ciao, -MN
Pi hole hab ich am laufen aber ohne DHCP. Ich werde den mal einrichten und testen.
Der mqtt kann das Gerät ja nicht mal anpingen. Überlastet mit 15 Geräten glaube ich jetzt mal nicht. Ein Blick in den top sagt eher dass sich das Teil langweilt.
Das hat mit der Fritzbox nichts zu tun, denke ich.
Und dass die mit dem bisschen DHCP überlastet wäre, ist mir auch neu.
Ausserdem wurde ja eine statische IP vergeben, also Fritz DHCP sowieso egal in dem Fall.
Und ist ja auch per Webbrowser und Ping erreichbar. Also da brauchen wir wohl nicht suchen.
Du schreibst, dass Du aus dem LAN an das Device pingen kannst, aber nicht aus dem WLAN.
Dann müsstest Du doch den Broker erreichen, der ist ja auch im LAN.
Funktioniert Ping vom Broker zu dem Device?
Nicht ganz. Das Gerät hängt im WLAN und lässt sich aus dem WLAN pingen. Der broker hängt im Lan und kann das Gerät nicht pingen. Der broker kann aber andere WLAN Geräte ohne Probleme pingen.
Können andere Geräte im LAN (ausser dem Broker) das Teil pingen?
Alle über DHCP versorgt?
Könnte ne falsche netzmaske sein wenn statisch versorgt.
ViIelleicht mal testweise per DHCP ins WLAN und von anderen DHCP Geräten (LAN und WLAN) versuchen.
Und mal die fritte durchstarten. Das schadet nie wenn es komische Effekte gibt.
Gesendet von meinem Doogee S60 mit Tapatalk
Bei statischer Adressierung fallen mir dann noch die üblichen Verdächtigen ein:
- Subnetzmaske
- DNS Server Eintrag (würde eher zum Log passen bei angabe von MQTTSERVER) - nicht aber zum pingen per IP
- Gateway
Sind die WLAN Clients und der Broker im gleichen IP Subnetz ? oder sind es unterschiedliche Subnetze und es kann ein Routingproblem sein (würde zum Punkt mit dem GW passen)
Hat der Broker ggf. eine Firewall ?
Hängt der Broker nur via Kabel im Netz oder zusätzlich via WLAN ?
Mit statisch versorgt meinte ich am DHCP habe ich für dieses Gerät eine bestimmte IP hinterlegt. Sorry, habe ich wohl falsch formuliert. Die IP habe ich auch schon geändert.
Rebooted habe ich alles. Bzw sogar stromlos gemacht.
Broker nur per LAN. Firewall hat er keine
Alle im gleichen subnetz.
DNS kann es auch nicht sein. Habe es mit der IP probiert.
Wäre es nicht einfacher für helfende wenn die genau wüssten wie die IP Konfig aussieht? Also so schwarz auf weiß? Ist nur so eine Idee.
Popcorn?
Zitat von: CoolTux am 06 Januar 2020, 21:09:14
Popcorn?
Gebuttert bitte. [emoji6]
Gesendet von meinem Doogee S60 mit Tapatalk
Nochmal meine Frage: Können andere Geräte im LAN das Teil pingen?
(WLAN jetzt erstmal egal)
Keiner aus dem LAN kann es pingen
Broker hat 192.168.99.13
Gerät hat 192.168.99.215
Subnet 255.255.255.0
Gateway 192.168.99.1
Was ist bei deiner Fritzbox als IP Range angegeben?
Die IPs des statischen DHCP Mappings sollten immer ausserhalb der DHCP Range liegen.
Range ist 192.168.99.20-60
Ubringes 192.168.99.216 ebenfalls WLAN lässt sich pingen
Aber einen Webserver auf 99.215kannst du normal erreichen?
Vielleicht doch einmal die Ausgabe von ifconfig zeigen?
Ein "Tasmota Gerät"hat glaube kein ifconfig. Oder?
Dann nehme ich alles zurück und behaupte das Gegenteil. Hatte gehofft, Aufschluß über ein ggfs. vorliegendes IPv4/v6 Problem zu bekommen. Ziehe sofort den Kopf ein.
Guten Morgen zusammen,
hier die ifconfigs bzw. so etwas in der Art.
Broker (LAN):
ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.99.13 netmask 255.255.255.0 broadcast 192.168.99.255
inet6 fe80::de8f:f2f5:2657:bd58 prefixlen 64 scopeid 0x20<link>
ether b8:27:eb:d3:f2:95 txqueuelen 1000 (Ethernet)
RX packets 339063 bytes 209935584 (200.2 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 435491 bytes 276691767 (263.8 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
ip route
default via 192.168.99.1 dev eth0 src 192.168.99.13 metric 202
192.168.99.0/24 dev eth0 proto dhcp scope link src 192.168.99.13 metric 202
Tasmota Gerät:
IP-Adresse 192.168.99.215
Gateway 192.168.99.1
Subnetzmaske 255.255.255.0
DNS-Server 192.168.99.1
Und ich erweitere meine Aussage: Auch der Webserver vom Tasmota Gerät lässt sich nicht über LAN ansprechen. Würde behaupten das ist aus dem LAN gar nicht erreichbar.
VG
Moin moin,
Ein anderer Gedanke, vielleicht eine doppelte MAC Adresse?
Die sind eigentlich eindeutig, kann man aber über die config ändern.
Ob auch bei ESPs mit Tasmota weiß ich nicht.
Ist aber ein Blick wert.
Gesendet von meinem Doogee S60 mit Tapatalk
Es scheint ein ziemlich seltsamer Fehler zu sein.
Wenn Du das Tasmota Gerät aus dem WLAN raus anpingen kannst, aber aus dem Lan nicht. Wenn Du aus dem Lan andere WLAN Geräte anpingen kannst scheint das ein Problem mit dem Tasmota zu sein. Warum auch immer.
Andere Geräte scheinen ja von Lan zu WLAN zu gehen. Oder?
Wenn die Ideen die nächsten Tage hier nichts bringen Kauf Dir ein neues. Der Stress ist es nicht Wert.
Kriegt man bei einem Tasmota Gerät relativ einfach die MAC raus?
Sind auf der fritte für dieses gerät spezielle "Einstellungen" eingerichtet worden?
Zitat von: Wernieman am 07 Januar 2020, 08:06:35
Kriegt man bei einem Tasmota Gerät relativ einfach die MAC raus?
Sind auf der fritte für dieses gerät spezielle "Einstellungen" eingerichtet worden?
Tasmota spukt bereitwillig unter einer der vielen Statusmeldung die MAC-Adresse aus.
Viele Grüße Gisbert
Also die Mac ist eindeutig. Hab diese mal an der fritzbox gesperrt und wieder freigeschaltet. Fehlereinträge an der Fritzbox decken sich mit den Power on off Vorgängen vom Gerät.
An einen Neukauf habe ich auch gedacht. Nur habe ich 10 Stück von den dingern im Einsatz. Und wenn das öfters passiert....
Mein letzter Gedanke war auch das tasmota oder die Hardware nen hau weg hat - aber da kenne ich mich nicht wirklich aus. Firmware habe ich bereits neu geflasht.
Kann die Hardware einen defekt haben dass es zu so einem Fehler kommt?
Muss man im Tasmota die Broadcast-Adresse "192.168.99.255" konfigurieren? Es scheint, dass er seine Adresse nicht bekannt gemacht hat.
"arp -a" gibt Aufschluss.
Schon mal "arp -i eth0 -s 192.168.99.215 MAC:des:Tasmota" probiert?
Grüße aus Brandenburg
Zitat von: Chris_XXX am 07 Januar 2020, 08:32:48
Also die Mac ist eindeutig. Hab diese mal an der fritzbox gesperrt und wieder freigeschaltet. Fehlereinträge an der Fritzbox decken sich mit den Power on off Vorgängen vom Gerät.
An einen Neukauf habe ich auch gedacht. Nur habe ich 10 Stück von den dingern im Einsatz. Und wenn das öfters passiert....
Mein letzter Gedanke war auch das tasmota oder die Hardware nen hau weg hat - aber da kenne ich mich nicht wirklich aus. Firmware habe ich bereits neu geflasht.
Kann die Hardware einen defekt haben dass es zu so einem Fehler kommt?
Sofern die Tasmota-Steckdose über das Webinterface sauber schaltet und erreichbar ist, ginge ich zunächst nicht von einem HW-Defekt aus. Ggf auch mal das Web-Logging in der Tasmota-Oberfläche hochdrehen und beobachten, was passiert.
Falls vorhanden: Man kann in Tasmota auch einen syslog-Server angeben und dorthin loggen lassen - somit kann man zumindest die Verbindung Tasmota -> LAN unabhängig vom MQTT-Server testen.
Welche Tasmota-Version wird verwendet?
Und bzgl. Fritzbox / WLAN: Mit der echten Auslastung der FB hat das wenig zu tun, aber ich kenne jetzt hier aus dem Forum einige Fälle (mich eingeschlossen), wo die Zunahme von WLAN-Clients die Fritzbox an ihre Grenzen gebracht hat, auch wenn diese anscheinend vor sich hin-schlummert.
Tasmota Version war 6.7.1 (auf den anderen Geräten noch immer erfolgreich im Einsatz) und ist jetzt auf dem "defekten" Gerät 8.1.0 (diese Version hat übrigens einen RGB Regler für Lampen - aber das nur am Rande)
Das Logging spuckt nicht wirklich was brauchbares aus:
17:27:07 HTP: Einstellungen
17:27:08 CFG: in Flash gespeichert am F4, zählen 184, Bytes 4096
17:27:15 UPP: Multicast deaktiviert
17:27:15 MQT: Verbindungsversuch...
17:27:20 MQT: Verbindung fehlgeschlagen aufgrund von pike:1883, rc -2. Wiederversuch in 10 s
17:27:21 UPP: Multicast (wieder-)verbunden
17:27:22 HTP: MQTT konfigurieren
17:27:25 HTP: Einstellungen
17:27:26 UDP: Packet (123)
17:27:27 WIF: Prüfe Verbindung...
17:27:27 WIF: verbunden
17:27:30 HTP: Gerät konfigurieren
17:27:31 UDP: Packet (123)
17:27:31 UPP: Multicast deaktiviert
17:27:31 MQT: Verbindungsversuch...
17:27:36 MQT: Verbindung fehlgeschlagen aufgrund von pike:1883, rc -2. Wiederversuch in 10 s
17:27:36 HTP: Einstellungen
Syslog host mit WLAN habe ich leider keinen.
Wie äußern sich die Grenzen des WLANs bei der FritzBox?
Mir würden Verbindungsabbrüche etc. eingehen aber nicht Probleme bei einem spezifischen Gerät.
Zitat von: Chris_XXX am 07 Januar 2020, 17:31:18
Tasmota Version war 6.7.1 (auf den anderen Geräten noch immer erfolgreich im Einsatz) und ist jetzt auf dem "defekten" Gerät 8.1.0 (diese Version hat übrigens einen RGB Regler für Lampen - aber das nur am Rande)
[...]
Syslog host mit WLAN habe ich leider keinen.
Wie äußern sich die Grenzen des WLANs bei der FritzBox?
Mir würden Verbindungsabbrüche etc. eingehen aber nicht Probleme bei einem spezifischen Gerät.
Ok, zu Tasmota-Version 8.1 kann ich leider nicht viel sagen, habe hier 6.7.X und 7.1.X erfolgreich und durchaus flächendeckend im Einsatz.
Bzgl. Fritzbox / WLAN: Verbindungsabbrüche oder einzelne Geräte fallen aus dem Wifi und reconnecten sich nicht mehr, wodurch sie nicht mehr seitens FHEM angesprochen werden können.
Also folgende Annahmen:
1. Das Gerät schaltet einwandfrei via Webinterface (wurde nicht beantwortet, aber nehme ich an) => HW im Wesentlichen ok
2. Die Verwendung der recht neuen Tasmota-Version 8.1.0 ist unbedingt erforderlich? Sonst ggf mal auf eine der bei Dir einwandfrei funktionierenden Versionen zurückflashen?
3. MQTT-Username / Password sind auch sicherlich korrekt gesetzt?
4. Namensauflösung in dem WLAN geht einwandfrei? Mal "pike" durch 192.168.XX.YY ersetzt?
Kurze Suche bei Google: https://forum.creationx.de/forum/index.php?thread/1161-verbindung-fehlgeschlagen-aufgrund-von-192-168-178-220-1883-rc-2-wiederversuch-i/ bringt ein vergleichbares Fehlerbild - auch hier lag es am WLAN...
Gruß,
Tom
Hi Tom,
Also
1: ja geht. Komme aber nur drauf wenn der Client auch im WLAN ist
2: werde ich testen. Ist nur drauf weil der Fehler plötzlich auftrat
3: passt
4: bereits gemacht. Bringt nix
Das Thema mit den repeatern habe ich gefunden - nur habe ich keine. Normale switche habe ich einige. Aber selbst die habe ich Rebooted...
Vg
Hi Chris_XXX,
ohne es zu wissen - eher im Sinne von Gedanken sammeln:
1. Logging-Level für MQTT in Tasmota auf max?
2. Logging-Level für Web-Oberfläche in Tasmota auf max?
Und: Das mit Syslog könntest Du ohnehin versuchen, wenn Du eine Büchse verfügbar hast. Entweder Deinen Laptop mit einer Virtualbox / VMware schnell auf Linux heben und dort hin loggen lassen oder ggf einen RaspBi - sofern verfügbar - aufmotzen.
Achja: Der MQTT-Server merkt gar nichts von den Verbindungsversuchen? also Verbose = 5 oder strace?
EDIT: Oder einfach den Tasmota mit "reset 5" nochmal neu aufsetzen?
Also RasPi und AVM-Wlan ist ein Prolem für sich, also wenn dann mit einem unabhängigen WLAN-Stick ...
Hallo meine Freunde der heiteren Fehlersuche ;)
Ich bin einen Schritt weiter oder auch nicht?
Ich habe eine zweite Fritzbox. Diese arbeitet nicht als Repeater. Sie hängt mit einem Schnorchel im LAN und strahlt die gleiche WLAN SSID aus. Diese Fritzbox ist aber nur bei Bedarf in Betrieb. Ich habe nun das WLAN an meiner primären Fritzbox deaktiviert und die zweite Box angeschaltet. Das Tasmota Gerät konnte sich verbinden und auch wieder seinen Borker erreichen. Zweite Box wieder aus, erste an, nix geht mehr. Alle anderen Geräte nach wie vor kein Problem.
FritzBox restten wäre ein Gedanke aber ich habe eine ziemlich umfangreiche Konfigurtion. Stromlos habe ich sie schonmal gemacht. Hat nix gebracht. Hat jemand eine andere Idee?
Ich bleibe bei meiner grundsätzlichen Aussage zum Thema Fritzbox und IoT-Wifi. Ich habe hier zuerst in 3-4 FB invenstiert, diese mit MESH usw zusammengedrahtet und weiß nicht was. Seit Unifi habe ich Ruhe und ein äußerst performantes Netzwerk in Summe...
Aber schön, dass es nicht am Device selber liegt - Lösungsvorschläge hast Du ;-)
nen Reset der Fritte hat in der Vergangenheit nicht viel gebracht - die WLan Probleme sind bei den meisten geblieben.
Fritten zu meshen scheint eine Lösung zu sein, aber gibt es auch da eine kritische Grenze an der das Verhalten unvorhersehbar wird?
Eine Umstellung des WLans auf zB. Ubiquiti AC Pro ist eine stabile, skalierbare und kostengünstige Lösung.
Zitat von: Wuppi68 am 08 Januar 2020, 13:35:35
Fritten zu meshen scheint eine Lösung zu sein, aber gibt es auch da eine kritische Grenze an der das Verhalten unvorhersehbar wird?
Eine Umstellung des WLans auf zB. Ubiquiti AC Pro ist eine stabile, skalierbare und kostengünstige Lösung.
Ad "MESH": Ging bei mir ab ~20-25 Devices auch nicht mehr wirklich zuverlässig. Nicht-deterministisches Verhalten in meinem Netzwerk is no-go. Zumindest war das der Sachstand Anfang 2018, als AVM gerade das MESH-Feature in place hatte und ich dann doch zu Unifi wechselte.
Ad Unifi: Ich betreibe hier sogar "nur" die Ubiquiti AC-AP Lite Version - mit ~80€ günstig und vom Durchsatz her für alles in meinem Netzwerk hinreichend.
Zitat von: sledge am 08 Januar 2020, 14:16:32
Ad "MESH": Ging bei mir ab ~20-25 Devices auch nicht mehr wirklich zuverlässig. Nicht-deterministisches Verhalten in meinem Netzwerk is no-go. Zumindest war das der Sachstand Anfang 2018, als AVM gerade das MESH-Feature in place hatte und ich dann doch zu Unifi wechselte.
AVM Mesh war mit 7.04 eine Katastrophe und ist so lala bis manchmal stabil mit 7.12 in meinem Netzwerk: 1 * 7490 + 2 * 1750E Repeatern als Mesh, WiFi-only, 37 Clienten. DHCP hat ein pi-hole übernommen, Repeater haben statische IPs.
Ich zähle die Tage, bis ich Zeit habe, meine Cat6A-Kabel zu ziehen und dann bald auf Ubiquiti wechseln kann. Sobald Glasfaser kommt...
Ciao, -MN
Zitat von: Morgennebel am 08 Januar 2020, 14:59:09
AVM Mesh war mit 7.04 eine Katastrophe und ist so lala bis manchmal stabil mit 7.12 in meinem Netzwerk: 1 * 7490 + 2 * 1750E Repeatern als Mesh, WiFi-only, 37 Clienten. DHCP hat ein pi-hole übernommen, Repeater haben statische IPs.
Ich zähle die Tage, bis ich Zeit habe, meine Cat6A-Kabel zu ziehen und dann bald auf Ubiquiti wechseln kann. Sobald Glasfaser kommt...
Ciao, -MN
die Ubiquitis können auch den Uplink via WiFi ;-)
PS.: Momentan werden bei Ebay die Cisco 3750Xer Switche wegen End Of Life super günstig gehandelt. Da bekommt man schon einmal einen 24 POE Switch mit Gigabit Ports und der Option auf 10GBit Ports für 50-100 Eurinchen - sind halt nur nicht Wohnzimmer geeignet da die Lüfter doch ein wenig Sound abgeben
Danke,
Ciscos kann ich in der Firma umsonst abstauben. Lüfterwechsel soll auch möglich sein und iOS ist geil. Aber der Stromverbrauch der Dinger und die Sicherheitslücken...
Ciao, - MN
Zitat... Stromverbrauch der Dinger ...
War für mich auch der Grund mir eine andere Lösung zu suchen ...
Hallo zusammen,
ich habe doch noch das Problem gefunden. Ich habe im Hostnamen der Geräte den Unterstrich "_" durch einen Bindestrich "-" ersetzt. Und siehe da alles funktioniert wieder.
Verstehen tue ich das aber nicht. Zuerst war alles Tutti mit dem Unterstrich, dann hat ein Gerät angefangen zu spinnen und nach und nach alle.... Wunder der Technik.
Nun ja, falls jemand ein ähnliches Problem hat - bei mir hat das geholfen. Fragt sich für wie lange ;)
Viele Grüße
Christian
https://de.wikipedia.org/wiki/Hostname (https://de.wikipedia.org/wiki/Hostname)
Ich würde eigentlich bei hostname auf Sonderzeichen verzichten ...
Eigentlich gebe ich dir recht. Was mich trotz allem irritiert: Ging mal, geht auf einmal nicht mehr. Das entspricht jetzt nicht so dem 0 und 1 Prinzip. :)
Naja ... durch ein Update ....