WOL bei Clientanmeldung

[Roadrunner86]

Hallo zusammen,

ich bin neu hier im Forum und beschäftige mich seit kurzer Zeit mit freetz. Ich habe mir ein kleines Projekt vorgenommen und würde es gerne mit freetz umsetzten, soweit das möglich ist. Vielleicht könnt ihr mir dazu ein paar Tipps geben.

Konkret geht es darum:
Ich möchte mein NAS im Netzwerk „on Demand“ über die Fritzbox starten bzw. in den Ruhemodus versetzen. Dabei soll das NAS über WOL gestartet werden, sobald sich ein bestimmter Client im Netzwerk anmeldet. Ich stelle mir das so vor, dass auf der Fritzbox eine Liste von Clients hinterlegt ist, deren Anmeldung dann den WOL triggert.

Gibt es eine Möglichkeit bei der Anmeldung eines Clients an der FB ein Script zu starten?

Ich muss dazu sagen, dass meine Linux Kenntnisse bist auf ein paar kleine Scripts recht beschränkt sind Aber aller Anfang ist schwer. Im Augenblick kämpfe ich mich noch durch die FAQs und weiß noch nicht so recht wo ich zuerst anfangen soll. Ich bin zumindest schon soweit, dass ich meinen ersten Trunk mit ein paar Packages erstellen konnte

Schöne Grüße

 

[koyaanisqatsi]

Guten Abend und willkommen im Forum

Der erste Schritt wird dann wohl sein, ein Skript zu schreiben, welches bei erfolgreichen Ping auf eine bestimmte IP Nummer true oder 1 als return zurückliefert.
Dann kann das nächste Kommando prüfen ob true oder 1 zurüchgegeben wurde und dann startet es WoL.

Sowas wird zum Beispiel manchmal in der /var/flash/debug.cfg gemacht, um sicherzustellen das ein Internetserver und/oder DSL eine Internetverbindung aufgebaut hat um eine Binary auf die Box zu laden.

Radislav von fritz.mod.net macht das zum Beispiel so:
(wenn google erreicht wird ist das Internet erreichbar)

while !(ping -c 1 www.google.de); do sleep 5; done

...ändern zum Beispiel auf:

while !(ping -c 1 192.168.178.20); do sleep 5; done

Anstatt 192.168.178.20 die IP des zu überwachenden Rechners eintragen und die nächste Zeile kann dann schon WoL ausführen.
Ich empfehle dir das fertige Skript über crond und dem crontab von root zu starten, dann blockiert es keine anderen Abläufe.
Denn in der debug.cfg oder rc.custom würde es den Start der Box blockieren, da es ja nicht abgelöst von der Shell läuft.

 

[Roadrunner86]

Hallo,

danke für die schnelle Antwort. An crontab habe ich auch schon gedacht. Allerdings habe ich etwas bedenken, dass ich ständig im Hintergrund alle Clients polle. Wie ist das mit der Systemauslastung, wenn im Hintergrund ständig ein ping abgesetzt wird? Das Problem dabei ist, immer wenn ein neuer Client hinzukommt muss ich die Liste neu pflegen.
Kann man die von der FB vergebenen DHCP Leases irgendwie abfragen? Gibt es eine Art Systemevent, wenn ein neuer Client angemeldet wird?

Schöne Grüße

 

[koyaanisqatsi]

freetz bietet ja schon ein komfotables editieren der crontab an.

Zitat: "...DHCP Leases irgendwie abfragen? Gibt es eine Art Systemevent, wenn ein neuer Client angemeldet wird?"
Antwort: Es würde mich nicht wundern, wenn AVMs ctlmgr_ctl das erledigen kann.
Mal schaun.....

Hab das hier dazu gefunden:

Die Struktur von landevices aus der ar7.cfg:

landevices {
        landevices {
                ip = 192.168.178.2;
                name = "deepsilver";
                mac = 00:00:00:00:00:00;
                medium = medium_wlan;
                auto_etherwake = no;
                ifaceid = ::;
        } {
                ip = 192.168.178.21;
                name = "deepthought";
                mac = 00:00:00:00:00:00;
                medium = medium_ethernet;
                auto_etherwake = no;
                ifaceid = ::;
        }
}

