DNSMasq und Übertragung der Hostnamen ins Fritz WebIF

[hermann72pb]

@er13: Ich bin schon dran. Ich habe den notwendigen Patch insofern angepasst, dass es jetzt einigermassen "AVM-like" aussieht (s. Anhang).

Folgende Sachen sind mir gelungen:
1. MAC-Adressen werden mit kleinen Buchstaben geschrieben (warum auch immer AVM es nun so macht)
2. Dieser Punkt und noch zum zweiten Mal MAC dahinter und "" ist drin
3. Neben "wlan" habe ich da noch alle denkbaren Devices verodert

Folgendes funktioniert trotzdem nicht:
1. AVM-Zeugs will die generierte Datei nicht annehmen. Die Devices werden in AVM-WebIF trotzdem als PC-XX-YY-ZZ-... angezeigt, obwohl multid.leases einen Namen enthält.
2. wlease-Erkennung funktioniert trotzdem nicht. Warum, weiß ich nicht. Wahrscheinlich liegt es nicht an "wlan" als Namen, sondern es gibt noch weitere Probleme. Oder ich bin zu doof, c zu schreiben...
3. multid.leases steht sehr oft leer da. Wahrscheinlich wird sie vom multid überschrieben... Im AVM-WebIF aktiv was am Netzwerk machen ist Tabu. Nach solchen Aktionen ist multid.leases definitiv leer.

MfG

 

[er13]

Hmm, habe wohl parallel gearbeitet...

Anbei meine Version des Patches:

• die zwei Aufrufe von lease_set_ifrname-Aufurfe entfernt, da es 4 Stellen gibt, wo diese aus meiner Sicht fehlen (ich verstehe es so, wenn lease_set_interface aufgerufen wird dann muss auch lease_set_ifrname aufgerufen werden, das war nur an zwei Stellen der Fall, an den anderen 4 aber nicht).
• stattdessen wird der interface_name in dem Moment ermittelt, zu dem multid.leases rausgeschrieben wird
• wlan-Erkennung funktioniert bei mir trotzdem nicht, es scheint als würden DHCP-requests immer auf dem lan-interface ankommen (siehe syslog-Ausgaben). Hat AVM da was zusammengebridged?

 

[hermann72pb]

@er13: Ich würde es nicht als Parallelarbeit sehen. Ich habe mich wieder etwas in das Thema "patchen von c-Programmen" eingearbeitet. Alleine das ist für mich schon Wert. Außerdem ist bei mir der dnsmasq gerade und hoffentlich immer noch über "mount -o bind" eingebunden, wenn die Box inzwischen nicht rebootet hat. Also, ich kann relativ schnell und leicht testen.
Hattest du denn in AVM-WebIF Verbesserungen gesehen, er13? Welche Box hast du überhaupt und mit welcher AVM-Firm. Denn dies wäre für das AVM-WebIF entscheidend.
Ich melde mich, sobald ich was getestet habe. Syslog muss ich auch zuerst vom entfernten Server auf die Box legen und Kernel-Meldungen abschalten, sonst finde ich da gar nichts.

MfG

 

[er13]

Parallelarbeit: ich habe eher mich gemeint. Hätte ich gewusst, dass Du da was machst, hätte ich vielleicht erst gar nicht angefangen, selbst da rumzuwursteln. Aber es hat mal wieder Spass gemacht, sich im fremden Code zurecht zu finden, auch wenn er an manchen Stellen nicht so gut ist (manche Funktionen sind echt zu lang, so über 1000 Zeilen).

Ich habe lediglich eine 7170. Und wie man mit brctl nachschauen kann, sind bei dieser alle Interfaces (zusammen-)gebridged. Daher kommt bei mir alles auf lan an. D.h. Erkennung WLAN vs. LAN anhand des Interface-Indexes oder -Namen (so wie es aktuell umgesetzt ist) ist schlicht und ergreifend nicht möglich. Wie es mit dem Zusammenbridgen auf anderen Boxen ausschaut, kann ich nicht sagen.

 

[hermann72pb]

