MAC -> IP

[Per]

Ich weiss ja nicht, welchen Beissreflex ich ausgelöst habe, aber der eine oder andere scheint nach "seinem" Buzzword nicht weitergelesen zu haben. Anders kann ich mir viele Antworten nicht erklären.
ICH kenne alle meine IPs, meine dynamischen IP sind quasistatisch.
Aber wenn ich ein Modul schreibe, warum dann nicht wie bei der "originalen" App auch auf die MAC referenzieren?

Im Übrigen: ich schrieb bereits, dass ich versuchen werde, eine portable (!) Funktion zu schreiben. Wann die fertig wird, weiss ich nicht. Durch weitere Gegenargumente geht es aber auch nicht schneller.

[Markus Bloch]

Aber wenn ich ein Modul schreibe, warum dann nicht wie bei der "originalen" App auch auf die MAC referenzieren?

Weils absolut niemand brauch (bis auf Dich offenbar). Layer 2 Adressen sind nur noch für Netzwerke relevant wo alle Rechner an einem einzigen Switch/Router hängen. Ein Übergang von LAN auf WLAN ist in vielen Routern bereits jeweils als eine einzelne Broadcast-Domäne implementiert, womit man also MAC Adressen von WLAN Geräten nicht direkt über LAN Abfragen kann (man wird an die MAC Adresse vom Router/Switch verwiesen). Somit hast du nur einen sehr kleinen Kreis an Netzwerkgeräten die man wirklich damit abfragen kann.

Im Übrigen: ich schrieb bereits, dass ich versuchen werde, eine portable (!) Funktion zu schreiben. Wann die fertig wird, weiss ich nicht. Durch weitere Gegenargumente geht es aber auch nicht schneller.

Schreib ruhig, wenn du sowas umbedingt brauchst, stells ins Wiki von mir aus, aber einchecken würde ich an meiner Stelle sowas nicht.

[Hollo]

...Im Übrigen: ich schrieb bereits, dass ich versuchen werde, eine portable (!) Funktion zu schreiben. Wann die fertig wird, weiss ich nicht. Durch weitere Gegenargumente geht es aber auch nicht schneller.

Die Kommentare waren ja alle auch nicht böse gemeint.
Vielleicht erschließt sich uns ja der Sinn, wenn Du das Modul  bzw. die Funktion geschrieben hast.
Oftmals hat man ja einen konkreten Anwendungsfall im Hinterkopf, wodurch es Außenstehenden auf den ersten Blick nicht ersichtlich ist.

[Per]

Die Kommentare waren ja alle auch nicht böse gemeint.

Für alle würde ich das nicht unterschreiben!

Hintergrund ist recht einfach, in vielen (Android-)Apps (SOP112 von ELV, MILIGHT) wird nicht mehr nach IP, sondern nach MAC unterschieden. Warum sollen wir das anders machen? Wie die Apps mit einem Sub-Netz klarkommen, weiss ich nicht, um das zu Testen müsste ich erstmal damit klarkommen. Nicht jeder Programmierer ist auch Netzwerker.

Das es keine ausschließliche Festlegung auf MAC sein kann, verstehe ich ja, bei "meinem" SOP112-Modul kann (z.Zt: muss) die IP auch manuell (attr) angegeben werden. Diese Option würde ich nicht nur wegen der Abwärtskompatibilität später nicht streichen.

[Markus Bloch]

Hintergrund ist recht einfach, in vielen (Android-)Apps (SOP112 von ELV, MILIGHT) wird nicht mehr nach IP, sondern nach MAC unterschieden. Warum sollen wir das anders machen? Wie die Apps mit einem Sub-Netz klarkommen, weiss ich nicht, um das zu Testen müsste ich erstmal damit klarkommen. Nicht jeder Programmierer ist auch Netzwerker.

Das ist richtig, hat allerdings andere Gründe. Hier adressiert man nach MAC, weil hier alles recht hardware-nah implementiert ist um Platz zu sparen. Und Platz in einer E27 Fassung ist wahrlich nicht viel, wenn man davon ausgeht, was da noch alles rein muss (12V Spannungsregler, PWM-Dimmer, WLAN-Funk, ...). Allein die WLAN-Protokolle inkl. Verschlüsselung ist ja schon durchaus aufwändig. Da der Anwendungsfall primär darum geht die Birnen innerhalb des lokalen WLAN's zu steuern hat man sich auf Layer 2 beschränkt. Solche Birnen haben also keinen IP-Stack. Es ist die einfachste und günstigste Methode die Birnen im WLAN zu steuern. Solche Birnen kann man aber nicht steuern, wenn man hinter einem Switch, VPN usw. steht, da dort ein MAC Broadcast nie bis zu den Birnen kommt. Und nur dadurch werden die Birnen erkannt.

Gruß
Markus

[Per]

Beide von mir genannten Systeme bekommen über DHCP eine IP und haben sogar ein Web-Interface, die MiLight sogar einen abschaltbaren WLAN-AP.
Inwieweit die Apps mit MAC Broadcast zum Finden der Systeme arbeiten, weiss ich aber nicht.

[Tedious]

Aber um noch mal auf den Ursprung zurückzukommen, das erschließt sich mir wirklich nicht - warum weist Du keine fixen IPs zu und die Sache ist gegessen? Sorry, das verstehe ich nicht - ist in wenigen Minuten konfiguriert und das Problem ist gelöst. Oder andersrum - warum sollte die fixe IP-Vergabe das Problem nicht lösen? Glaube das ist das Fragezeichen das hier viele über dem Kopf haben..?!

[Per]

warum weist Du keine fixen IPs zu und die Sache ist gegessen?