...und nun:

/usr/bin/ctlmgr_ctl r landevice settings/landevice0/active
/usr/bin/ctlmgr_ctl r landevice settings/landevice1/active
/usr/bin/ctlmgr_ctl r landevice settings/landevice2/active

u.s.w.

Wobei die Rückgabe des Kommandos entweder eine 1 für aktiv oder eine 0 für inaktiv zurückliefert.

Die Namen kriegste folglich so raus:

/usr/bin/ctlmgr_ctl r landevice settings/landevice0/name
/usr/bin/ctlmgr_ctl r landevice settings/landevice1/name
/usr/bin/ctlmgr_ctl r landevice settings/landevice2/name

u.s.w.

Was? Jetzt auch noch die IPs?
Nagut:

/usr/bin/ctlmgr_ctl r landevice settings/landevice0/ip
/usr/bin/ctlmgr_ctl r landevice settings/landevice1/ip
/usr/bin/ctlmgr_ctl r landevice settings/landevice2/ip

u.s.w.

Auch praktisch, die MAC lässt sich so auch herausholen:

/usr/bin/ctlmgr_ctl r landevice settings/landevice0/mac
/usr/bin/ctlmgr_ctl r landevice settings/landevice1/mac
/usr/bin/ctlmgr_ctl r landevice settings/landevice2/mac

Ohne eine Endlosschleife laufen zu lassen, kannste ja root seine crontab jede Minute checken lassen:

* * * * * sh ~/ip_check.sh

Jetz aber, ran ans Skript!

 

[hermann72pb]

@koyaanisqatsi: Deine Idee ist nicht weit durchdacht. Ich weiß es, weil ich mich zufällig mit dem DHCP-Klient vor ein Paar Monaten rumgeärgert hatte. Hier ein Paar Gründe:
1. Die Benennung der landevices ist sehr dynamisch, wenn ich es so positiv ausdrücken darf. Unter uns gesagt, ist es eine Katastrophe, die nach uns kaum bekannten Regeln von AVM abläuft
2. ctlmgr_ctl ist eine Krücke, die leider nicht alles aus der internen Datenbank von AVM abfragen kann
3. ctlmgr_ctl läuft nicht besonders schnell. Es ist ein Debugging-Werkzeug von AVM, welches nicht darauf optimiert ist, ständig im Hintergrund zu pollen

Also, Roadrunner86 hat schon Recht, man sollte versuchen, sich "dazwischen zu hängen". Und das kann man tun, wenn dnsmasq als DHCP-Server läuft. Zu dem Tierchen haben wir Quellen und die könnte man anfassen. Erfordert allerdings C-Kenntnisse und eher weniger shell-Scripting. Den Weg würde ich viel zielführender finden, als ständig im Hintergrund zu lauschen und alles abfragen.
Such einfach nach meinen Beiträgen hier und DHCP als Stichwort. Es dürfte vor ein Paar Monaten was dazu gegeben haben. Das Problem wurde damals auch in Trac behandelt und diskutiert. Irgendjemand hat letztendlich eine halbwegs akzeptable Lösung dazu beigetragen. Die Lösung ist für die Thematik hier eher weniger interessant, sondern der Weg dahin und vor allem ein Paar tote Äste, die mich in meiner Suche im AVM-DHCP-Kram begleitet hatten.

Edit: Hier ist die damalige Diskussion von mir und er13:
http://www.ip-phone-forum.de/showthread.php?t=250707
Er hat damals den Patch geschrieben. Das eigentliche Problem, bzw. Threadwunsch hatten wir aber damals nicht gelöst...

MfG

 

[koyaanisqatsi]

Ok Ok Ok

Dazu möchte ich aber klarstellen, dass es hier wirklich nur ums rauslesen von Infos aus der "persistenten" Datenbank ar7.cfg geht.
Ich möchte auch von schreiben mittels ctlmgr_ctl in die ar7.cfg deutlich abraten.
Zu 3. möcht ich auch noch anmerken, dass das AVM Webinterface sämtliche Einstellungen aus der ar7.cfg mittels ctlmgr_ctl holt.
Also meines Erachtens ein Konfigurationstool.

