[gelöst] Netzwerkproblem

sledge · 07 Januar 2020, 09:20:37

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.

Chris_XXX · 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)

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.

sledge · 07 Januar 2020, 17:46:52

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

Chris_XXX · 07 Januar 2020, 17:56:45

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

sledge · 07 Januar 2020, 18:12:19

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?

Wernieman · 07 Januar 2020, 19:36:34

Also RasPi und AVM-Wlan ist ein Prolem für sich, also wenn dann mit einem unabhängigen WLAN-Stick ...

Chris_XXX · 08 Januar 2020, 12:58:58

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?

sledge · 08 Januar 2020, 13:09:26

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

Wuppi68 · 08 Januar 2020, 13:35:35

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.

sledge · 08 Januar 2020, 14:16:32

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.

Morgennebel · 08 Januar 2020, 14:59:09

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

Wuppi68 · 08 Januar 2020, 15:32:28

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

Morgennebel · 09 Januar 2020, 06:43:37

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

Wernieman · 09 Januar 2020, 08:59:36

Zitat... Stromverbrauch der Dinger ...

War für mich auch der Grund mir eine andere Lösung zu suchen ...

Chris_XXX · 02 Februar 2020, 12:58:41

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