AVM-interne Datenbank von FREETZ aus editieren, ergänzen und steuern

Nein, der Abschnitt definitiv nicht. Allerdings kann es gut sein, dass man für den Abschnitt diverse Definitionen vorher machen musste. Ich hatte da einfach ein Stück von einer Function als Hauptprogramm erklärt. Ich muss zugeben, ich kenne mich mit LUA gar nicht aus. Ich kann schon die in LUA geschriebenen Sachen verstehen und sogar einiges ergänzen, in den Definitionen bin ich aber ziemlich schwach. Und genau an der Stelle vermute ich Probleme, die ich leider aufgrund den fehlenden Fehlermeldungen schlecht identifizieren kann.
Versteh es bitte nicht falsch, sf3978: Deine Lösung mag für fehlerfreie LUA-Skripte funktionieren. Für so einen LUA-Neuling wie ich, ist ein solcher Blindflug leider nicht besonders zielführend. Ich werde meine Idee mit LUA wohl aufgeben.

MfG
 
Versuch es mal hiermit:
Code:
int main (int argc, char **argv)
{
  int ret;
  lua_State *L = luaL_newstate ();
  luaL_openlibs (L);

  if (argc < 2) {
    fprintf(stderr, "%s: missing argument lua-script\n", argv[0]);
    return 1;
  }
  if (luaL_loadfile (L, argv[1])) {
    fprintf(stderr, "%s: Error loading lua script %s\n", argv[0], argv[1]);
    lua_close(L);
    exit (1);
  }

  ret = lua_pcall (L, 0, 0, 0);
  if (ret)
    lua_error(L);

  lua_close(L);
  return ret;
}
Damit sollte bei Fehlern eine Meldung von LUA kommen.
 
Stimmt, jetzt kommen die Fehlermeldungen. Binary ist jetzt auch 11kB anstatt 50kB vorher... Ich verstehe zwar nicht warum, aber egal. Laufen tut es erstmal und Fehlermeldungen werden ausgegeben. Versuche mich jetzt durch die Fehlermeldungen durchzukämpfen...

Danke, Ralf!

MfG
 
Egal mit 50kB. Vergessen wir es...
Jetzt habe ich ein Problem, dass alle Aufrufe zur Hauptklasse "box" (oder wie man auch immer es nennen soll) mit Fehler quittiert werden:
Code:
...
g_oem = box.query("env:status/OEM")
...
Fehlermeldung:
Code:
PANIC: unprotected error in call to Lua API (./landevice.lua:3: attempt to index global 'box' (a nil value))

So, wie ich es aus LUA-Syntax verstanden habe, kann man auf box.query(xyz) dann zugreifen, wenn man z.B. eine box.lua mit "require" vorlädt und dadrin die Funtkion "query" vorhanden ist. Das Problem ist aber, dass ich nirgendswo bei AVM so einen "require" gefunden habe. Viel mehr, sie rufen fast immer diese box.irgendwas(xyz) ziemlich am Anfang von deren LUA-Skripte. Meine Vermutung: Diese "box"-Hauptklasse ist in irgendeiner vorkompillierten Bibliotheken von AVM erhalten. Wir haben womöglich vergessen diese Bibliothek einzulinken. Es kann natürlich sein, dass ich komplett auf dem Schlauch stehe. Bitte berichtigt mich dann...

MfG
 
- 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
 
@hermann72pb ich weiß der Thread ist schon echt alt, aber hast du in die Richtung noch weiter geforscht?
 
