Da immer mehr Geräte über ihre IP anzusprechen sind (IoT), feste oder reservierte DHCP nicht immer angebracht sind, wäre doch eine Funktion, welche die IP bei bekannter MAC zurückgibt, angebracht.
Jetzt kann man zwar mit ARP, FING o.ä. arbeiten, aber da diese Funktionen OS-abhängig sind, gehören sie meiner Ansicht nach nicht in die Module, sondern sollten ein "Service" der Basis sein.
Natürlich wären sie auch in Fhem selbst noch vom OS abhängig, ich denke aber, es wäre dort leicher zu "verwalten" als in den Modulen selbst.
Zumal die Modulersteller damit auch keine OS-übergreifenden Kentnisse bräuchten.
Zitat von: Per am 22 Januar 2016, 08:26:54
...wäre doch eine Funktion, welche die IP bei bekannter MAC zurückgibt, angebracht...
Genau das kann ein ordentlicher DHCP-Server, wenn er entsprechend konfiguriert ist.
Sowas ist aber IMHO ein "Server-Dienst", von dem massgeblich die Netzwerkfunktion und -stabilität abhängt; das gehört meines Erachtens nicht in ein FHEM-Modul.
Oder ich habe die "Frage" nicht verstanden.
Zitat von: Hollo am 25 Januar 2016, 09:41:30Oder ich habe die "Frage" nicht verstanden.
Vllt. habe ich mich auch nur ungenau ausgedrückt. Ich möcht nicht den DHCP-Server in Fhem nachbilden, sondern nur die vom "normalen" DHCP-Server an eine bekannte MAC (die von meinem Gerät) vergebene IP herausbekommen.
Das kann ich manuell über das Web-Frontend vom DHCP-Server oder vom -Client, automatisiert wird das aber deutlich schwieriger, da jeder Hersteller sein eigenes Konzept und seine eigene Syntax verwendet. Und das auch noch modellabhängig.
Mit "Fing" oder "Arp" bekomme ich Listen von MAC und zugehörigen IP (fest und dynamisch) zurück. Das würde ich aber nicht in jedes Modul einbauen wollen, sondern eine zentrale Instanz (Dienst, Funktion...) dafür vorsehen, da ich dann die OS-Abhängigkeit auch nur einmal berücksichten muss.
Ich hab immer noch nicht kapiert, welche IP Du herausfinden willst. Die von der Kiste, auf der das fhem läuft?
Glaube er hätte gerne dass man per FHEM einen ping sendet? So hab ichs verstanden?!
Á la "ping ABC"
Ping wird ausgeführt für ABC [1.2.3.4] mit 32 Bytes D
aten:
Antwort von 1.2.3.4: Bytes=32 Zeit<1ms TTL=128
Antwort von 1.2.3.4: Bytes=32 Zeit<1ms TTL=128
Antwort von 1.2.3.4: Bytes=32 Zeit<1ms TTL=128
Antwort von 1.2.3.4: Bytes=32 Zeit<1ms TTL=128
Ping-Statistik für 1.2.3.4:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms
Oder hab ich das auch (nicht/falsch) verstanden?
EDIT: ich glaube ich habs auch falsch verstanden - Du willst von der MAC (?) ausgehend die IP haben? Bei Windows wäre das ein arp -a auf cmd-Ebene, bi Linux bin ich nicht soooo fit was die Bash angeht...
Zitat von: Tedious am 25 Januar 2016, 12:05:19EDIT: ich glaube ich habs auch falsch verstanden
Richtig :(
Zitat von: Tedious am 25 Januar 2016, 12:05:19Du willst von der MAC (?) ausgehend die IP haben?
Nochmal richtig! :D
Die MAC ist halt konstant (Definition), die IP kann (DHCP) sich ändern (Internal).
Zitat von: Per am 25 Januar 2016, 12:46:14
...Die MAC ist halt konstant (Definition), die IP kann (DHCP) sich ändern (Internal).
Wie oben schon geschrieben...
wenn Du den DHCP-Server ordentlich konfigurierst, bekommt ein Device mit einer definierten MAC-Adresse bei jeder DHCP-Anfrage dieselbe IP zugewiesen; auch völlig unabhängig vom verwendeten Betriebssystem.
Schließe mich meinem Vorredner an. Zudem... auch ich nutze DHCP, habe aber allen relevanten Geräten in der Infrastruktur auf die ich Zugriffe/Pings/etc. benötige wie Servern, Druckern etc. eine fixe IP ausserhalb der DHCP-Range zugewiesen. Insofern... erschließt sich mir der Sinn nicht so ganz.
Und, wie gesagt - geb an einem Win-Rechner in der CMD mal arp -a ein ;)
Tante EDITH: Google sagt das geht auch bei Linux ;) http://www.oreilly.de/german/freebooks/linag2/netz0510.htm (http://www.oreilly.de/german/freebooks/linag2/netz0510.htm)
Zitat von: Tedious am 25 Januar 2016, 13:36:13habe aber allen relevanten Geräten in der Infrastruktur auf die ich Zugriffe/Pings/etc. benötige wie Servern, Druckern etc. eine fixe IP ausserhalb der DHCP-Range zugewiesen.
Tja, dass das geht, weiss ich alles. Steht ja schon im Eröffnungspost. Auch Arp (und fing) wurde da schon erwähnt.
Mir geht es aber darum, Sachen, die ich manuell machen kann, zu automatisieren.
Oder stellt ihr eure Heizungen noch manuell ein?! ;D
Nein. Aber wir machen es an der Stelle, an der es sinnvoll UND einfach ist und das ist entweder eine feste IP oder die Konfiguration des DHCP Servers.
Warum sollte man viel Aufwand in die Implementierung eines solchen Mechanismus stecken, wenn man in der FritzBox nur einmalig eine Checkbox anklicken muss und auf speichern drückt und das Problem somit dauerhaft gelöst ist?
Alternativ, bau dir eine Perl-Funktion in deiner 99_myUtils.pm, welche eine IP-Adresse zur MAC auflöst.
Gruß
Markus
Zitat von: Per am 25 Januar 2016, 14:03:55
Oder stellt ihr eure Heizungen noch manuell ein?! ;D
Nein, natürlich nicht. Aber es steht Dir ja frei was in Perl zu basteln - auch da kannst Du arp einbetten - wie in dem Post vor mir genannt. Wobei - man möge mir verzeihen - sowas mit Kanonen auf Spatzen schießen ist. Man sollte an der Basis anfangen und seine Netze sauber aufbauen, denn kommt man gar nicht zu der Problematik :o
Mein DHCP Server heißt dnsmasq und die Konfigurationsdateien dazu habe ich selbst erstellt. Also wenn ich irgendwelche Informationen diesbezüglich brauche, dann lese ich einfach die Konfigurationsdateien aus. Aber gebraucht habe ich sowas auch nach 30 Jahren Netzwerktechnik noch nie.
Zitat von: Tedious am 25 Januar 2016, 16:00:40Aber es steht Dir ja frei was in Perl zu basteln
Meinst du nicht, dass ich das dann vllt. unter
Codeschnipsel vorgestellt hätte statt unter
Wunschliste?
Aber wahrscheinlich werde ich das tun müssen, wird dann halt nicht OS-unabhängig und kann "etwas" dauern.
Zitat von: betateilchen am 25 Januar 2016, 19:08:28
Mein DHCP Server heißt dnsmasq...
So isses.
Und der kann DNS, DHCP und auch PXE-Server mit TFTP; mehr braucht man für's Home-Netzwerk eigentlich fast nicht. 8)
Zitat von: Per am 25 Januar 2016, 21:03:44
Meinst du nicht, dass ich das dann vllt. unter Codeschnipsel vorgestellt hätte statt unter Wunschliste?
Aber wahrscheinlich werde ich das tun müssen, wird dann halt nicht OS-unabhängig und kann "etwas" dauern.
Kein Grund pissig zu sein?!? Sehs mal so - Du generierst ein Problem das bei 99% der anderen nicht auftaucht weil sie das Netzwerk sauber konfigurieren. Denn bekommst Du gleich lautende Infos von Menschen die hier den Titel "Developer" tragen... FHEM beschäftigt sich mit Hausautomatisation, nicht mit Netzwerk-Infrastukturen, dieses Layer liegt je nach System 1-3 Ebenen darunter. Warum das Übel nicht bei der Wurzel packen - Du tankst Dein Auto ja auch nicht durch den Motorraum? Wenn Du denn was individuelles brauchst musst Du das halt selbst basteln?!
Zitat von: Tedious am 26 Januar 2016, 09:20:05weil sie das Netzwerk sauber konfigurieren
Ich weiss immer noch nicht, was an DHCP unsauber ist! Und ob ich die Adressen im DHCP-Server reserviere oder im Gerät fest vergebe, beides macht zusätzliche Aufwände, welche eigentlich nur wegen dieser fehlenden Funktion nötig sind. Hat nix mit "sauber" zu tun.
Zitat von: Tedious am 26 Januar 2016, 09:20:05Wenn Du denn was individuelles brauchst musst Du das halt selbst basteln?!
Tja, als individuelle Lösung wäre das auch ok, ich sehe es eher als globale. Aber scheinbar bin ich der einzige, der das so sieht.
Zitat von: Tedious am 26 Januar 2016, 09:20:05Du tankst Dein Auto ja auch nicht durch den Motorraum?
Noch nie nen Trabbi (http://img.webme.com/pic/m/mein-ddrfahrzeug/trabant.82.beige.9.jpg) gefahren?
Zitat von: Per am 26 Januar 2016, 09:48:24
Ich weiss immer noch nicht, was an DHCP unsauber ist! Und ob ich die Adressen im DHCP-Server reserviere oder im Gerät fest vergebe, beides macht zusätzliche Aufwände, welche eigentlich nur wegen dieser fehlenden Funktion nötig sind. Hat nix mit "sauber" zu tun.
Tja, als individuelle Lösung wäre das auch ok, ich sehe es eher als globale. Aber scheinbar bin ich der einzige, der das so sieht.
Noch nie nen Trabbi (http://img.webme.com/pic/m/mein-ddrfahrzeug/trabant.82.beige.9.jpg) gefahren?
Warum DHCP unsauber ist? Weil genau Deine Probleme auftauchen. Weil die Leases ablaufen und neu vergeben werden. Darum. Fixe Geräte, fixe IP. Es ist ein "Aufwand" das Netzwerk sauber zu konfigurieren? Stimmt, für die Programmierer ist es ja kein Aufwand was zu coden. Nochmal: Netzwerk-Layer =/= BS-Layer =/= SW-Layer (Fhem). Und ja, Du bist der einzige der das scheinbar so sieht. Weils wie gesagt nicht die Aufgabe von FHEM ist die Infrastruktur des Netzwerks zu verwalten. Und nein, nen Trabbi bin ich noch nicht gefahren. Bin zum Glück in einer Demokratie groß geworden. So what, ich bin hiermit raus.
Zitat von: Tedious am 26 Januar 2016, 10:07:09Es ist ein "Aufwand" das Netzwerk sauber zu konfigurieren? Stimmt, für die Programmierer ist es ja kein Aufwand was zu coden.
Nun, Fhem hat sich unter anderem auch auf die Fahnen geschrieben, für Nicht-Programmierer interessant zu werden (DOIF; ich weiss, es gibt auch DOIF-freie Zonen), warum darf das nicht auch für Nicht-Netzwerker gelten?
Zitat von: Tedious am 26 Januar 2016, 10:07:09Bin zum Glück in einer Demokratie groß geworden. So what, ich bin hiermit raus.
Zitat von: Tedious am 26 Januar 2016, 09:20:05Kein Grund pissig zu sein?!?
Ähm, wer jetzt?
Nochmal: ich schreibe "jetzt" was selbst und werde es anschließend (wann auch immer das sein wird) bei Code-Schnipseln veröffentlichen.
Es wird wohl nur auf meiner aktuelle Debian-Version laufen, vllt. noch auf Windows. Mehr Möglichkeiten und Kenntnisse habe ich nicht.
Und nein, ich bin nicht "pissig", nur verwundert ob der Argumente.
Ich kann beide Seiten hier verstehen.
Wenn ich es richtig verstehe, möchtest Du "eigentlich" Devices nicht mit Ihrer IP, sondern Ihrer MAC definieren?
Da man FHEM auch in eventuell geroutete Netze (z.B. eigenes Netz für Außensensoren) einsetzen können soll, muß man sowieso IP implementieren, sehe also in der MAC keinen Vorteil, eher Nachteil. Wenn der Sensor getauscht wird ...
Kurzfassung:
Stehe eher auch auf dem Standpunk: Ein netz sauber definieren und die Probleme sind gelöst
(Habe übrigens auch dhcp und DNS-Server am laufen ... und nicht die Fritzbox)
Zitat von: Per am 26 Januar 2016, 10:36:50
Nun, Fhem hat sich unter anderem auch auf die Fahnen geschrieben, für Nicht-Programmierer interessant zu werden (DOIF; ich weiss, es gibt auch DOIF-freie Zonen), warum darf das nicht auch für Nicht-Netzwerker gelten?
Weil das verschiedene Ebenen sind. Daher ja auch das abstrahierte Beispiel mit dem Auto. Schau mal hier rein (Layer 3 --> 7): https://de.wikipedia.org/wiki/OSI-Modell (https://de.wikipedia.org/wiki/OSI-Modell)
DOIF ist hier für ein schlechter Vergleich. DOIF ist eine Hilfe, auch nicht Perl-Kennern einen leichten Zugang zu komplexen Automatisierungen zu geben. Das was du möchtest, ist eine Krücke, die Unzulänglichkeiten einer anderen Ebene ausgleichen soll. Es gibt also keinerlei Gemeinsamkeiten zwischen DOIF und deinem "MAC -> IP".
Ehrlich gesagt verstehe ich, auch aus Anwender Sicht, dein Problem nicht. Es könnte eventuell für Leute interessant sein, die ihr Problem im Netzwerk nicht kennen (bspw. unzulänglich konfigurierter DHCP Server) aber da du dein Problem kennst, kannst du es an der richtigen Stelle lösen.
Zitat von: Per am 26 Januar 2016, 10:36:50
Nun, Fhem hat sich unter anderem auch auf die Fahnen geschrieben, für Nicht-Programmierer interessant zu werden (DOIF; ich weiss, es gibt auch DOIF-freie Zonen), warum darf das nicht auch für Nicht-Netzwerker gelten?
Vorsicht mit dieser Aussage. FHEM ist generell von Technik-Bastlern für Technik-Bastler gedacht. Es war (und ist) nicht für den einfachen Endnutzer gedacht der einmal klickt und alles läuft. Diese Aussage hat Rudi bereits mehrfach im Forum gegeben. Es gibt durchaus den ein oder anderen Entwickler, der das versuchen möchte zu vereinfachen (ich nehm mich da nicht aus), aber es gab nirgendswo die Aussage von Rudi (der ja der Projekt-Eigentümer ist) FHEM jetzt für Nicht-Bastler interessant zu machen.
Generell kann ich dir da das Interview auf meintechblog.de empfehlen um zu verstehen wieso er so denkt: http://www.meintechblog.de/2015/07/rudolf-koenig-im-interview-der-erfinder-von-fhem-zum-thema-smart-home/
Gruß
Markus
mal am Rande:
die MAC zu einer IP befindet sich im ARP-Cache. Und in diesem auch nur, wenn sie noch nicht durch einen Timeout aus diesem wieder geloescht wurde. Weiterhin nur dann, wenn sie sich innerhalb des gleichen Netzwerksegments (Subnet) befindet...
Von daher glaube ich, dass eine solche Abfrage in einigen Faellen, sollte nicht ein Ping vor einer Arp-Cache Abfage gemacht werden, einfach nicht zum gewuenschten Resultat, sprich der IP fuehrt...
Gruß
Markus
Hi,
dafür gibts das Tool arping.
ARPING 192.168.6.1
60 bytes from 00:0d:b9:xx:xx:xx (192.168.6.1): index=0 time=1.206 msec
60 bytes from 00:0d:b9:xx:xx:xx (192.168.6.1): index=1 time=10.390 msec
60 bytes from 00:0d:b9:xx:xx:xx (192.168.6.1): index=2 time=9.957 msec
lG
Wolfgang
jaaa ... aber das verwendet auch die IP und eben NICHT die MAC!
Ein "MAC"_ping existiert so nicht ....
nmap (https://de.wikipedia.org/wiki/Nmap) würde auch (Linux + Windows) gehen, müsste aber installiert werden.
Nutzt doch einfach den DNS-Namen, wenn ihr mit der IP ein Problem habt. Der wird dann entsprechend in die aktuelle IP-Adresse aufgelöst. Steht in einer FritzBox und jedem anderen Router im Konfigurationsmenü.
Gruß
Markus
Speziell bei FritzBox-DNS und DNS-Namen soll man vorsichtig sein.
Wenn ein Gerät selber nicht sendet, also Netzwerktechnisch nur "hört", wird es aus dem FritzBox-DNS geschmissen.
Eventuell über einen eigenen DNS7DHCP-Server nachgedacht?
Zitat von: Wernieman am 30 Januar 2016, 18:41:23
...Eventuell über einen eigenen DNS7DHCP-Server nachgedacht?
Das will er ja nicht. ;)
Meines Erachtens bleibt die Idee "sinnlos", weil das bei korrekter Netzwerkinfrastruktur/-konfiguration nicht erforderlich ist.
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.
Zitat von: Per am 31 Januar 2016, 19:26:46
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.
Zitat von: Per am 31 Januar 2016, 19:26:46
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.
Zitat von: Per am 31 Januar 2016, 19:26:46
...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.
Zitat von: Hollo am 01 Februar 2016, 00:25:12Die 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.
Zitat von: Per am 01 Februar 2016, 09:48:04
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
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.
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..?!
Zitat von: Tedious am 01 Februar 2016, 11:53:44warum 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.
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
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 ....
ZitatWeil 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.
ZitatWie 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.