[Gelöst] Hostname im AVM-WebIF durch DNSMASq auflösen/anzeigen

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
395
Punkte für Reaktionen
13
Punkte
18
Hallo liebes Forum,

ich habe schon einige Threads diesbezüglich gelesen, die sind aber alle schon älter und haben bislang keine abschließende Lösung. Derzeit nutze ich auf einer 3490 die aktuelle Firmware 7.12 und den aktuellen Freetz-Master.

Ich möchte nun, dass im AVM-WebIF unter Netzwerk, die bekannten Netzwerkgeräte nicht mit "PC-192-168-1-150" angezeigt werden, sondern mit ihrem Hostnamen. Klar, man kann das manuell ändern, doch es sollte doch auch irgendwie automatisch gehen.

Schaltet man den DNSMASq ab und lässt den DHCP der Box laufen, so klappt das auch. Sobald der DHCP/DNS vom DNSMasq läuft, werden die Hosts eben mit obigen Schema in die Netzwerkliste eingetragen. Ich habe mich auch schon ein wenig mit dem ctlmgr_ctl gespielt, doch bin ich bislang noch nicht auf einen grünen Zweig gekommen...

Vielleicht haben ja unsere Experten hier einen Tipp oder einen Lösungsansatz.

LG
WileC

-- Zusammenführung Doppelpost by stoney

Vielleicht könnte man ja das selbe Lease-File benutzen? also, statt der dnsmasq.leases, die multid.leases? Oder eine Aktion mittels --dhcp-script=<path> triggern??
 
Zuletzt bearbeitet von einem Moderator:
Ich hatte mich mal vor ein Paar Jährchen mit dem Thema beschäftigt. Bestimmt hast du auch mein Thread dazu irgendwo gesehen. Wenn ich mich richtig besinne, hatte ich es damals so weit geschafft, ein Skript zu schreiben, um es in eine und später in die andere Richtung zu synchronisieren. Damals kannte man sich (oder besser gesagt ich mich) nicht so richtig mit der Syntax der ctlmgt_ctl-Sprache, sodass ich irgendwann mal in einer Sackgasse gelandet bin. Heutzutage sind die Erkenntnisse darüber, wo die leases liegen und im welchen Format deutlich weiter fortgeschritten, sodass es wahrscheinlich viel leichter und schneller zu realisieren wäre. Ich persönlich habe momentan leider kaum Zeit dazu, es richtig "durchzuziehen", vor allem, weil es heutzutage vermutlich gleich IPV4- und IPV6-lauffähig sein sollte. Alleine das rumspielen damit, bis man die richtige Lösung findet, wird bei mir 2-3 Abende klauen, die ich momentan nicht habe. Danach könnte man es versuchen zu implementieren. Ideal wäre es, die Stelle in dnsmasq abzufangen, wo das lease "verliehen" wird und sich dann mit dem eigenen Skript "dadran zu hängen" und den entsprechenden Namen in die AVM-Datenbank zu schreiben, wenn es sich z.B. geändert hat.
Mein alter Ansatz war aber etwas anders. Dort ging es damals um eine Synchronisation der beiden Listen, nicht um eine "live"-Eintragung in die AVM-Datenbank.
Und ohne AVM-Datenbank kommst du nicht rumherum. Mit irgendeiner Datei kannst du es vergessen. Es gab da früher zwar irgendeine Datei, die AVM vielleicht mal für irgendwas benutzt hat, sie ist aber anders gestaltet, als die von dnsmasq und wird meinen damaligen Erkenntnissen nach eigentlich nicht so "bedient", wie man es will. Damit du es im WebIF siehst, musst du an die AVM-Datenbank ran.
 
Also, eine Datenbank läuft da ja nicht im Hintergrund, das kommt alles über den CTLMGR_CTL und letztendlich aus der AR7.CFG....

Vielleicht könnte mir jemand mal eine originale /var/tmp/multid.leases hier posten, um mal das Dateiformat zu sehen und mit dem des dnsmasq.leases zu vergleichen.