Nun nehm ich aber trotzdem an was du darlegst, da Erfahrung bei mir im Rang höher steht als Logik.

 

[hermann72pb]

Enige Klarstellungen:
1. ctlmgr_ctl weder liest aus noch schreibt in ar7.cfg, sondern in eine "interne Datenbank". Dies erkennt man dadurch, dass die Änderungen nicht sofort in ar7.cfg auftauchen
2. AVM Webinterface benutzt nicht ctlmgr_ctl, sondern ctlmgr direkt. Bzw. ctlmgr ist seit langem "AVM Webinterface". Das ist ein wesentlicher Unterschied. Damit sind deutlich tiefgründige Änderungen in der "internen Datenbank" möglich.

"Interne Datenbank" ist so ein Sammelbegriff, darum extra so eingedeutet. Wir vermuten nur, dass eine interne Datenbank existiert. Wo und wie sie gelagert ist, weiß keiner hier zu 100%.
Und auch die ganzen LUA-Geschichten reden nicht über ctlmgr_ctl mit dieser berüchtigter Datenbank, sondern auch irgendwie direkt. Dafür scheint LUA-Interpreter irgendwie speziell gepatcht sein, sodass er spezielle closed-source-Bibliotheken von AVM nutzt. Leider ist die Lizenzlage von LUA so, dass die AVMs dies dürfen, ohne, dass sie die Quellen dafür posten. Darum hatten sie sich vermutlich für LUA entschieden. Denn sonst hätte man diesen ganzen Quatsch auch in shell machen können, wie wir es in FREETZ tun.

Wir hatten im Züge meiner damaligen Versuche bereits versucht LUA für uns zu adaptieren, um eigene LUA-Skripte in Shell ausführen zu können. Dies war uns allerdings nicht so richtig gelungen. Wegen Anbindung der closed-source-Bibliothek von AVM.

MfG

 

[Roadrunner86]

Hallo zusammen,

nun muss ich mich wieder zu Wort melden. Ich habe einiges ausprobiert und die Tipps von koyaanisqatsi waren wirklich gut. Danke nochmal! Im nächsten Schritt kann ich ja mal überlegen, ob ich mich an den Vorschlag von hermann72pb ran wage. Wie gesagt, ich habe noch keine große Erfahrung was freetz bzw. linux im Allgemeinen betrifft. Aber es wird schön langsam.

So nun hier zu meinem Skript:

#!/bin/sh

# Define the MAC-Address of the NAS
NAS_MAC_ADDRESS=28:92:4A:32:03:E0

# Define a list with MAC-Addresses which causes the NAS to start
WAKEUP_CLIENT_LIST=/var/wakeuplist

# Define a variables; and set to zero
count=0
count_active_wakeup=0

# Define a temp variables for each client
is_active=0
mac_addr=00:00:00:00:00:00

# Define NAS variables, active state and name
nas_active=0
nas_name=""

# Get the maximum count of know devices
maxcount=$(ctlmgr_ctl r landevice settings/landevice/count)

# While going through each known device ...
while [ $count -lt $maxcount ] ; do
	
	# Get device settings
	is_active=$(ctlmgr_ctl r landevice settings/landevice$count/active)
	mac_addr=$(ctlmgr_ctl r landevice settings/landevice$count/mac)
	
	# Is it the NAS?
	if [ "$mac_addr" == "$NAS_MAC_ADDRESS" ] ; then
		if [ $is_active -eq 1 ] ; then 
		
			# Get NAS device name for ping
			nas_name=$(ctlmgr_ctl r landevice settings/landevice$count/name)
			
			# Clients are still active in FB even, when they are already shut down
			# Check state by pinging the client
			if [ $(ping -c 1 -w 3 $nas_name | grep received | cut -d ',' -f2 | cut -d ' ' -f2) -eq 1 ] ; then
				nas_active=1
			else
				nas_active=0
			fi
			
		fi
		
	fi
			
	# Is the client part of the wake-up list? 
	if [ -n "$mac_addr" ] && [ $(grep $mac_addr $WAKEUP_CLIENT_LIST | grep -v '^#' | wc -l) -gt 0 ] ; then
		if [ $is_active -eq 1 ] ; then 
			: $((count_active_wakeup++))
		fi
	fi
		
	: $((count++))

