NEWS
Massive Probleme nach Austausch von Router und Mesh Repeater
-
@da_woody
Oh, das klingt interessant!!
Da würde ich, wenn ich wieder genug „Mut“, habe, etwas umzustellen, gerne nochmal draufzurückkommen, wie man das macht!@invidianer hehe, mut kann man nicht kaufen! ;)
wie es bei dem fritten zeuch genau funktioniert, kann ich dir nicht sagen. aber im grunde musst du den aktuellen lease auflösen und die alte IP an die MAC des lan-anschlusses vergeben. nennt sich dann DHCP reservierung. ich habe für neue geräte nur einen kleine freie IPrange offen wo sich ein neues gerät anmelden kann. dort sage ich dann IP reservieren, weise dem gerät die gewünschte IP zu, neustart, das gerät nimmt an hand der MAC die neu IP an und gut ists.
ist sowieso die bessere lösung, da auch nach einem stromausfall sicher gestellt ist, daß die selbe IP sicher vergeben wird. -
@invidianer sagte in Massive Probleme nach Austausch von Router und Mesh Repeater:
ISt nicht normal.
Kannst du mal auf dem PI das machen:
ping repo.iobroker.liveMal so 10-15 Zeilen laufen lassen dann mit "STRG-C" abbrechen und hier posten.
pi@raspberrypi:~ $ ping repo.iobroker.live PING repo.iobroker.live.cdn.cloudflare.net (104.21.88.137) 56(84) bytes of data. 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=1 ttl=56 time=22.9 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=2 ttl=56 time=23.0 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=3 ttl=56 time=21.7 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=4 ttl=56 time=21.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=5 ttl=56 time=21.5 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=6 ttl=56 time=21.4 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=7 ttl=56 time=22.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=8 ttl=56 time=21.10 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=9 ttl=56 time=21.6 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=10 ttl=56 time=22.6 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=11 ttl=56 time=21.0 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=12 ttl=56 time=21.1 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=13 ttl=56 time=22.2 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=14 ttl=56 time=21.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=15 ttl=56 time=22.2 ms ^C --- repo.iobroker.live.cdn.cloudflare.net ping statistics --- 15 packets transmitted, 15 received, 0% packet loss, time 35ms rtt min/avg/max/mdev = 21.048/21.971/23.007/0.634 ms -
pi@raspberrypi:~ $ ping repo.iobroker.live PING repo.iobroker.live.cdn.cloudflare.net (104.21.88.137) 56(84) bytes of data. 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=1 ttl=56 time=22.9 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=2 ttl=56 time=23.0 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=3 ttl=56 time=21.7 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=4 ttl=56 time=21.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=5 ttl=56 time=21.5 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=6 ttl=56 time=21.4 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=7 ttl=56 time=22.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=8 ttl=56 time=21.10 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=9 ttl=56 time=21.6 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=10 ttl=56 time=22.6 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=11 ttl=56 time=21.0 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=12 ttl=56 time=21.1 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=13 ttl=56 time=22.2 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=14 ttl=56 time=21.8 ms 64 bytes from 104.21.88.137 (104.21.88.137): icmp_seq=15 ttl=56 time=22.2 ms ^C --- repo.iobroker.live.cdn.cloudflare.net ping statistics --- 15 packets transmitted, 15 received, 0% packet loss, time 35ms rtt min/avg/max/mdev = 21.048/21.971/23.007/0.634 ms@invidianer Die Antwort Zeiten vom Server sind schon relativ hoch. Liegt zu 99% am Netzwerk oder der Internet Verbindung.
Meine Zeiten liegen deutlich unter 20ms.
Kannst du das auch mal von einem anderen Rechner aus machen der per Kabel an der Fritzbox hängt?
-
@invidianer hehe, mut kann man nicht kaufen! ;)
wie es bei dem fritten zeuch genau funktioniert, kann ich dir nicht sagen. aber im grunde musst du den aktuellen lease auflösen und die alte IP an die MAC des lan-anschlusses vergeben. nennt sich dann DHCP reservierung. ich habe für neue geräte nur einen kleine freie IPrange offen wo sich ein neues gerät anmelden kann. dort sage ich dann IP reservieren, weise dem gerät die gewünschte IP zu, neustart, das gerät nimmt an hand der MAC die neu IP an und gut ists.
ist sowieso die bessere lösung, da auch nach einem stromausfall sicher gestellt ist, daß die selbe IP sicher vergeben wird.@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.@wendy2702
Wenn ich den Pi per LAN-Kabel anschließe und WLAN deaktiviere, ist es dann trotzdem sinnvoll, ihn paar Meter von der 7590 zu positionieren und ist das dann egal? Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört? -
@invidianer Die Antwort Zeiten vom Server sind schon relativ hoch. Liegt zu 99% am Netzwerk oder der Internet Verbindung.
Meine Zeiten liegen deutlich unter 20ms.
Kannst du das auch mal von einem anderen Rechner aus machen der per Kabel an der Fritzbox hängt?
@wendy2702
Hmm, komisch.
Ich mache das vom Mac aus, der hat ein LAN-Kabel zur FritzBox (allerdings ist an ihm auch WLAN aktiviert, z.B. um Airdrop usw. nutzen zu können).
Meinst Du, die langen Antwortzeiten haben etwas mit der Meldung "... Updating repository stable ..." zu tun? Diese ist übrigens nach dem neu Positionieren des Pis (weit weg von der Fritte) um 09:38 Uhr nur noch ein einziges Mal aufgetaucht, nämlich um 10:19 Uhr. -
@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.@wendy2702
Wenn ich den Pi per LAN-Kabel anschließe und WLAN deaktiviere, ist es dann trotzdem sinnvoll, ihn paar Meter von der 7590 zu positionieren und ist das dann egal? Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?@invidianer WLAN kann man nicht abstellen auf dem Pi, der funkt immer durch die Gegend. Auch wenn das WLAN nicht konfiguriert ist oder per overlay softwareseitig ausgeknipst ist.
Updating repository stable kommt, wenn z.B. im Info-Adapter die Liste der Adapter neugeladen wird.
-
@invidianer WLAN kann man nicht abstellen auf dem Pi, der funkt immer durch die Gegend. Auch wenn das WLAN nicht konfiguriert ist oder per overlay softwareseitig ausgeknipst ist.
Updating repository stable kommt, wenn z.B. im Info-Adapter die Liste der Adapter neugeladen wird.
@thomas-braun
Oh, okay! Dann also Kabel dran und zusätzlich weg von der Fritte lassen. -
@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.@wendy2702
Wenn ich den Pi per LAN-Kabel anschließe und WLAN deaktiviere, ist es dann trotzdem sinnvoll, ihn paar Meter von der 7590 zu positionieren und ist das dann egal? Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?@invidianer said in Massive Probleme nach Austausch von Router und Mesh Repeater:
@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.hatte ich anfangs auch, allerdings wurden die mir dann im router nicht mehr angezeigt. der übersicht etwas nicht zuträglich...
und bei meinem netzwerk von 192.168.0.1-192.168.8.254 auch mühsam...
klar, wäre über die reservierung gegangen. IPs fix eingetragen habe ich nur mehr bei batteriebetriebenen geräten, da die batterie geschont wird. -
@invidianer WLAN kann man nicht abstellen auf dem Pi, der funkt immer durch die Gegend. Auch wenn das WLAN nicht konfiguriert ist oder per overlay softwareseitig ausgeknipst ist.
Updating repository stable kommt, wenn z.B. im Info-Adapter die Liste der Adapter neugeladen wird.
@thomas-braun said in Massive Probleme nach Austausch von Router und Mesh Repeater:
Updating repository stable kommt, wenn z.B. im Info-Adapter die Liste der Adapter neugeladen wird.
Yeah!! Gerade mal ausprobiert, auf "Info" geklickt und schon ist die Meldung im Log! Okay, danke, dann bin ich da beruhigt!
-
@da_woody
Danke, aber ich habe allen Geräten, bei denen es möglich ist, sowieso eine feste IP gegeben, DHCP nutze ich nur, wenn es nicht anders geht.@wendy2702
Wenn ich den Pi per LAN-Kabel anschließe und WLAN deaktiviere, ist es dann trotzdem sinnvoll, ihn paar Meter von der 7590 zu positionieren und ist das dann egal? Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?@invidianer sagte in Massive Probleme nach Austausch von Router und Mesh Repeater:
Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?
Sowohl als auch.
Also PI wie du selber geschrieben hast besser Stück weg von der Fritte oder an eine Stelle wo er eh nicht stört.
In der Regel fummelt man an seinem Server ja eh nur per SSH rum.
Bei mir steht das Teil auf dem Speicher bzw. hängen hinter verschlossenen Türen in zwei Unterverteilungen.
-
@invidianer sagte in Massive Probleme nach Austausch von Router und Mesh Repeater:
Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?
Sowohl als auch.
Also PI wie du selber geschrieben hast besser Stück weg von der Fritte oder an eine Stelle wo er eh nicht stört.
In der Regel fummelt man an seinem Server ja eh nur per SSH rum.
Bei mir steht das Teil auf dem Speicher bzw. hängen hinter verschlossenen Türen in zwei Unterverteilungen.
@wendy2702
Gut, dann muß ich bisschen was basteln, denn LAN-Kabel habe ich nur dort liegen, wo er jetzt steht.
Danke nochmals!Aber extrem krass: Da sucht man sich einen Wolf, hat ständig verschiedenste Fehlermeldungen der verschiedensten Adapter, wobei vorher alles topp war, und dann liegt es an einem störenden Gerät, das man schon lange problemlos im Einsatz hat, und gegen das aber ein neu gekauftes Gerät (FritzBox 7590) "allergisch" reagiert. Wie soll man da drauf kommen? ;)
-
@wendy2702
Gut, dann muß ich bisschen was basteln, denn LAN-Kabel habe ich nur dort liegen, wo er jetzt steht.
Danke nochmals!Aber extrem krass: Da sucht man sich einen Wolf, hat ständig verschiedenste Fehlermeldungen der verschiedensten Adapter, wobei vorher alles topp war, und dann liegt es an einem störenden Gerät, das man schon lange problemlos im Einsatz hat, und gegen das aber ein neu gekauftes Gerät (FritzBox 7590) "allergisch" reagiert. Wie soll man da drauf kommen? ;)
@invidianer said in Massive Probleme nach Austausch von Router und Mesh Repeater:
Da sucht man sich einen Wolf
as u say...
hab ich auch gerade hinter mir. ewig keine probleme, plötzlich keine saubere retourmeldungen von den shelly's. nach adapterstart 5 minuten alles i.o., danach switchstate rot.
backup, synology-support, FW downgrade u.s.w. ich wollte ioBroker schon in die tonne treten. eindeutig ein IGMP snooping problem mit CoAP. weis nicht mehr wie, irgendwann ist mir eingefallen, daß ich 2 managed router im netz hängen habe. dort aber nie etwas eingestellt, oder upgedatet. netgear-tool geholt, config belinst, siehe da: IGMP snooping aktiv!
deaktiviert, gleich deutsche FW aufgespielt, keine probleme mehr!
gute 2 monate rumgeeiert... :D
du siehst, daß es immer überaschungen geben kann... -
@invidianer said in Massive Probleme nach Austausch von Router und Mesh Repeater:
Da sucht man sich einen Wolf
as u say...
hab ich auch gerade hinter mir. ewig keine probleme, plötzlich keine saubere retourmeldungen von den shelly's. nach adapterstart 5 minuten alles i.o., danach switchstate rot.
backup, synology-support, FW downgrade u.s.w. ich wollte ioBroker schon in die tonne treten. eindeutig ein IGMP snooping problem mit CoAP. weis nicht mehr wie, irgendwann ist mir eingefallen, daß ich 2 managed router im netz hängen habe. dort aber nie etwas eingestellt, oder upgedatet. netgear-tool geholt, config belinst, siehe da: IGMP snooping aktiv! deaktiviert, gleich deutsche FW aufgespielt, keine probleme mehr!
gute 2 monate rumgeeiert... :D
du siehst, daß es immer überaschungen geben kann...@da_woody
Ja, krasse Geschichte!
Dachte, sowas passiert nur (fast nur) mir :-D -
@invidianer sagte in Massive Probleme nach Austausch von Router und Mesh Repeater:
Oder anders gefragt: Ist es das WLAN im Pi, welches das WLAN der FritzBox stört oder ist es ein anderes Bauteil des Pi, welches stört?
Sowohl als auch.
Also PI wie du selber geschrieben hast besser Stück weg von der Fritte oder an eine Stelle wo er eh nicht stört.
In der Regel fummelt man an seinem Server ja eh nur per SSH rum.
Bei mir steht das Teil auf dem Speicher bzw. hängen hinter verschlossenen Türen in zwei Unterverteilungen.
@wendy2702
Hmm, wenn der Pi so "strahlt", macht es vermutlich auch keinen Sinn, ihn an die Steckdosenleiste für meine Hifi-Anlage zu hängen? Gerade die wären bestimmt "empfindlich" gegenüber so einem Störenfried, oder? -
Hier wieder etwas, das ein wenig "unschön" zu sein scheint, wenn auch "nur" eine Info:
2021-03-06 11:22:44.211 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connection closed: timeout 2021-03-06 11:22:53.778 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connected with secret 1615026173777_2189 2021-03-06 11:22:53.810 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.command" 2021-03-06 11:22:53.811 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.command" 2021-03-06 11:22:53.812 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.relay.0.command" -
Hier wieder etwas, das ein wenig "unschön" zu sein scheint, wenn auch "nur" eine Info:
2021-03-06 11:22:44.211 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connection closed: timeout 2021-03-06 11:22:53.778 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connected with secret 1615026173777_2189 2021-03-06 11:22:53.810 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.command" 2021-03-06 11:22:53.811 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.command" 2021-03-06 11:22:53.812 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.relay.0.command"@invidianer nicht alle Geräte reagieren da empfindlich drauf. Muss man im Einzel Fall testen
-
@invidianer nicht alle Geräte reagieren da empfindlich drauf. Muss man im Einzel Fall testen
@wendy2702
Okay!
Sicherheitshalber lege ich den Pi aber vermutlich doch in den Kabelkanal unter meinen Schreibtisch. Dort könnte er höchstens das WLAN meines Macs stören, der aber zusätzlich per LAN-Kabel angeschlossen ist (WLAN nur, damit ich AirDrop und andere „Apple-Dinge“ nutzen kann). -
Hmm, der hier will einfach nicht verschwinden:
2021-03-06 13:55:55.234 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connection closed: timeout 2021-03-06 13:56:04.519 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connected with secret 1615035364517_7910 2021-03-06 13:56:04.556 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.command" 2021-03-06 13:56:04.557 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.command" 2021-03-06 13:56:04.562 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.relay.0.command" -
Hmm, der hier will einfach nicht verschwinden:
2021-03-06 13:55:55.234 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connection closed: timeout 2021-03-06 13:56:04.519 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] connected with secret 1615035364517_7910 2021-03-06 13:56:04.556 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.command" 2021-03-06 13:56:04.557 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.command" 2021-03-06 13:56:04.562 - info: mqtt.0 (1339) Client [shelly1-E098068D096C] subscribes on "mqtt.0.shellies.shelly1-E098068D096C.relay.0.command"@invidianer Zu mqtt und Shelly kann ich leider nichts sagen.
Aber sind die Shelly nicht auch per WLAN im Netz?
-
@invidianer Zu mqtt und Shelly kann ich leider nichts sagen.
Aber sind die Shelly nicht auch per WLAN im Netz?
@wendy2702
Ja, sind sie. Aber außer dieser Meldung ist rein gar nichts in den Logs, nachdem ich Deinem Rat folgend den Pi weit weg von der FritzBox aufgestellt habe!
Daher muß es sich wohl um ein anderes Problem handeln.Gut, die bekannten Meldungen vom DWD sind drin (kommen alle 5 Minuten), aber die sind wohl normal und nicht zu ändern (hatte ich schon immer):
2021-03-06 15:05:00.063 - info: host.raspberrypi instance system.adapter.dwd.0 started with pid 14085 2021-03-06 15:05:01.986 - info: dwd.0 (14085) starting. Version 2.7.5 in /opt/iobroker/node_modules/iobroker.dwd, node: v12.21.0, js-controller: 3.2.16 2021-03-06 15:05:06.859 - info: dwd.0 (14085) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2021-03-06 15:05:07.402 - info: host.raspberrypi instance system.adapter.dwd.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
766
Online32.5k
Benutzer81.7k
Themen1.3m
Beiträge