Ich würde mir auch gerne mal ansehen, was genau passiert, wenn sich ein Client an der FritzBox anmeldet, also seine IP bezieht...

Wann genau wird der Datensatz unter landevices settings/landevice[x]/name angelegt? Beim aufruf des WebIF wird ein durchlauf gemacht? oder wird er eintrag durch den CTLMGR_CTL bei Vergabe der IP angelegt?

Irgendwann wird ja der Eintrag angelegt... aber wann und genau durch wen, müsste ich noch recherchieren...

Edit:
Vielleicht könnte man auch über den dnsmasq mittels "dhcp-luascript=" die /var/html/net/edit_device.lua" mit Übergabe der Variablen IP und Name (die wichtigen) irgendwie triggern?!
 
Zuletzt bearbeitet von einem Moderator:
Ich habe mich absichtlich bisher zurückgehalten ... das Thema ist nämlich alles andere als einfach, weil AVM viele verschiedene Quellen benutzt, um einen solchen "Hostnamen" zu bilden.

Stünde ich vor dem Problem (das man ja auch nur dann hat, wenn man die beiden Aufgaben (DHCP-Server und Anzeige der Netzwerk-Teilnehmer) unbedingt getrennt halten will - warum man dann auf einer "korrekten Anzeige" bestehen wollte, erschließt sich mir ohnehin nicht wirklich), würde ich zunächst mal überprüfen, wie sicher die neue mDNS-Implementierung von AVM ist und ob die FRITZ!Box tatsächlich nur dann eine solche (lokale) Namensansage akzeptiert/verarbeitet, wenn sie auch von dem Client kommt, der da seinen Namen bekanntmachen will.