done

# Wake Up NAS, Power off NAS, or do nothing
if [ $nas_active -eq 0 ] ; then
	if [ $count_active_wakeup -gt 0 ] ; then
		ether-wake $NAS_MAC_ADDRESS
		echo $count_active_wakeup clients active, wakeup NAS
		logger -p $LOG_FACILITY $count_active_wakeup clients active, wakeup NAS
		
	else
		echo $count_active_wakeup clients active, NAS stays off
		logger -p $LOG_FACILITY $count_active_wakeup clients active, NAS stays off
	fi
else
	if [ $count_active_wakeup -eq 0 ] ; then
		echo $count_active_wakeup clients active, send NAS to sleep
		logger -p $LOG_FACILITY $count_active_wakeup clients active, send NAS to sleep
	else
		echo $count_active_wakeup clients active, NAS stays on
		logger -p $LOG_FACILITY $count_active_wakeup clients active, NAS stays on
	fi
fi

exit 1

Das Skript wird wie bereits von koyaanisqatsi vorgeschlagen über crond gestartet. Ich muss es jetzt nur noch so automatisieren, dass die Files auch beim Neustart der FB wieder auf das System kommen (USB-Stick/Eigenes Paket - bitte um Vorschläge).
Ganz kurz zur Funktionsweise, die eigentlich recht klar sein sollte Ich trage alle Clients die zum WOL des NAS führen sollen, mit deren MAC-Adresse, in das File /var/wakeuplist ein. Je nach Aktivität wird das NAS heruntergefahren oder gestaret.
Und hier kommt nun eine kleine Unschönheit der FB zu tragen. Wenn nämlich das NAS heruntergefahren wurde, ist der Status in der FB für ca. 5 Minuten weiter als aktiv gekennzeichnet. Das würde bedeuteten, dass sobald ich das NAS herunterfahre und kurz darauf wieder starten möchte, weil ein Client aktiv wird, funktioniert das nicht ohne kleine Tricks. Das Script würde das NAS als aktiv erkennen und würde keinen WOL antriggern. Daher setze ich zusätzlich noch einen Ping zu NAS ab, ob dieses wirklich noch aktiv ist.