Ich habe im Unterschied zu dir mir es nicht komplett angeschaut, sondern hatte mich lediglich an der Stelle konzentriert, wo es in multid.leases geschrieben wird. Du hast aber Recht, man soll sich es komplett anschauen.
Es ist aber gut, dass du noch eine 7170 hast. Alle von meinen 7170 sind schon längst im Keller gelandet. Ich habe aktuell 7270v3 und eine noch nicht ausgepackte 7390. Also, wir können schon gemeinsam ziemlich breit testen...

MfG

 

[hermann72pb]

@er13: Ich habe deinen Patch ausprobiert. Es scheint genau so zu funktionieren, wie meine Änderungen. Dass dort jemand an Tausenden Stellen wahllos nach dem Typ vom LAN-Interface rumfragt, da gebe ich dir Recht: Es muss nicht sein und es ist wahrscheinlich richtig, dass du es wegoptimiert hast. wlan wird auch bei mir nicht erkannt. Ich glaube, da läuft generell etwas falsch an der Erkennung.
Nun haben wir das eigentliche Problem aber immer noch nicht gelöst:
1. multid scheint heutzutage sich gar nicht für multid.leases zu interessieren. Bzw. egal, was wir da rein schreiben, es wird vom multid ignoriert.
2. Manchmal wird multid.leases geleert, obwohl dnsmasq.leases noch Einträge behält. Wer bzw. was verändert multid.leases? Warum wird die Datei geleert?

Um dem multid vorzugaukeln, es käme ein neuer Rechner mit dem Namen so und so, müssen wir mit ihm reden. Ich weiß allerdings nicht wie. msgsend? ctlmgr_ctl? Welche Parameter. Ich habe da schon ziemlich alles ausprobiert. Fast immer leider erfolglos.

MfG

 

[er13]

Wie gesagt, solange die Interfaces zusammengebridged sind, wirst Du mit der jetzigen Methode nicht erkennen können, ob es sich um WLAN oder LAN handelt. Aus dnsmasq-Sicht kommen alle Anfragen auf dem lan-Interface an. Das ist dann einfach zu spät.

Ich weiß nicht, wie es auf den neueren Boxen ausschaut (7390), da sind die beiden WLAN-Interface glaube ich getrennt. Da könnte die jetzige Methode eventuell funktionieren (zumindest auf einem der Interfaces).

Was multid anbetrift, da kann leider wenig bzw. gar nichts dazu sagen. Muss man forschen, wer da alles, was, wann reinschreibt.

 

[hermann72pb]

Mit wlease/lease hast du Recht, er13. Es wird schwierig mit eigenen Mitteln es eindeutig auseinander zu halten. Man muss genau anschauen, wie AVM es machen...
Wie du sicherlich im anderen Thread mitbekommen hast, versuche ich die Problematik etwas breiter anzugehen und auf die internen Daten von ctlmgr und multid zuzugreifen. Bis jetzt gelingt es mir nur bedingt, die Untersuchungen an der Front laufen aber weiter.
Zu dnsmasq / multid habe ich eine Frage an dich, er13: Warst du auch an der preload-Geschichte für multid beteiligt? Man hat versucht, durch Preloads den multid von den DNS und DHCP Ports zu vertreiben. Es scheint auch zu gehen, allerdings empfinde ich, dass multid sich dennoch etwas komisch verhält.
Ich habe heute nach meinen unzähligen Versuchen irgendwie einen Zustand auf der Box reproduziert, wo der DHCP-Server von AVM halbwegs lebendig ist. Und zwar, ich habe den DHCP-Server von AVM aktiviert, gleichzeitig aber den dnsmasq laufen gelassen. Bei dieser Einstellung scheinen ctlmgr und multid sich etwas anders zu verhalten. Man sieht plötzlich im WebIF die über DHCP ausgelesenen Namen der Netzwerkteilnehmer. Sowas ist z.B. beim abgeschalteten DHCP-Server von AVM schlicht unmöglich. Das Interessante an der Geschichte ist aber, wie der multid an die Daten von den DHCP-Klients kommt. Laut netstat lauscht auf dem Port 67 eindeutig der dnsmasq! Der multid scheint aber brav die Leases in /var/flash/multid.leases zu schreiben. Und ja, das ist multid und nicht dnsmasq, weil ich einen ungepatchten dnsmasq auf der Box habe und weil die Einträge auch "wlease" enthalten, was mit dnsmasq nicht möglich ist. Frage: Wie kommt multid an die DHCP-Daten, wenn dnsmasq auf dem Port 67 lauscht?