Ist das der Box am Ende egal und sie akzeptiert solche Ansagen auch von anderen Clients, würde ich im nächsten Schritt auf einem anderen Linux-Host mal probieren, ob die Anzeige in der Box dann stimmt, wenn man solche Zuordnungen über einen "avahi-daemon" mit passender "avahi.hosts"-Datei per mDNS verteilen läßt (https://linux.die.net/man/5/avahi.hosts).

Klappt auch das noch, kann man sich Gedanken machen, wie man bei einer neu vergebenen Lease durch den "dnsmasq" die passenden mDNS-Pakete generiert ... das "avahi"-Paket gibt es ja auch für Freetz und am Ende müßte man eigentlich nur aus den "dnsmasq"-Leases die passende "avahi.hosts" generieren und den "avahi-daemon" neu starten lassen, damit nicht nur die anderen AVM-Daemons, sondern eigentlich alle Clients im lokalen Netz, über die vorhandenen Namen informiert werden.

Ich würde jedenfalls versuchen, das über "das Netzwerk" zu lösen und die AVM-Services auf diesem Weg mit den Infos zu versorgen ... das eigenständige Herumändern in AVM-Dateien kann schon morgen (also bei der nächsten Version) wieder nicht mehr funktionieren.

Notfalls gäbe es sogar noch die Möglichkeit, im FRITZ!OS-DNS-Server statische Namen zu hinterlegen ... ich weiß nur nicht, ob die dann auch die Anzeige im GUI "überstimmen", denn der Name dort wird eben nicht nur aus den Angaben im DNS- oder DHCP-Server generiert, sondern es gibt noch weitere Wege (u.a. eben auch das "mDNS", wie man sich in den Support-Daten bei den DNS-Zonen problemlos überzeugen kann).

Geht es am Ende tatsächlich ausschließlich um die Anzeige der Netzwerkgeräte im AVM-GUI, kann man natürlich auch dieses so anpassen, daß anstelle des von der Box verwendeten Namens ein anderer genutzt wird (bei der Anzeige oder schon beim Generieren der JSON-Struktur, die da höchstwahrscheinlich dahinter steckt), den man zuvor per Abfrage ermittelt oder sogar ganz stupide aus einer Text-Datei mit statischen Zuordnungen (z.B. anhand der MAC-Adresse) ausliest.

Welchen Weg man jetzt nimmt, hängt eben auch davon ab, wofür man diese Namen am Ende braucht ... "korrigiert" man nur die Anzeige mit einer statischen Zuordnung, wird natürlich eine DNS-Abfrage nach einem solchen Namen nicht funktionieren. Das sollte allerdings beim o.a. Weg über mDNS-Announcements auch wieder automatisch eingeschlossen sein ... nur die Frage, ob das AVM-GUI sich davon überzeugen/überreden läßt, kann ich aus dem Stand gerade auch nicht beantworten und ohne die passende Umgebung (in der das beschriebene Phänomen überhaupt auftaucht, daß die Box anstelle anderer Namen auf das "PC-irgendwas"-Schema zurückfällt) kann man da auch nichts "fremdtesten".
 
@WileC Mit "Datenbank" meinte ich die von dir angesprochene "landevices settings..." im "Inneren" des ctlmgr-Daemons. Die entsprechenden ar7.cfg-Einträge sollte man nicht direkt bearbeiten, sodern über diese "settings". Ob man es mit einem lua-Skript schafft? Kann sein... Da ich mich mit lua nicht auskenne, würde ich es eher über shell-script und sed angehen. Vor allem, weil die landevices zunächst durchnummeriert sind. Um ein passendes zu finden, musst du am besten alle nach MAC-Adresse durchsuchen. Also, ohne Schleife wird es vermutlich nicht gelingen.

@PeterPawn Wenn ich es richtig verstehe, ging es tatsächlich nur um die Anzeige im WebIF. Dem Rest von deinem Exkurs in die DNS-Grundlagen werden hier vermutlich leider 98% der Leser (mich eingeschlossen) nicht folgen können. Ist diesmal wirklich ziemlch kompliziert erklärt, nimm es bitte nicht persönlich.
 
So, ich habe mal ein Skript geschrieben und auf meiner Testbox funktioniert das ganze soweit, dass wenn die Option "dhcp-script=/verzeichniszurdatei/dhcp_publish_name.sh" gegeben ist, wird der Name des Geräts im AVM-WebIF geändert.

Code:
#!/bin/sh
#
# Skript für DNSMasq, wenn dieser eine IP
# zugeteilt hat, damit im AVM-WebIF der richtige
# HOSTNAME angezeigt wird.

ACTION=$1
MAC=$(echo $2 | tr [a-z] [A-Z])
IP=$3
HOSTNAME=${4:=UNKOWNHOST}

echo "Parameterübergabe von DNSMasq: $@"

if [ -z $ACTION ] || [ -z $MAC ] || [ -z $IP ] || [ -z $HOSTNAME ]; then
        echo "Mindestens eine Variable wurde von DNSMasq nicht richtig übergeben"| logger
        exit 1
fi

# entsprechendes LANDEVICE aus dem CTLMGR auslesen und anhand der MAC nach den Datenfeldern LANDEVICE und NAME aufsplitten
LANDEVICE_STRING=$(ctlmgr_ctl l landevice "settings/landevice/list(mac,name)" | grep $MAC)
LANDEVICE_TO_CHANGE=$(echo "$LANDEVICE_STRING" | cut -f 2)
LANDEVICE_OLD_NAME=$(echo "$LANDEVICE_STRING" | cut -f 4)

if [ -z $LANDEVICE_TO_CHANGE ]; then
        echo "Keinen passenden Eintrag im CTLMGR_CTL gefunden!"
        exit 1
fi

if [ "$LANDEVICE_OLD_NAME" != "$HOSTNAME" ]; then
                echo $(ctlmgr_ctl w landevice "settings/$LANDEVICE_TO_CHANGE/name" $HOSTNAME)
                echo "Der Hostname des $LANDEVICE_TO_CHANGE wurde in $HOSTNAME geändert."
    else
        echo "Es wurden keine Änderungen am $LANDEVICE_TO_CHANGE durchgeführt."
fi

exit 0

Vielleicht hat noch jemand eine Idee, wie ich den Hostnamen auf ungültige Zeichen überprüfen und ggf. ersetzen kann. "SED" müsste da eigentlich das erste Mittel sein? Für Verbesserungsvorschläge bin ich natürlich offen ;)
 