Mehr Infos zur Statusabfrage der Clients habe ich übrigens in im Quelltext der network_user_devices.lua gefunden. Dort werden die Eigenschaften der Clients recht ausführlich aufgeschlüsselt:

  ["landevice:settings/landevice/list(name,ip,mac,UID,dhcp,wlan,ethernet,active,static_dhcp,manu_name,wakeup,deleteable,source,online,speed,wlan_UIDs,auto_wakeup,guest,url,wlan_station_type,vendorname,parentname,parentuid,ethernet_port,wlan_show_in_monitor,plc,ipv6_ifid)"] = {
    [1] = {
      ["UID"] = "landevice6090", 
      ["_node"] = "landevice3", 
      ["active"] = "0", 
      ["auto_wakeup"] = "0", 
      ["deleteable"] = "1", 
      ["dhcp"] = "1", 
      ["ethernet"] = "1", 
      ["ethernet_port"] = "4", 
      ["guest"] = "0", 
      ["ip"] = "192.168.0.70", 
      ["ipv6_ifid"] = "", 
      ["mac"] = "XX:XX:XX:XX:XX:XX", 
      ["manu_name"] = "0", 
      ["name"] = "DiskStation", 
      ["online"] = "0", 
      ["parentname"] = "", 
      ["parentuid"] = "", 
      ["plc"] = "0", 
      ["source"] = "0x1104", 
      ["speed"] = "100", 
      ["static_dhcp"] = "1", 
      ["url"] = "http://192.168.0.70", 
      ["vendorname"] = "Linux 3.2.30 x86_64", 
      ["wakeup"] = "0", 
      ["wlan"] = "0", 
      ["wlan_UIDs"] = "", 
      ["wlan_show_in_monitor"] = "0", 
      ["wlan_station_type"] = ""
    }, 
    [2] = {
      ["UID"] = "landevice6061", 
      ["_node"] = "landevice4", 
      ["active"] = "0", 
      ["auto_wakeup"] = "0", 
      ["deleteable"] = "2", 
      ["dhcp"] = "1", 
      ["ethernet"] = "1", 
      ["ethernet_port"] = "1", 
      ["guest"] = "0", 
      ["ip"] = "192.168.0.23", 
      ["ipv6_ifid"] = "", 
      ["mac"] = "XX:XX:XX:XX:XX:XX", 
      ["manu_name"] = "0", 
      ["name"] = "Hans-PC", 
      ["online"] = "0", 
      ["parentname"] = "", 
      ["parentuid"] = "", 
      ["plc"] = "0", 
      ["source"] = "0x1004", 
      ["speed"] = "0", 
      ["static_dhcp"] = "0", 
      ["url"] = "", 
      ["vendorname"] = "MSFT 5.0", 
      ["wakeup"] = "0", 
      ["wlan"] = "0", 
      ["wlan_UIDs"] = "", 
      ["wlan_show_in_monitor"] = "0", 
      ["wlan_station_type"] = ""
    },
}, ...

Mit einem Problem habe ich im Augenblick noch zu kämpfen, evtl. habt ihr dazu noch ein paar Tipps für mich. Und zwar möchte ich, dass über Freetz das NAS auch heruntergefahren werden kann. Dazu habe ich ein BASH Skript auf dem NAS generiert. Das Skript soll nun per SSH von Freetz ausgeführt werden:

ssh myUser@NAS sudo sh myShutdownSkript.sh

Dabei möchte ich natürlich keine Passwortabfrage durch ssh erhalten. Daher soll das ganze über einen RSA Key erfolgen. Leider habe ich es bis jetzt nicht zum laufen gebracht. Evtl. habe ich dabei etwas falsch verstanden.
Hier meine Vorgehensweise:
1. Auf NAS RSA Key mit dem User myUser generiert:
# ssh-keygen
2. Public Key auf FB kopiert:
# scp .ssh/id_rsa.pub root@fritzbox
3. Auf Fritzbox den Public Key zu den Authorized Keys hinzugefügt
# cd $Home
# cat id_rsa.pub >> .ssh/authorized_keys
4. Auf der FB versucht auf das NAS zu verbinden
# ssh myUser@NAS

Und hier kommt immernoch die Abfrage. Was habe ich falsch gemacht? Muss ich auf der FB die Keys generieren und auf das NAS kopieren? Wenn ja, wie? ssh-keygen ist bei Freetz nicht verfügbar.

Gruß Roadrunner86

 

[hermann72pb]

Ich würde dir stattdessen eine etwas elegantere Methode vorschlagen. Schau hier bitte nach meinem HOL-Paket. Irgendwo im Thread dazu gab es ein Beispiel, wie man unter Linux (wohl gemerkt mit Shell-Mitteln!) einen "HOL-Server" zum Laufen bringen kann. Wenn du es schaffst (und das dürfte funktionieren, weil von mir damals ausprobiert), dann brauchst du weder su noch keys und ssh.

Edit: Und noch eine Bemerkung am Rande (sorry, kann mich nicht zusammenreißen): Du hast eine falsche NAS, wenn du sie runterfahren muss. Meine QNAP verbraucht im StandBy kaum mehr als 6 Watt. Und in diesen StandBy geht sie voll automatisch, wenn bei den Festplatten Ruhe einkehrt.

Edit2:
http://www.ip-phone-forum.de/showthread.php?t=211366

MfG

 

[Roadrunner86]

