Raspberrymatic wechselt selbständig nach einiger Zeit MAC Adresse und ist über WEB nicht mehr erreichbar

[jp112sdl]

Es gibt hier anscheinend auch zwei "Lager"

"Egal" würde ich nicht sagen.
Das Problem verlagert sich nur irgendwie gerade vom Pi zum Router.
Denn der eigentlich problemlos funktionierende Workaround "statische IP bei wechselnder MAC" scheint ja ein neues Problem (routerseitig) aufzuwerfen.

Ich glaube weiterhin, es ist hier eine ungünstige Konstellation von Kernel und Pi-Chipsatzfirmware und hoffe für die MAC-Wechsel-Geplagten, dass das mit einer zukünftigen RM Version wieder weg ist.

[Xel66]

...persönlich habe immer schon mit festen IP-Adressen gearbeitet außerhalb des DHCP Bereichs...

Nur fürs Protokoll, weil dort viele Missverständnisse herrschen. Man muss bei den "festen" Adressen eben zwei Dinge unterscheiden. Es gibt viele Anwender, die eine Zuweisung reservierter IPs (zur MAC) für eine feste Adresse halten (Routerfunktion: "Diesem Gerät immer die gleiche IP zuweisen"). Das ist aber nicht so. Es ist immer noch DHCP und somit eine dynamische Zuweisung durch den DHCP-Server, nur dass der eben immer die gleiche Adresse zuweist.

Eine feste IP wird aber im Gegensatz zu vorherigen Vorgehensweise in dem jeweiligen Gerät selbst (welches ggf. Dienste im Netz anbietet) konfiguriert. Der Vorteil dieser Vorgehensweise ist, dass eine Kommunikation auch ohne jegliche Beteiligung des Netzrouters erfolgen kann (natürlich nicht ins Internet). Heißt, eine CCU ist immer noch in der Lage, irgendwelche Geräte im Netz (Gateways, Bridges, Cams etc.) anzusprechen und die Automation läuft. Das natürlich nur, wenn alle an einem separaten Switch und nicht an einen der vier Netzwerkanschlüsse eines Standardrouters angeschlossen sind. Bei der Vielzahl von Heimgeräten heutzutage ist ein solcher wohl meist Standard.

Bei der Adressreservierung geht diese vermeintlich "feste" Vergabe spätestens bei einem Routertausch (auf dem ja meistens im Heimbereich der DHCP-Server läuft und die IPs im Netz zuweist) verloren. Bei einer festen Zuweisung (im Gerät) bleiben die Einstellungen auch bei einem Routertausch erhalten. Das Einzige was man bei einem Routertausch tun muss ist, den Adressbereich des Routers und des DHCP-Servers auf seine alten Einstellungen anpassen (wichtig bei anderem Routertyp). Dann läuft das Heimnetz, als ob nichts verändert wäre.

Gruß Xel66

[steho]

@Xel66

Ich glaube, dass das mit der Zuweisung und fester Vergabe schon richtig verstanden wurde, ich hänge mal einen Screenshot meiner FB mit exemplarischer IP und MAC an. Wie man sehen kann, ist seitens der FB keine Zuordnung vorgesehen.

In der RM, Systemsteuerung, IP ist halt die exemplarische IP eingestellt, also STATISCH, wie es sein sollte, oder?

Wenn jetzt das lustige MAC-Wechseln an den Stellen CC und DD losgeht, "meint" die FB ein neues Gerät erkannt zu haben und listet es mit gleicher IP 192.168.1.100 aber "neuer" MAC unter Netzwerkgeräten auf. Bei mir standen dann z.B. innerhalb kürzester Zeit 20 Einträge mit eben dieser IP aber unterschiedlicher MAC (Block 3 & 4) auf er Liste und nichts ging mehr bei der CCU, diese lief quasi auf "Volllast" und Programme oder Geräte konnten nicht mehr bedient werden, bzw. nur mit erheblicher Verzögerung.

[jp112sdl]

Wenn jetzt das lustige MAC-Wechseln an den Stellen CC und DD losgeht, "meint" die FB ein neues Gerät erkannt zu haben

Ich glaub so langsam verstehe ich... die Fritte scant permanent alles was an MACs im LAN umher fliegt, um "kundenfreundlich" schon mal eine Liste der Geräte anzubieten!?

[cmjay]

Wenn jetzt das lustige MAC-Wechseln an den Stellen CC und DD losgeht, "meint" die FB ein neues Gerät erkannt zu haben und listet es mit gleicher IP 192.168.1.100 aber "neuer" MAC unter Netzwerkgeräten auf.

Liegt das vielleicht daran, dass deine fest vergebene IP 192.168.1.100 im DHCP Bereich der Fritte liegt? Warum sollte sich die Fritte für MAC Adressen von Geräten ausserhalb ihres DHCP Bereiches interessieren und diese regelmässig scannen?
Ich versteh's nicht.

[Sven_A]

Ich glaub so langsam verstehe ich... die Fritte scant permanent alles was an MACs im LAN umher fliegt, um "kundenfreundlich" schon mal eine Liste der Geräte anzubieten!?

Naja... eine Fritte ist der Dreh- und Angelpunkt des Netzes. Die MUSS wissen an welchem Port welche MAC hängt damit das mit dem Layer2 Switching klappt...

[jp112sdl]

Die MUSS wissen an welchem Port welche MAC hängt damit das mit dem Layer2 Switching klappt...

Jup, aber nicht im Hintergrund schon mal eine IP Adresse "vor-reservieren", obwohl auf dem Client kein DHCP Client darum bittet.

[sailor79]

Und nein bei außerhalb .20.-.200 bleiben bei uns nicht genug freie Adressen übrig

Aber du brauchst doch sicherlich keine 181 IP Adressen im DHCP-Bereich... dann verringere die Range und schon hast du mehr Platz für statisches Zeug.
(Mein DHCP Bereich daheim geht von .49 - .100)

Genau so bin ich ja jahrelang mit einem reduziertem DHCP-Beteixh gefahren, und dass wurde von Avm moniert als Abweichung, unter der ein reibungsloser Betrieb nicht mehr gewährleistet werden könne

[steho]

@cmjay

Nein, ich habe das definitiv voneinander getrennt - FB vergibt beispielsweise 1.101 bis 1.199, also der DHCP Bereich ist völlig separat von den fest vergebenen.

Ich meine auch, dass ein anderer User die Komponenten von AVM gegen was anderes ersetzt hat und es auch mit anderem Netzwerkhersteller zu dem Problem kam. Weiß gar nur nicht, ob hier oder bei GitHub und HAP-Homematic.

[cmjay]

Genau so bin ich ja jahrelang mit einem reduziertem DHCP-Beteixh gefahren, und dass wurde von Avm moniert als Abweichung, unter der ein reibungsloser Betrieb nicht mehr gewährleistet werden könne

Also AVM stellt in der Firmware explizit die Möglichkeit bereit, den DHCP Bereich anzupassen und wenn man das dann macht ist die Rückmeldung "du darfst das nicht tun"? Sehr seltsam ...