Vielleicht hat noch jemand eine Idee, wie ich den Hostnamen auf ungültige Zeichen überprüfen und ggf. ersetzen kann. "SED" müsste da eigentlich das erste Mittel sein? Für Verbesserungsvorschläge bin ich natürlich offen ;)

tr wäre ein Versuch wert.
 
tr wäre ein Versuch wert.

Wie meinst du genau ??!

Mir ist grad aufgefallen, dass $HOSTNAME ja nie leer ist, entweder hat die Variable nen Wert vom DNSMasq über die Kommandozeile, oder eben "UNKOWNHOST"
 
Mit tr kann man recht einfach ungültige Zeichen aus einer Zeichenkette löschen:

Code:
echo  'host.xyz$%=-bcn' | tr -c -d '[:alpha:]-.'
host.xyz-bcn
 
So, hier mal das aktualisierte Skript:

Code:
#!/bin/sh
#
# Skript für DNSMasq, wenn dieser eine IP
# zugeteilt hat, damit im AVM-WebIF der richtige
# HOSTNAME angezeigt wird.

ACTION=$1
MAC=$(echo $2 | tr [a-z] [A-Z])
IP=$3
HOSTNAME=${4:=UNKOWNHOST}

echo "Parameterübergabe von DNSMasq: $@"

if [ -z $ACTION ] || [ -z $MAC ] || [ -z $IP ] || [ -z $HOSTNAME ]; then
        echo "Mindestens eine Variable wurde von DNSMasq nicht richtig übergeben"| logger
        exit 1
fi

# entsprechendes LANDEVICE aus dem CTLMGR auslesen und anhand der MAC nach den Datenfeldern LANDEVICE und NAME aufsplitten
LANDEVICE_STRING=$(ctlmgr_ctl l landevice "settings/landevice/list(mac,name)" | grep $MAC)
LANDEVICE_TO_CHANGE=$(echo "$LANDEVICE_STRING" | cut -f 2)
LANDEVICE_OLD_NAME=$(echo "$LANDEVICE_STRING" | cut -f 4)

# HOSTNAME auf AVM-gültige Zeichen formatieren
$HOSTNAME=$(echo $HOSTNAME | tr "_" "-" | tr -cd "[:alpha:]-")

if [ -z $LANDEVICE_TO_CHANGE ]; then
        echo "Keinen passenden Eintrag im CTLMGR_CTL gefunden!"
        exit 1
fi

if [ "$LANDEVICE_OLD_NAME" != "$HOSTNAME" ]; then
                echo $(ctlmgr_ctl w landevice "settings/$LANDEVICE_TO_CHANGE/name" $HOSTNAME)
                echo "Der Hostname des $LANDEVICE_TO_CHANGE wurde in $HOSTNAME geändert."
    else
        echo "Es wurden keine Änderungen am $LANDEVICE_TO_CHANGE durchgeführt."
fi

exit 0

Übrigens: ein Underscore "_" ist im Hostnamen im AVM-Interface nicht erlaubt.. wird auch vom ctlmgr_ctl abgelehnt.
 
Für den Anfang nicht schlecht, aber die Zeile 25 im aktualisierten Skript ist falsch. Logmeldung:
Code:
dhcp_publish_name.sh: line 25: raspbx=raspbx: not found
Offensichtlich ist $ vor der Variable HOSTNAME zu viel.
Nach der Korrektur läuft es besser, aber nun kommen merkwürdige Nebeneffekte:
Die Namen werden falsch zugewiesen, doppelte Namen, Abschneiden einer Ziffer am Ende des Namens (z.B. aus webcam2 wird am Ende nur webcam und so heißt auch die nächste IP aus der hosts-Liste, obwohl es eigentlich dort einen anderen Namen hat). Ich versuche selbst zu debuggen und melde mich dann wieder, wenn ich was dazu herausfinde, woran es liegen könnte.