Zu einem ist das Ganze damals hier mit meinen unbeantworteten Fragen geendet und ich bin an der Stelle auch kaum weiter gekommen. Zum anderen sind es wirklich schon fast 12 Jahre seit dem vergangen. Es hat sich nicht nur sehr viel an der AVM-Software geändert, sondern es gibt hier kaum mehr die Hauptplayer, die mich damals dabei aktiv mitbegleitet hatten. FREETZ gibt es auch nicht mehr, sondern FREETZ NG und es ist hier in der Community wirklich kaum mehr was los, wenn man es mit der intensiven Phase so um 2006...2012 vergleicht. Also, es gibt keine fertige Lösung, um es kurz zu fassen.
Ich hatte damals basierend auf den Informationen aus diesem Thread auch noch was in Richtung ctlmgr_ctl gemacht und mir ist damals auch was in die Richtung gelungen. Es müsste hier auch was dazu in einem separaten Thread geben. Zumindest hatte ich damals versucht meine Informationen hier mit anderen zu teilen. Da meine Themen damals aber zu spezifisch waren, gab es keine wirkliche Resonanz dazu, sodass ich dann irgendwann mal aufgehört habe, hier Monologe zu führen.
Wenn du Interesse hast, kann ich dir meine Shell-Skripte von damals zur Verfügung stellen. Mir war damals gelungen, mit diesen Skripten und ctlmgr_ctl Befehlen dnsmasq und AVM halbwegs zu synchronisieren und sogar einen Sync zwischen mehreren Boxen bei mir zuhause durchzuführen. Aber die Skripte nutze ich aktuell nicht und weiß auch nicht, ob sie noch laufen und das tun, was ich ursprünglich damit bezwecken wollte. AVM hat ja seitdem nach und nach überall MESH eingeführt. Meine damaligen Versuche mit mehreren Boxen waren ja so gesehen eine Art von MESH.
Daher wäre es hilfreich, zunächst überhaupt zu hören, was du denn erreichen willst. Danach kann man abschätzen, ob es umsetzbar wäre und ob es überhaupt sinnvoll ist.
Und wie gesagt, den alten Anreiz, eine AVM-Box überhaupt modifizieren zu wollen hat AVM uns hier methodisch und Jahr zu Jahr abgewöhnt. Daher findest du hier auch kaum einen mehr, der dir dabei helfen kann.
Wenn du Lust auf OSS hast und selbst die Hand anlegen willst, nimm dir lieber eine andere Hardware, als die von AVM. Mittlerweile ist die Auswahl dazu deutlich besser, als z.B. im Jahr 2012!
 
Mein Ziel ist es über die normale Fritzbox UI die IP Adresse von Clients zu setzen und diese soll dann der dnsmasq vergeben.
Der Teil mit dem auslesen aus der AVM Datenbank und in eine Dnsmasq Config schreiben funktioniert bereits.

Ich kann nur bei manchen Geräten die IP in der AVM UI nicht mehr ändern ( ging früher glaube ich bei allen Geräten, kann mich da aber täuschen).
Sobald die Fritzbox einmal eine IP an das Gerät per DHCP vergeben hat, wird es editierbar.

Ich habe bereits die dumps von ctlmgr_ctl verglichen, einer der Unterschiede ist, dass z.B. dhcp auf 0 steht, wenn der Fritzbox eigene DHCP Server dem Gerät keine IP gegeben hat.
Es lassen sich aber nicht alle Werte setzen, wie hier bereits angemerkt wurde.

Die Script von dir hören sich sehr vielversprechend an. Falls du die noch hast würde ich mich freuen wenn du sie irgendwo hochladen könntest.
Einen extra Thread von dir zu dem Thema hab ich leider nicht gefunden.
Ich hoffe das du evtl. schon herausgefunden hast, wie man die nicht per ctlmgr_ctl editierbaren Werte ändern kann

Das AVM das nicht möchte ist schade, aber Im Cable Bereich kenne ich nicht wirklich eine alternative, ohne ein extra Modem zu betreiben,
 
[Hier] ist die von mir angesprochene Diskussion. War gar nicht mein Thread damals, ich hatte aber da mitdiskutiert. Lies es dir durch. Eine damals funktionierende Version des Shell-Skriptes von WileC ist dort gepostet, Auch ein Paar weitere Ideen von mir sind dort gepostet.
Auf meiner produktiven Box läuft diese Geschichte nicht mehr. Dort sind auch keine Skripte mehr zu finden, da ich dort kräftig aufgeräumt hatte. Ich habe einige Überreste auf der zweiten Box gefunden, aber die Skripte sind im Grunde eine leichte Modifikation von dem Original von WileC.
Du musst aber dabei auch bedenken, dass uns dort NUR UM DIE ANPASSUNG DES NAMES ging, nicht der IP und nicht der anderen Parametern. Und wir haben es im Grunde dort auch andersrum gemacht, als du es willst, nämlich von dnsmasq Richtung AVM. Sprich, der DHCP von AVM abgeschaltet, daher kann er die Namen im AVM-WebIF nicht ändern und nimmt sie von dnsmasq, der als DHCP läuft.
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,347
Beiträge
2,250,583
Mitglieder
374,001
Neuestes Mitglied
curious2315
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.