Danke für den Tipp! Werde ich mal probieren. Der nächste Schritte wäre dann noch ein Webinterface dazu. Aber da melde ich mich dann nochaml

Zu deiner Bemkerung, die kann ich voll und ganz verstehen, aber bei mir ist das eine etwas andere Konstellation. Ich habe als Hardware einen HP Proliant Microserver N54l im Einsatz. Auf dem läuft Xpenology (http://xpenology.com/) Das ist quasi das OS, welches auf den Synology NASen läuft. Der GPL sei dank, gibt's das frei zugänglich.
In Idle Modus braucht das NAS ca. 30W, was ja bei NASen ähnlicher Leistungsklasse ganz gewöhnlich ist.

 

[hermann72pb]

Ich bleibe bei meiner Meinung: Dein HP-Rechner ist keine NAS, sondern ein PC. Darum hast du eine falsche NAS. Die richtigen NAS sind dafür ausgelegt NAS zu sein, haben keine Grafikkarten und sind daher keine Stromfresser mit AMD-Prozessoren. Meine alte QNAP hatte ich damals genau darum ausgewählt, weil sie wenig Strom im Idle verbraucht und einen sehr guten Durchsatz im Netzwerkverkehr hatte. Mehr braucht eine NAS meiner Meinung nach nicht.

MfG

 

[RalfFriedl]

1. ctlmgr_ctl weder liest aus noch schreibt in ar7.cfg, sondern in eine "interne Datenbank". Dies erkennt man dadurch, dass die Änderungen nicht sofort in ar7.cfg auftauchen
2. AVM Webinterface benutzt nicht ctlmgr_ctl, sondern ctlmgr direkt. Bzw. ctlmgr ist seit langem "AVM Webinterface". Das ist ein wesentlicher Unterschied. Damit sind deutlich tiefgründige Änderungen in der "internen Datenbank" möglich.

Das Programm ctlmgr_ctl ist ein einfaches Frontend, das XML Anfragen an den ctlmgr schickt, eine XML Antwort bekommt, und daraus einen Teil ausgibt, sofern es eine lesende Anfrage war. Es gibt keinen Grund für AVM, ctlmgr_ctl aufzurufen, wenn sie die gleiche Funktion in einer Library haben können, die keinen externen Aufruf benötigt. Das gleiche können wir auch machen, wenn wir das genaue Format der benötigten XML Nachricht kennen.

 

[hermann72pb]

Ja, Ralf, weiß ich. Vielleicht hatte ich mich falsch ausgedrückt.
Und ja, wir können es und wir wissen sogar, wie die Nachrichten aussehen. Es findet sich bloß keiner, der sich dieses Thema wirklich ernsthaft annimmt und in C ein Programm dafür schreibt.
Wie gesagt, ich hatte mal angefangen da etwas nachzuforschen und hatte auch Einiges rausgefunden. Der weitere Schritt war aber mir zu aufwendig und ich hatte es mangels Zeit sein gelassen. Ich hatte mal versucht über LUA dran zu gelangen, um nicht gleich in C zu programmieren. Auch das ist im Sande verlaufen. Es ist ja alles machbar und "knackbar", allerdings erfordert diese Thematik sehr viel Zeit, Fleiß und Geduld. Und das habe ich momentan leider nicht.

MfG

 

[RalfFriedl]

Ich gehe davon aus, dass Du des weißt, aber es lesen hier auch andere mit. Vielleicht findet sich einer, der das machen will.
Wobei die Frage ist, was ein eigenständiges C Programm machen soll, was ctlmgr_ctl nicht schon kann.

 

[hermann72pb]

Hier eine Auflistung nach meinen Beobachtungen damals:
- ctlmgr_ctl kann z.B. nicht mehrere Daten "in einem Aufwasch" lesen oder ausgeben. Stichwort "Array-Operationen", oder wie man es auch immer besser bezeichnen könnte. Bei LUA-Auszügen aus AVM-WebIF sieht man, dass dort viel mehr und viel bequemer geht, als wir es mit ctlmg_ctl kennen
- ctlmgr_ctl ist ein Parser und arbeitet nur die commandos ab, die er kennt. Man sieht es, wenn man die ASCII-Ketten von dem Binary betrachtet. Also, es wird nur eine bestimmte Anzahl der commandos zugelassen. Und das sind vom Weiten nicht alle
- Fehlermanagement von ctlmgr_ctl ist eine Katastrophe. Das wissen wir hier alle. Sprich, man setzt einen Befehl ab und weiß nicht, ob es gefruchtet hat oder nicht. Klar, kann man sich viel drum-herum aufbauen, um es zu kontrollieren. Der Aufwand dafür ist aber sehr groß
- Man weiß nicht so ganz, wann die Syncronisierung zwischen ar7.cfg und Co. und der Datenbank stattfindet. Ich habe eine leise Vermutung, dass AVM es irgendwie beeinflüssen können und der richtige ctlmgr sowas auch anstoßen kann

Worauf basieren all diese meinen Punkte:
a) Ich hatte mal das Thema 2.PVC und dynamic-DNS hier ausgiebig untersucht. Man kann mit ctlmgr_ctl einen zweiten Eintrag für z.B. zweite PVC oder einen anderen Dynamic-DNS-Anbieter anlegen. Dieser wird dann vom internen DynDNS-Klient von AVM "mitbedient". Sobald man es geschafft hat, funktioniert es auch. Sogar Jahrelang. Aber der Weg dahin ist sehr steinig. Mit ctlmgr_ctl muss man die Reihenfolge der commandos beim Anlegen akribisch verfolgen. Macht man irgendwas falsch, klappt es nicht. Wir denken, dass wir eine richtige Reihenfolge rausgefunden hatten, bestätigt ist es aber noch nicht. Hierbei war übrigens aufgefallen, dass die Einträge erst sehr spät in ar7.cfg auftauchen. Der Zeitpunkt war uns auch nicht ganz klar
b) Bei meinen Versuchen mit dem DHCP-Klient von AVM hatte ich auch vergeblich versucht die ganze Liste mit den ganzen Einträgen wenigstens auszulesen. Bei 10-20 Rechner grenzt es schon fast am Wahnsinn, wenn man es mit ctlmgr_ctl Parameter für Parameter macht. Über LUA kriegen die AVMs es deutlich schneller und auf einen Wisch. Vom Schreiben schweige ich ganz und gar. Da bin ich wirklich an einigen Stellen an die Grenzen von ctlmgr_ctl gestoßen