Konstruktive Vorschläge:
a) Bitte poste nur eine Version von deinem Skript, von mir aus auch als txt-Anhang, aber nicht alle Versionen als CODE. Sonst kommt man am Ende durcheinander. Die Posts kann man ja korrigieren.
b) Logging ist für DEBUG-Zwecke jetzt noch ok, langfristig sollte man es aber abschaltbar machen
c) Die Datei sollte in ASCII abgespeichert werden. Meine Default-Einstellung von Notepad++ ist schon lange UTF8. Da die Box aber immer noch nur ASCII spricht, kriegt man entsprechend im Syslog unlesbare Umlaute, wenn die Datei in UTF8 abgespeichert ist. Vielleicht sollte man die Meldungen dann gleich in Englisch ausgeben. Somit würde man das Problem auf eine andere Art und Weise umgehen.
d) Langfristig könnte man anstatt echo dann gleich logger mit entsprechenden Parametern nehmen. Obwohl echo in dem Falle auch geht, weil dhcp_publish_name.sh ein Teil von dnsmasq ist. Somit kriegt man dann im Syslog gleich eine passende Zuordnung.

Edit1: HOSTNAME als lokale Variable im Skript ist sehr unglücklich. Ich glaube, das ist eine Systemvariable. Ich habe es bei mir in MYHOST umgeändert, weil bei mir tatsächlich im Log dann der Name der FritzBox auftauchte, was ja nicht sein kann. Jetzt ist es mit dem durcheinander unter den Namen zumindest gefühlt nicht mehr so, wie es ursprünglich nach dem Wegnehmen von $ war. Das Abschneiden der Zahlen ist aber noch da. Ich analysiere es weiter.
Edit2: Anstelle [:alpha:] sollte man [:alnum:] nehmen, dann klappt es auch mit den Zahlen in den Namen.
Edit3: In der Zeile
Code:
echo $(ctlmgr_ctl w landevice "settings/$LANDEVICE_TO_CHANGE/name" $HOSTNAME)
Ist echo überflüssig. Selbst wenn man echo weg lässt, kommt hier eine Rückmeldung mit dem Namen. Von daher wäre hier besser
Code:
CTLMGR_REQUEST=$(ctlmgr_ctl w landevice "settings/$LANDEVICE_TO_CHANGE/name" $MYHOST)
echo "Der Hostname des $LANDEVICE_TO_CHANGE wurde in $CTLMGR_REQUEST geändert."
Wobei streng genommen sollte man prüfen, was ctlmgr_ctl da zurück gibt und wenn nicht gleich $MYHOST, dann Fehler ausgeben.

In UNKNOWNHOST fehlt ein N
 
Zuletzt bearbeitet:
Habe nun das meiste wie von @hermann72pb gefunden, ausgebessert.. Die "Echo"s kann ja jeder selbst entfernen, wenn sie ihn stören.

Das Skript habe ich in erster Linie für mich geschrieben und wollte es der Allgemeinheit teilen, die ich die die Problemlösung angegangen bin.

Das Skript darf natürlich durch jeden, so wie es benötigt wird, abgeändert werden ;)

Übrigens: IPv6 nutze ich nicht mit DNSMasq, daher kann ich das Verhalten des Skriptes nicht wirklich mit IPv6 sagen...
 

Anhänge

  • dhcp_publish_name.sh.txt
    1.4 KB · Aufrufe: 15
Zuletzt bearbeitet:
Jetzt müsste man nur noch wissen, wie man den ctlmgr_ctl extern anstößt, wenn also der DNSMasq nicht auf der FritzBox läuft, sondern extern auf eine Raspberry PI zum Beispiel...
 