MfG

 

[er13]

Zu dnsmasq / multid habe ich eine Frage an dich, er13: Warst du auch an der preload-Geschichte für multid beteiligt? Man hat versucht, durch Preloads den multid von den DNS und DHCP Ports zu vertreiben. Es scheint auch zu gehen, allerdings empfinde ich, dass multid sich dennoch etwas komisch verhält.

Beteiligt, nur minimal. Ich "kam dazu" als es schon mal sowohl die Idee als auch die erste funktionierende Umsetzung gab. Ralf und ich haben nur die Qualität des C-Codes etwas verbessert. Meines Wissens funktioniert dieses Vertreiben auch einwandrei auf allen Boxen (nur FREETZ_LIB_libmultid_WITH_LOCAL ist etwas problematisch, aber das ist sowieso was anderes).

habe den DHCP-Server von AVM aktiviert, gleichzeitig aber den dnsmasq laufen gelassen...

Hmm, und wer von beiden hat denn an udp:67 gelauscht? Ich nehme mal an beide (das würde gehen, denn es ist UDP und dnsmasq setzt SO_REUSEADDR auf dem socket).

Man sieht plötzlich im WebIF die über DHCP ausgelesenen Namen der Netzwerkteilnehmer. Sowas ist z.B. beim abgeschalteten DHCP-Server von AVM schlicht unmöglich. Frage: Wie kommt multid an die DHCP-Daten, wenn dnsmasq auf dem Port 67 lauscht?

Ich denke es ist alles viel einfacher. Multid lauscht an 67 (egal, ob alleine oder mit dem dnsmasq zusammen) und kriegt dadurch halt alles mit. Neben dem Beantworten der DHCP-Anfrage, macht es noch etwas zusätzlich, nämlich in diese "interne Datenbank" (wo auch immer sich diese befindet) die Netzwerkteilnehmer reinschreiben (ich bin mir nicht sicher, ob Du das gleiche mit dem etwas seltsam klingelnden "die über DHCP ausgelesenen Namen der Netzwerkteilnehmer" meinst). Ich weiß nicht, ob multid für dieses "in DB Schreiben" ctlmgr aufruft (möglicherweise über socket) oder einfach selbst direkt in die DB schreibt und ctlmgr es daraus dann ausliest.

 

[hermann72pb]

Und warum sehe ich dann über netstat nur dnsmasq auf dem Port 67? Außerdem scheint doch die Verlegung des Ports auf 50067 geklappt zu haben (das bewirkt doch Preload):

root@fritz:/var/mod/root# netstat -a -tu -enp
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
...
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      14299/dnsmasq
...
tcp        0      0 :::50053                :::*                    LISTEN      14841/multid
...
tcp        0      0 :::53                   :::*                    LISTEN      14299/dnsmasq
...
udp        0      0 0.0.0.0:50067           0.0.0.0:*                           14841/multid
udp        0      0 0.0.0.0:53              0.0.0.0:*                           14299/dnsmasq
...
udp        0      0 0.0.0.0:67              0.0.0.0:*                           14299/dnsmasq
...
udp        0      0 :::50053                :::*                                14841/multid
udp        0      0 :::47757                :::*                                14841/multid
udp        0      0 :::50074                :::*                                14841/multid
udp        0      0 :::7077                 :::*                                3088/voipd
udp        0      0 :::53                   :::*                                14299/dnsmasq
udp        0      0 :::55353                :::*                                14841/multid
udp        0      0 :::55353                :::*                                14841/multid
udp        0      0 :::55355                :::*                                14841/multid
udp        0      0 :::55355                :::*                                14841/multid
...

Mit "in die Datenbank schreiben" meine ich, dass die per DHCP automatisch ermittelten Wunschnamen (Client -> Server) nun plötzlich in der "Datenbank" und in AVM-WebIF auftauchen. Mittlerweile (nach einigen Stunden) wurde /var/flash/multid.leases von dnsmasq überschrieben. Dies hatte aber keinerlei Auswirkung auf die Webanzeige und auf die "interne Datenbank". Wie ich bereits vermutet hatte, reicht es nicht, einfach multid.leases zu beschreiben.
Bzgl. Kommunikation zwischen ctlmgr und multid. Heute hatte ich mehr Glück und hatte sie tatsächlich mit strace beobachtet. Es sieht so aus, dass multid die leases komplett alleine verwaltet. Wenn man per WebIF einen neuen Netzwerkteilnehmer mit einer festen IP hinzufügt, schickt ctlmgr ein "generate_static_lease" Richtung multid.