Zu dem Thema, was so ein C-Programm machen soll, hast du Recht. Man sollte zuerst wissen, was man genau will. Die DHCP-Anwendung wäre z.B. ein Fall. Aber dort druckt der Schuh nicht allsoviel, bzw. Interesse beide Listen (von AVM und von dnsmasq) zu synchronisieren ist nicht so hoch hier. Beim Thema 2.PVC sieht es ähnlich aus. Der Aufwand war mir jedesmal zu hoch, das Ding anzupacken, um ein vergleichbar kleines Problem damit zu lösen.

MfG

 

[koyaanisqatsi]

Morgen

Wenn ich das alles so lese, dann halte ich LUA für den geeignetsten Weg, auch weil LUA für C-Programmierer keine Hürde darstellen sollte.
Aussen vor bleiben dann allerdings ungefreetze ältere Boxen/Firmwares ohne LUA Unterstützung.

Leider hab ich keinen Plan von ctlmgr, der mir in meiner Naivität wie ein Severdienst vorkommt, der wohl irgendwelche Anfragen beantwortet, oder ausführt.
Mit XML kann ich allerdings umgehen.
Sogar wohlgeformt: XML. DTD und XSL wenns sein muss.

 

[hermann72pb]

Wo willst du denn XML anwenden, bzw. wo siehst du es, dass die AVMs XML anwenden? Bei ar7.cfg und bei den LUA-Aufrufen im WebIF sieht es zwar danach, ob es dann aber wirklich XML ist, kann ich nicht beurteilen. Bin an der Stelle nicht vom Fach. Meine Vermutung ist allerdings, dass AVM sich da wie immer an XML angelehnt hat, letztendlich aber wie immer ihr eigenes Suppchen kocht.
Zu LUA gebe ich dir Recht koy. Aber wie gesagt, da hat mir die Ausdauer gefällt. Wir hatten angefangen den allgemeinen LUA-Interpreter dazu zu ertüchtigen, dass man eigene LUA-Programme schreiben könnte, sind aber dabei gescheitert, weil wir die AVM-Bibliothek nicht anbinden konnten, die dafür entscheidend ist.
Der AVM-eigene LUA-Interpreter ist aber leider in den ctlmgr integriert und kann nur als CGI laufen, nicht aus Kommando-Zeile. Zumindest war es uns nicht gelungen, den dazu zu ertüchtigen. Und CGI in ctlmgr-Ummantelung ist nicht unbedingt das, was wir wirklich in FREETZ brauchen. Denn damit kannst du höchstens LUA-Skripte für AVM-WebIF und innerhalb von AVM-WebIF schreiben und ausführen.