Es gibt mehrere Möglichkeiten dies zu tun:
1. SSH-Tunnel (idealerweise Anmeldung mit Zertifikaten)
Dann muss dein Skript etwas aufgesplittet werden. In dem Teil auf dem Raspberry baust du die SSH-Verbindung zur FritzBox auf und lässt dort ein Skript aufrufen, wo die Box-spezifischen Befehle (ctlmgr_ctl und Co.) liegen. Wie man da die Parameter übergibt, muss man noch überlegen, sollte aber grundsätzlich gehen.
2. Meiner Meinung nach etwas elegantere Lösung. Du nutzt auf der FritzBox inetd und ordnest deinem Skript irgendein Port zu. Raspberry baut Verbindung zu diesem Port auf und sendet dorthin seine Parameter. Inetd "triggert" dann dein Skript. Inetd ist für solche Zwecke bestens geeignet, weil du keine Anwendung dauerhaft wartend auf dem Port laufen lassen musst. Sowas nutze ich öfters, auch bei meinen vielen Raspberry-s.

Beispiel sis-pm-Steckdose per Netzwerk remote ansteuern.
FritzBox-seitig /var/media/ftp/SYSTEM/sisgateway.sh:
Code:
#!/bin/sh

SCRIPT_NAME="SIS-PM-gateway"
DAEMON=sispmctl
DAEMON_LONG_NAME="SIS-PM"
ETC_INIT_DIR="/etc/init.d"
RC_SCRIPT="${ETC_INIT_DIR}/rc.${DAEMON}"
BINARY="/usr/bin/$DAEMON"
TMPOUT="/tmp/sisout"
retval=0

read ARGUMENT
$(${BINARY} "$ARGUMENT" > ${TMPOUT})
cat ${TMPOUT}
rm -f ${TMPOUT}

exit $retval

FritzBox-seitig. Inetd-Config:
Code:
9991 stream tcp nowait    root    /var/media/ftp/SYSTEM/sisgateway.sh

Von jedem anderen beliebigen Rechner (in dem Falle Linux-basiert, z.B. von deinem Raspberry gesendet):
Code:
echo "-f 2" | nc fritz.box 9991

"-f 2" ist in dem Falle ein Argument für sispmctl, was auf der Box läuft (bedeutet "Steckdose Nr. 2 ausschalten")

Edit: In dem Zusammenhang ist mir übrigens eine interessante Verwendung für diese CLIENT-SERVER-Aufteilung aufgefallen, an der ich persönlich interessiert bin: Ich habe neben meiner 7490 als Hauptbox noch eine 7390 im Client-Modus. Dort herrscht es mit den Namen das gleiche Chaos und man musste sie bis jetzt alle doppelt pflegen (in der Hauptbox und in der Zweitbox). Wenn ich jetzt allerdings deine Skripte auf beide Boxen packe und sie auf einem Port wartend laufen lasse, kann ich dann vom dnsmasq heraus beide (oder beliebig viele) Boxen mit den Informationen versorgen. Es wäre deinem Ansatz mit dem Raspberry-Pi sehr ähnlich. Also, wenn du ein Paar Tagen abwartest, poste ich es vielleicht hier, wie man es machen kann. Ich will nur die Doppelarbeit ersparen, wenn du schon damit angefangen hast.
 
Zuletzt bearbeitet:
Ich melde mich wieder mit meiner CLIENT-SERVER-Aufteilung, da ich hierbei einige Nebeneffekte entdeckt hatte und diese nun hier zur Diskussion stellen will.
a) Ausgangslage: 7490 mit 7.12 als Hauptbox mit dnsmasq als DHCP-Server + 7390 mit 06.86 im Client-Modus + 1750E mit 7.12 im Client-Modus. Alle Boxen mit FREETZ (auch der Repeater)
b) Umsetzung in etwa wie oben beschrieben mit nc, inetd und read, allerdings Shell-Skript etwas umgeschrieben, damit es in dieses Schema rein passt. Posten will ich es hier noch nicht, weil ich es noch teste und es noch alles im Fluss ist
c) Z.B. die echo-logging-Sektion sollte in dem Falle anders umgedacht werden, sonst landen alle Logs auf der Box mit dem dnsmasq. Bei vielen Clients ist es dann schwierig sie auseinander zu halten und in meinem Falle wollte ich es zu debugging-Zwecken auf jeder Box separat haben. Also, ich habe es entsprechend umgeschrieben