Weil ich als Anwendungsentwickler nicht für mich, sondern für den Anwender entwickle.
Außerdem mag ich es persönlich nicht, Konfigurationen an verschiedenen Stellen zu pflegen. Deshalb habe ich ja auch ein Modul für die SOP112 entwickelt, mit Dummies, Ats, Notifies und ein paar Funktionen in 99_myutils wäre es ja auch getan. Aber das trifft bestimmt auf 90% aller Module zu.

[Darkman]

Ahoi,

vermutlich ist die Loesung am Ende ganz einfach:
es soll funktionieren "wie in der original App" (warum wird erstmal nicht geklaert, und genau das ist das Problem).

Warum eine App das ueber die MAC macht? Vermutlich aus folgendem Grund: Die MAC ist der "statische" Part der Hardware die der Kunde in die Hand bekommt. Die IP nicht. Denn die IP kann sonst was sein. Wenn ich jetzt 10 Birnen in meinem Haus verbaue, dann habe ich vorher i.d.R. KEINE Option diese zu Konfigurieren. Ist ja kein RJ45 an der Birne. Also gibts diese ganzen Fallbacks ueber selbst gespannte APs usw. die mir es ermoeglichen die Birne zu konfigurieren. Jetzt hab ich am Ende aber 10 verbaut. Welche ist welche? Kein Plan. Aber da die MAC auf der Kiste stand oder an der Birne, weiss ich zumindest die MAC. Die App kann jetzt in den SSIDs oder so danach "suchen" und entsprechend die Birne konfigurieren damit sie anschliesstend im WLAN von mir zu finden ist, inkl. vermutlich per DHCP (oder wegen mit auch statisch) vergebener IP.

Technisch ist ein "mapping" von MAC zu IP in dem Fall wenig sinnvoll, denn wann braucht man das? Bei der Konfig (i.d.R. der Ersten) der Birne. Je nach dem wie das Produkt sein "finde mich/konfigurier mich" aufgebaut hat, ist die MAC ein "identifier" oder teilweise sogar dazu da um mit sehr grundlegenden Befehlen eine kleine Basis Konfiguration (zb. das setzen einer lokalen IP) zu ermoeglichen. Wenn man das jetzt in FHEM abbilden moechte, muesste man die jeweiligen "initialen Konfigurationsschritte" entsprechend Implementieren. Kann man machen - aber, so als Netzwerker: wenn Netz sauber konfiguriert ist, ist alles besser. Und die Hersteller verwenden teilweise echten scheiss um diese initiale Konfiguration hinzubekommen. Also ueberlassen wir denen ihren Mist und verwenden das Produkt wenns sauber Konfiguriert ist. Die Methode des "WLAN AP-wenn-keine-Konfiguration-vorhanden-ist" kann man mit FHEM ja auch nicht ohne weiteres "nachbauen" und geht in meinen Augen auch weit ueber das Ziel von FHEM hinaus. Vorallem weil man sich innerhalb von FHEM schon genug um die ganzen "tollen" Eigenarten der verschiedenen Hersteller in den Protokollen rumschlagen darf.

Von daher: einfach mal drueber nachdenken was eigentlich Sinn und Zweck ist und ggfs. auf dieser Basis nochmal drueber reden. In den meisten Faellen fehlen naemlich einfach nur ganz kleine Details um das aufzuloesen - ohne das man sich missverstanden fuehlen muss.

Gruesse,
Sven

[Wernieman]

Der Nachteil von MAC-Adresen in unserem Falle ist nur die Implementierung in FHEM. Du müstest doch tief in den Netzwerkstack einsteigen, um dieses Aufzulösen.

Denn es bringt Dir nicht, dem User die MAC zu zeigen, aber mit tcpip zu reden. Wenn, dann solltest Du auch komplett auf einer Schiene bleiben.

Viel Spaß beim Implementieren ....

[rumors]

Weil ich als Anwendungsentwickler nicht für mich, sondern für den Anwender entwickle.
Außerdem mag ich es persönlich nicht, Konfigurationen an verschiedenen Stellen zu pflegen.

Theoretisch ein löblicher Ansatz, viele Anwender wiederum wollen dann aber wieder Ihre Konfiguration splitten um es überschaubar zu halten. Sprich jeder hat seine eigene Arbeitsweise, mit welcher er eben am besten klarkommt.
Letztendlich sollte man sich bei allem aber an die quasi defacto Standards halten um im Troubleshhoting auch Feedback zu bekommen was schwer ist wenn keiner den Ansatz versteht.

Der Ansatz direkt mit MacAdressen zu arbeiten wird sicherlich in einer kleinen Umgebung funktionieren. Sobald aber Routings ins Spiel kommt ist es bereits wieder vorbei. ACLs werden normalerweise auf IP Ebene gepflegt, sprich auch wenn etwas mehr Komponenten beteiligt sind wird das debugging nahezu unmöglich.

Wie die Apps mit einem Sub-Netz klarkommen, weiss ich nicht, um das zu Testen müsste ich erstmal damit klarkommen. Nicht jeder Programmierer ist auch Netzwerker.

Das musst auch kein Netzwerker sein. Allerdings solltest du dann nicht neu erfinden wollen wie ein Netz funktionieren soll.
Ich bin bisher eher nicht der Coder deshalb höre ich wenn ich dann was machen will auf die best-practice der Coder. Umgekehrt wäre es hilfreich auf die Netzwerker zu hören anstatt hier Experimente zu machen.
Wir müssten auch schon Entwicklungsabteilungen vom Netz nehmen da Sie den Betrieb gestört haben. Hätten Sie mal vorher mit der IT gesprochen wären einige Wochen Entwicklung nicht für die Tonne gewesen.
Dabei geht es auch nicht um Grabenkämpfe sondern die Anwendung muss für die Anwender letztendlich auf der Infrastruktur störungsfei läuffähig sein.