Also, grab bitte den alten Thread von mir hier heraus und forsche da weiter. Vielleicht gelingt dir dann bald der Durchbruch. Ich hatte damals den Interpreter auch nicht selbst kompiliert. Mir wurde schon hier dabei geholfen, Bibliotheken für Crosskompiling besser einzubinden. Von daher wirst du damit auch nicht Einzelkämpfer sein, wenn du über deine Schritte hier ausführlich informierst.

MfG

 

[koyaanisqatsi]

Naja,
die ar7.cfg z.B. die Definitionen die da drinne stehen sehen für mich nach Klassen aus.
Der Aufbau ist immer derselbe:
KlassenName {
ErstesElement = "Wert1";
ZweitesElement = "Wert2";
...
}

XML würde so aussehen:

<RootElement>
<ErstesElement>Wert1</ErstesElement>
<ZweitesElement>Wert2</ZweitesElement>
</RootElement>

Der Vorteil bei XML ist,
der Transformator oder das Stylesheet (XSL) braucht Root-, und/oder Elternelemte nicht Namentlich zu kennen,
weil XPath mit Array Befehlen arbeiten kann (foreach zum Beispiel).
Allerdings sind die XML-Parser in Geräten äusserst proprietär, sie kochen ihr eigenes Süppchen.
Zum Beispiel beim snom 320: XSL, also die transformation, findet im Gerät statt.
Alles ist da hardgecodet, vom Namen der/des Rootelements über die Elemente selber bis hin zu den Attributen.
Zumindest dokumentieren die das wenigstens, sonst könnte man damit garnichts anfangen.

EDIT: Das (gepatchte?) AVM LUA macht das rauslesen übrigens so: if box.query("telcfg:settings/ShowPSTN") == "0" then ....
...oder so:
UsePstn = box.query("telcfg:settings/UsePSTN")

 

[RalfFriedl]

Es wäre kein Problem, ein Programm ähnlich wie ctlmgr_ctl zu erstellen, das eine XML Datei als Eingabe liest und die XML Antwort ausgibt. Damit könnte man alles machen, was die Schnittstelle hergibt, man müsste nur die XML Verarbeitung selbst machen.
Man könnte auch ein Programm machen, dass den Rahmen des Aufrufs automatisch generiert, darin die eingelesene XML Anforderung einpackt, und aus der XML Antwort den wichtigen Teil ausgibt.

@koyaanisqatsi
Dass, was zwischen ctlmgr_ctl und ctlmgr gesendet wird, sieht nach XML aus und hat nichts mit dem zu tun, was in ar7.cfg steht.

 

[hermann72pb]

Ich glaube, wir sind vom eigentlichen Thema hier etwas abgedrifftet. Ich würde empfehlen dazu einen eigenen Thread aufzusetzen oder sich einem der vielen anhängen, die ich schon mal zum Thema angelegt hatte. Sonst findet man diese Diskussion unter dem jetzigen Threadnamen nicht mehr wieder. Aber einer muss sagen "ja, ich mach es". Sonst macht es wenig Sinn, es durchzukauen.

MfG