MfG

 

[er13]

Kurze (habe leider viel in der Arbeit zu tun) Rückmeldung von mir: wenn dnsmasq alleine auf dem 67 gelauscht hat, dann muss ich erstmal passen, dann weiß ich nicht, wie multid das mitgekriegt hat.

 

[hermann72pb]

Ein denkbarer Weg wäre SAMBA (bzw. besser gesagt NMBD?) oder neuerdings dieser WIN7-Dingens auf den Ports 5353 / 5355. Obwohl auch diese Port eigentlich nach oben transferiert wurden (55353 / 55355). Von daher verstehe ich es auch nicht.

MfG

 

[hermann72pb]

Nach ein Paar Tagen kann ich über folgende halbwegs laufende Kombination berichten:
DHCP-Server von multid aktivieren und den DHCP-Server von dnsmasq ebenfalls.
Positive Effekte:
1. AVM-WebIF zeigt auch von DHCP-Klients ermittelte Namen an
2. DHCP an sich läuft aber über dnsmasq
3. Durch Preload von libmultid bleibt multid auf den entsprechenden Ports still, scheint dort aber zu "lauschen" und kriegt die DHCP-Kommunikation von dnsmasq mit. Daher bekommt er die Namen.
Negative Effekte:
1. Die Datei /var/flash/multid.leases wird von beiden DHCP-Server bedient und dementsprechend gegenseitig überschrieben. Es hat zwar keine Bedeutung und Auswirkung, ist aber nicht schön
2. multid versucht die IPs jedesmal zu vergeben, wenn dnsmasq dran wäre. Er hört ja schließlich mit. Das gelingt dem multid natürlich nicht, er schreibt aber seine "Wünsche" brav in multid.leases rein. Am Ende sieht man dort mehrere Einträge für das gleiche Gerät.

Inzwischen bin ich etwas hinterhergelaufen und weiß halbwegs, wie multid und ctlmgr miteinander reden. ctlmgr schickt dem multid eine Anfrage "neightransfer" und bekommt als Antwort eine Auflistung unter /var/tmp/neigh.cfg. Diese Datei erscheint dort nur für 2-3 Sekunden und wird danach vom multid gelöscht. Man kann diesen Vorgang aber selbst nachbilden und beobachten:

msgsend multid neightransfer
cat /var/tmp/neigh.cfg

Die angefragte Datei sieht vom Aufbau her sehr ähnlich den typischen .cfg-Dateien von AVM. In neigh.cfg steht aber sehr viel drin. Ich habe per strace gesehen, dass ctlmgr die Datei ausliest nachdem er dem multid die Anfrage geschickt hat.
Die Frage der Kommunikation zwischen ctlmgr und multid ist aber für mich immer noch nicht ganz klar. Der multid kennt irgendwie die Namen, die man "statisch" im AVM-WebIF vergibt. D.h. es muss auch den Weg geben, wo der ctlmgr dem multid den neuen Namen übermittelt. Diesen Weg habe ich noch nicht gefunden.

MfG

 

[F.Nietzsche]

Hallo,

hat sich bei diesem Thema eigentlich noch etwas getan? Ich habe nämlich das gleiche "Problem". Auch wenn es funktional nichts ändert, würde es mir trotzdem gefallen, die Hostnamen im Web-If lesen zu können.

Viele Grüße!

 

[hermann72pb]

Nein, von meiner Seite aus nicht, da ich keine Zeit mehr für FREETZ habe. Und da es lediglich der Schönheit und nicht der Funktionalität dient, will es anscheinen keiner sonst machen.

MfG

 

[vice_pres]

Schade auch, ich wollte gerade auch nochmal nachfragen. Starten beider DHCPs gleichzeitig führt bei mir leider zu Problemen mit manchen Clients, die machen permanent neue Anfragen dann leider