Beobachtungen:
1. Jetzt habe ich verstanden, warum du wahrscheinlich meine Änderung
Code:
CTLMGR_REQUEST=$(ctlmgr_ctl w landevice "settings/$LANDEVICE_TO_CHANGE/name" $MYHOST)
echo "Der Hostname des $LANDEVICE_TO_CHANGE wurde in $CTLMGR_REQUEST geändert."
mit dem REQUEST nicht übernommen hast. Das Verhalten ist nämlich bei einer 7490 und einer 7390 bei mir unterschiedlich. Wenn 7490 mit 7.xx-Firmware an der Stelle den geänderten Namen zurückmeldet, was ich wiederum als Erfolgsmeldung interpretiere, tut die 7390 dies nicht und vermeldet zurück die leere Menge. Auch im Falle eines Erfolgs. Tun das vielleicht deine Boxen auch so? Und hier kommt meine nächste Verständnisfrage.
2. Anscheinend kann ctlmgr_ctl nicht immer die Namen ändern. Reproduzierbarer Fall: Ein Gerät meldet sich per WLAN an meinem Repeater 1750E und ist dort WLAN-technisch "verbucht". Bei dem zweiten "WLAN-Repeater" (nennen wir es diesmal so), meiner 7390, ist dann dieses Gerät ausgegraut, weil es sich für den anderen Repeater mit dem stärkeren Signal entschieden hat. In dem Moment kann der Name anscheinend nicht geändert werden. Zumindest beobachte ich es so. Vermutlich gibt es da unter den landevices irgendwas zum Status, wie active oder ähnlich. Das hatte ich noch nicht genau nachgeforscht. Es könnte sein, dass man zum erfolgreichen Ändern des Gerätenamens (auch im nicht aktivierten Zustand) dieses landevice erstmal fake-mäßig aktivieren sollte, dann ändern und dann wieder deaktivieren. Das muss ich erstmal auch nachforschen.
3. Bei dem Repeater 1750E war ich überrascht, als ich die ganzen Gerätschaften als "ausgegraut" vorgefunden habe. Ich meine, dass es in den früheren Firmwareversionen noch nicht so war. Jetzt wird anscheinend im LAN-Brücke-Modus (AVM-Bezeichnung) komplett die "Netzwerk"-Seite deaktiviert und unter WLAN findet man alle Geräte nur ausgegraut dargestellt und mit ihren PC-XXX-YYY-ZZZ-Namen. Dies würde meine Theorie von oben bestätigen, dass hier alle Geräte (warum auch immer) unter landevices als nicht aktiv markiert sind, wodurch auch die Namensänderung nicht möglich ist. Aber auch hier muss ich erst nachforschen, was da wirklich los ist.
4. Die Nummern der landevices werden sehr oft und auf eine für mich unerklärliche Weise geändert. Das ist mir durch meine Logs aufgefallen. Ganz schlimm ist es beim Repeater 1750E, wo ja die Namen gar nicht abgespeichert werden können. Warum die landevices immer wieder fleißig durchgemischt werden, ist für mich nicht erklärbar. Dadurch, dass es im Skript immer nach der MAC-Adresse gesucht wird, spielt es erstmal keine Rolle. Dennoch wäre es gut zu wissen, warum AVM es ständig macht.

Ich melde mich später mit weiteren Erkenntnissen.
 
