- ich konnte mit strace keinerlei Kommunikation zwischen ctlmgr und multid beobachten. Meine Vermutung vorher war, dass sich die beiden in irgendeiner Art und Weise unterhalten. Dies war jedoch auch beim vollständigen strace (allerdings ohne -f) nicht zu sehen.
Wie ich bereits im Thread zu dnsmasq/multid-Listen geschrieben hatte, konnte ich mit strace doch Einiges beobachten, was mich zum besseren Verstehen der AVM-Kommunikation zwischen ctlmgr und multid brachte. Zwar bin ich immer noch hinter der dubiösen "Datenbank" hinterher, die ich immer noch nicht gefunden habe. Dafür weiß ich zumindest halbwegs, wie ctlmgr und multid die Informationen untereinander austauschen. Dies betrifft nicht nur leases, sondern ist von allgemeiner Bedeutung interessant. Daher erkläre ich es nochmal hier in einigen Details:
1. Es gibt sockets, die wir oben bereits diskutiert haben. Darüber kommuniziert luacgi mit ctlmgr. Die Kommunikation erfolgt in XML.
2. Es gibt aber auch Sockets von multid. Die nutzt z.B. ctlmgr, um dem multid "etwas wichtiges" zu sagen. Das kann z.B.
a) "generate static lease" sein. Darauf generiert multid ein statisches lease für eine bestimmte MAC und IP. Gerät muss nicht aktiv sein
b) "neightransfer". Daraufhin schickt multid ausführliche Informationen Richtung ctlmgr.
Man würde für 2b logischerweise annehmen, dass der Informationfluss von multid Richtung ctlmgr über Sockets erfolgt. Dies ist aber nicht der Fall. Wahrscheinlich kommt dieses Teil der Kommunikation noch von der "alten Technik" von AVM. Es wird so gemacht:
- ctlmgr schickt an multid per Socket "neightransfer" als Anfrage
- multid legt eine Datei /tmp/neghnew.cfg an und schreibt dorthin eine Konfiguration rein, die vom Syntax her der ar7.cfg ähnelt (also, kein XML, sondern diese verzweigte {} mit mehreren Sektionen ohne Namen)
- /tmp/neighnew.cfg wird in /tmp/neigh.cfg von multid umbenannt
- ctlmgr wartet, bis /tmp/neigh.cfg lesbar wird und liest /tmp/neigh.cfg
- ctlmgr löscht /tmp/neigh.cfg
Also, eindeutig Anfrage per Socket, Antwort per Datei.
Meine Fragen wären:
- Wie können wir am elegantesten eine solche Anfrage "abfangen" und die Antwort "fälschen"?
- Kann man sich zwischen den Sockets "anhängen" und (oder zumindest) die Kommunikation dort "abhören"?
- Kann man multid so patchen, dass anstatt /tmp/neigh.cfg dort z.B. /tmp/fretr.cfg steht? Z.B. mit df? Die ASCII-Stellen in der Binary von multid habe ich gefunden. Dies würde uns die Möglichkeit geben, auf dem "Rückwege" die Datei zu bearbeiten und sie dann in /tmp/neigh.cfg umbenennen. ctlmgr würde davon nichts mitbekommen.
MfG