Ich möchte nun, dass im AVM-WebIF unter Netzwerk, die bekannten Netzwerkgeräte nicht mit "PC-192-168-1-150" angezeigt werden, sondern mit ihrem Hostnamen. Klar, man kann das manuell ändern, doch es sollte doch auch irgendwie automatisch gehen.
Ich verwende meine F!Bs nicht als DHCP-Server, doch ich habe in den F!Bs die Namen, die ich den Systemen per Bind gebe. Bei einigen habe ich aber auch die Namen, die sich die Systeme selber geben. (Radio im IP-Anschluss, Sat>IP-Empfänger, ..)
Einträge nach dem Schema "PC-..." habe ich nur für Systeme, die schon länger nicht mehr aktiv waren, aber nicht im F!B-Cache stehen.
 
@Theo Tintensich: Und wie kommen die Namen auf die Box? Und wo läuft dein Bind? Ich verstehe leider nur Bahnhof von deiner Konfiguration und kann nur raten. Auch im Falle von dnsmasq als DHCP landen nun nach WileC-Methode die Namen der Clients, die sie sich selbst vergeben (wenn sie nun können) jetzt in der AVM-Liste und im AVM-WebIF entsprechend, was früher auch nicht der Fall war. Zusätzlich hat man durch dnsmasq noch einige weitere Features, die AVM-WebIF nicht unbedingt bietet (wenn man die denn braucht). Mit bind bist du natürlich noch weiter, als dnsmasq. Aber ist eigentlich bind nicht langsam obsolete? Im Serverbereich ist man schon längst auf andere Alternativen, wie z.B. PowerDNS umgestiegen...
 
Ich benutze die 7590 nur als Router und als Umsetzter VoIP=> ISDN, um die 5020 zu bedienen.
Die 7390 arbeitet als ISDN-Client an der 500 und bedient das DECT-Telefon und die VoIP-Anschlüsse.(zu ISDN), da die 5020 zu wenige VoIP-'Plätze' hat.

Die IP-Verteilung (DHCP) und auch die Namensauflösung (Bind) macht ein Devuan-Server. Wenn ich in der 7390 nachsehen (in der sehe ich häufiger nach ;-), sehe ich in den Netzwerkeinstellungen die im Netz aktiven Systeme hauptsächlich mit ihren BIND-Namen.
Doch, wie gesagt, zeigt sich bei der F!B z.B. ein Radio (mit IP-Möglichkeit) und der SAT>IP-Server mit den dort eingestellten Namen.
Systeme, die nicht (mehr) aktiv sind, und deren IP (ich habe ein kleinen freiemn DHCP-Bereich für Systeme nur nur gelegentlich im Netz sind) nicht anders belegt sind, werden bei mit mit dem Namen "PC-'MAC-Adresse'" angezeigt.
Ich habe eben ein Geräte festgestellt, das mit PC-MAC erscheint, es ist Pinbar, aber ich komme nicht mehr per SSH drauf (in PI, die sich aufgehangen hat)
 
Hm, eine recht merkwürdige Kombination. Vor allem verstehe ich nicht, warum man ISDN dort als Zwischenmedium nutzt. Die ganzen Filterregeln für Telefonie und wie man von innen nach "zwischeninnen" telefoniert will ich gar nicht wissen. Denn vermutlich **1 auf 7590 und ähnliche Sachen werden da nicht so einfach gehen. Aber sei es rum. Darum geht es hier nicht. Mich würde interessieren, wie deine 7390 netzwerktechnisch da eingebunden ist, denn "ISDN-Client" ist erstmal aus der Netzwerk-technischen Sicht keine Aussage. Ich betreibe meine 7390 im IP-Client-Modus (wie man es eigentlich tun sollte), die meisten der Netzwerkteilnehmer "sitzen" aber vor der 7390 und nur ein Paar dahinter bzw. an dem WLAN von der 7390, wenn sie sich dafür entscheiden. Wo sitzt denn dein DNS / DHCP im Netzwerk? Kann es sein, dass du an der 7390 noch den AVM-DNS am Laufen hast? Vielleicht sollte ich dort auch ein Image ohne dnsmasq bauen? Dann löst es sich von alleine (was ich eher wenig glaube)? Kann sein, dass bei deiner 7390 noch der DHCP-Server "mitläuft"?
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.