Das Dienstprogramm ng-upnp2mrtg zur Abfrage von Byte-Countern in UPNP-Routern ist nun in Version 0.2.3 verfügbar.
Neu in dieser Version ist die Option --nowrap
Beim Neuaufbau von Verbindungen (z.B. nach einer Zwangstrennung) setzen Modems häufig die Empfangs- und Sende-Zählerstände auf Null zurück. MRTG interpretiert dies als 32-Bit-Zählerüberlauf, was in der grafischen Darstellung zu einer Spitze führt. Diese lässt sich auch durch andere MRTG-Optionen nicht sicher verhindern.
Wenn diese ng-upnp2mrtg-Option gesetzt ist, werden die Zählerstände vom Skript zwischengespeichert und nach einem Reset als Offset bei allen nachfolgenden Ausgaben hinzuaddiert.
Ohne diese Spitzen kann die Funktion zur automatischen Skalierung wieder richtig arbeiten.
Posts mit dem Label UPnP werden angezeigt. Alle Posts anzeigen
Posts mit dem Label UPnP werden angezeigt. Alle Posts anzeigen
Samstag, 6. Juni 2009
Montag, 20. April 2009
UPnP – Entdeckungsreise... zu Fuß
Für die im Folgenden beschrieben Abläufe gibt es sicher spezialisierte Programme. Das Ziel war aber ein kurzes Skript, das von mrtg aufgerufen werden soll. Hierzu ist nur die Kenntnis einer Handvoll Strings notwendig, die in das Skript integriert werden müssen.
Auch will ich hier nicht das UPnP-Protokoll vollständig wiedergeben. Vielmehr werden nur die Teile vorgestellt, die zur Abfrage von Werten (z.B. der Anzahl der übertragenen Bytes) benötigt werden.
Mit diesen Kenntnissen sollte sich ng-upnp2mrtg eigentlich an alle UPnP-Modems, die die UPnP-Abfrage unterstützen anpassen lassen.
Die eigentliche Abfrage
Nachdem eine TCP-Verbindung zum UPnP-Server im Modem aufgebaut ist, erfolgt die Kommunikation nach dem HTTP-Protokoll.
Schauen wir uns eine typische Abfrage an.
Der Client sendet:
Natürlich müssen auch die Werte für HOST und CONTENT-LENGTH angepasst werden. Sie haben die im HTTP-Protokoll definierten Bedeutungen und sind selbsterklärend.
Die variablen Teile in der XML-Nachricht kennen wir schon aus dem Header.
In der gleich TCP-Verbindung liefert der Server seine Antwort. Hier wieder ein typisches Beispiel:
Der Ergebniscode hat die bei HTTP definierte Bedeutung – kurz gesagt: 200 ist ok, bei allen anderen Werten muss man nachforschen.
Um also eine bestimmte Information abzufragen braucht man:
Der Weg in den Router
Glücklicherweise werden diese Informationen – und noch einige mehr – vom UPnP-Server per UDP-Broadcast verbreitet. Standardmäßig wird dieser Broadcast an die IP-Adresse 239.255.255.250. Port 1900 gerichtet. Das Protokoll heißt SSDP (Simple Service Discovery Protocol).
Die Pakete kann man z.B. mit Wireshark auffangen und decodieren. Grenzen Sie ggf. die Anzeige mit 'ip.addr == a.b.c.d' auf die IP des Routers ein.
Lassen Sie sich Zeit. Es kann einige Minuten dauern, bis die ersten SSDP-Pakete angezeigt werden. Untersuchen Sie den Text-Inhalt. Nach einiger Zeit wird dieser sich wiederholen, Sie sollten aber mehrere unterschiedliche Pakete finden.
Hier der Textinhalt eines solchen Pakets
Der nächste Schritt ist, die URL aus LOCATION in den Browser einzugeben. Ergebnis ist eine weitere XML-Datei. (Wenn Sie hierzu Firefox verwenden, wird die Datei übersichtlich formatiert dargestellt.) Interessant sind die Einträge unter <serviceList>, die an mehreren Stellen und in unterschiedlichen Ebenen im XML-Baum auftreten können:
Hier ein Beispiel:
Unterhalb von <serviceList> findet man diverse Dienste mit <service> aufgelistet.
In dieser XML-Datei findet sich unter <actionList> ein oder mehrere Einträge <action>. Eine Ebene tiefer finden sich <name> und die <argumentList> mit einem oder mehreren <argument> Einträgen. Und bei <argument> interessieren wir uns vor allem für <name> und <direction>.
Prinzipieller Aufbau:
Die Namen der Tags sind selbsterklärend. Interessant für eine Abfrage sind natürlich nur die Aktionen mit der <direction> out.
Zum Abschluss
Die Stellen in ng-upnp2mrtg, an denen diese Werte eingetragen werden müssen, sind im Quelltext einfach zu finden.
Die Byte-Counter befinden sich meist in einer Aktion, die als Antwort die Tags „NewTotalBytesReceived“ und „NewTotalBytesReceived“ zurück gibt. Für die Verbindungsdauer sucht man am besten nach „NewUpTime“. Alle Werte werden bei einem Verbindungsaufbau zurückgesetzt, was bei MRTG leider einen Spike erzeugt.
Auch will ich hier nicht das UPnP-Protokoll vollständig wiedergeben. Vielmehr werden nur die Teile vorgestellt, die zur Abfrage von Werten (z.B. der Anzahl der übertragenen Bytes) benötigt werden.
Mit diesen Kenntnissen sollte sich ng-upnp2mrtg eigentlich an alle UPnP-Modems, die die UPnP-Abfrage unterstützen anpassen lassen.
Die eigentliche Abfrage
Nachdem eine TCP-Verbindung zum UPnP-Server im Modem aufgebaut ist, erfolgt die Kommunikation nach dem HTTP-Protokoll.
Schauen wir uns eine typische Abfrage an.
Der Client sendet:
POST /WANCommonInterfaceConfigService/control HTTP/1.0
HOST: 192.168.0.1:49300
CONTENT-LENGTH: 340
CONTENT-TYPE: text/xml; charset="utf-8"
SOAPACTION: "urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1#GetTotalBytesReceived"
<?xml version="1.0"?>
<s:Envelope
xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<s:Body>
<u:GetTotalBytesReceived xmlns:u="urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1">
</u:GetTotalBytesReceived>
</s:Body>
</s:Envelope>
- Die erste Zeile ist ein HTTP-Befehl (eine Methode, gefolgt von einer URL, gefolgt von der Protokollversion).
- Ihr folgen einige Header-Zeilen in der Form 'Schlüssel: Wert'.
- Eine Leerzeile trennt den Header von der eigentlichen Nachricht.
- Diese liegt im XML-Format vor (SOAP).
Natürlich müssen auch die Werte für HOST und CONTENT-LENGTH angepasst werden. Sie haben die im HTTP-Protokoll definierten Bedeutungen und sind selbsterklärend.
Die variablen Teile in der XML-Nachricht kennen wir schon aus dem Header.
In der gleich TCP-Verbindung liefert der Server seine Antwort. Hier wieder ein typisches Beispiel:
HTTP/1.1 200 OKMan erkennt eine Standard-HTTP-Antwort, mit dem HTTP-Ergebniscode in Zeile 1, weitere Headerzeilen, die unvermeidliche Leerzeile, gefolgt von Text, wieder im XML-Format. Im <u>-Tag selbst findet man wieder die Werte für Aktion und Dienst-Bezeichner. Der <u>-Tag umschließt die gewünschten Information, die ihrerseits von <tag> ...</tag> eingeschlossen sind.
EXT:
CONTENT-TYPE: text/xml; charset="utf-8"
SERVER: IAD, UPnP/1.0, MicroStack v1.0.2777
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body>
<u:GetStatusInfoResponse xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
<NewConnectionStatus>Connected</NewConnectionStatus>
<NewLastConnectionError>ERROR_NONE</NewLastConnectionError>
<NewUptime>30864</NewUptime>
</u:GetStatusInfoResponse>
</s:Body>
</s:Envelope>
Der Ergebniscode hat die bei HTTP definierte Bedeutung – kurz gesagt: 200 ist ok, bei allen anderen Werten muss man nachforschen.
Um also eine bestimmte Information abzufragen braucht man:
- IP-Adresse und Port-Nummer des UPnP-Servers
- die URL
- den Bezeichner für den Dienst bzw. das Gerät und die Aktion
- sowie den Namen des Tags, in dem in der Antwort die gewünschte Information steht.
Der Weg in den Router
Glücklicherweise werden diese Informationen – und noch einige mehr – vom UPnP-Server per UDP-Broadcast verbreitet. Standardmäßig wird dieser Broadcast an die IP-Adresse 239.255.255.250. Port 1900 gerichtet. Das Protokoll heißt SSDP (Simple Service Discovery Protocol).
Die Pakete kann man z.B. mit Wireshark auffangen und decodieren. Grenzen Sie ggf. die Anzeige mit 'ip.addr == a.b.c.d' auf die IP des Routers ein.
Lassen Sie sich Zeit. Es kann einige Minuten dauern, bis die ersten SSDP-Pakete angezeigt werden. Untersuchen Sie den Text-Inhalt. Nach einiger Zeit wird dieser sich wiederholen, Sie sollten aber mehrere unterschiedliche Pakete finden.
Hier der Textinhalt eines solchen Pakets
NOTIFY * HTTP/1.1Auch hier erkennt man wieder die HTTP-Struktur: eine Methode (NOTIFY), eine URL (*) (naja) und die Protokollversion, gefolgt von UPnP-Headern, die diverse nützliche Informationen enthalten.
HOST: 239.255.255.250:1900
LOCATION: http://192.168.0.99:49000/igddesc.xml
SERVER: mynet UPnP/1.0 AVM FRITZ!Box WLAN 3170 49.04.57
CACHE-CONTROL: max-age=1800
NT: urn:schemas-upnp-org:device:InternetGatewayDevice:1
NTS: ssdp:alive
USN: uuid:75802409-bccb-40e7-8e6c-001C4A50656D::urn:schemas-upnp-org:device:InternetGatewayDevice:1
- LOCATION: eine URL mit einer XML-Datei, die die Dienste weiter beschreibt.
- NT: den „Dienst-Bezeichner“
- NTS: ssdp:alive = das Geräte meldet sich an; ssdp:byebye = das Gerät meldet sich ab
- USN: nochmal der Name des Diensts, diesmal mit einer eindeutigen ID, die von Gerät zu Gerät unterschiedlich ist, auch wenn die Dienstnamen identisch sind.
Der nächste Schritt ist, die URL aus LOCATION in den Browser einzugeben. Ergebnis ist eine weitere XML-Datei. (Wenn Sie hierzu Firefox verwenden, wird die Datei übersichtlich formatiert dargestellt.) Interessant sind die Einträge unter <serviceList>, die an mehreren Stellen und in unterschiedlichen Ebenen im XML-Baum auftreten können:
Hier ein Beispiel:
...
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType>
<serviceId>urn:upnp-org:serviceId:WANCommonIFC1</serviceId>
<SCPDURL>WANCommonInterfaceConfigService/scpd.xml</SCPDURL>
<controlURL>WANCommonInterfaceConfigService/control</controlURL>
...
</service>
...
</serviceList>
Unterhalb von <serviceList> findet man diverse Dienste mit <service> aufgelistet.
- Der <serviceType> ist der Dienst-Bezeichner, den wir in der UPnP-Abfrage brauchen.
- Die <controlURL> ist die URL für die UPnP-Abfrage (ohne vorangestellten Backslash).
- <SCPDURL> verweist auf eine weitere XML-Datei, die die Aktionen näher beschreibt.
In dieser XML-Datei findet sich unter <actionList> ein oder mehrere Einträge <action>. Eine Ebene tiefer finden sich <name> und die <argumentList> mit einem oder mehreren <argument> Einträgen. Und bei <argument> interessieren wir uns vor allem für <name> und <direction>.
Prinzipieller Aufbau:
<scpd>
...
<actionList>
<action>
<name>Name_der_Aktion</name>
<argumentList>
<argument>
<name>ArgumentName_1</name>
<direction>in</direction>
</argument>
<argument>
<name>ArgumentName_2</name>
<direction>out</direction>
</argument>
...
</argumentList>
</action>
...
</actionList>
</scpd>
Die Namen der Tags sind selbsterklärend. Interessant für eine Abfrage sind natürlich nur die Aktionen mit der <direction> out.
- Der Name der <action> ist der Aktionsname für unsere Abfrage.
- Der Name bei <argument> ist der Name des Tags bei der Antwort, der den entsprechenden Wert einklammert.
Zum Abschluss
Die Stellen in ng-upnp2mrtg, an denen diese Werte eingetragen werden müssen, sind im Quelltext einfach zu finden.
Die Byte-Counter befinden sich meist in einer Aktion, die als Antwort die Tags „NewTotalBytesReceived“ und „NewTotalBytesReceived“ zurück gibt. Für die Verbindungsdauer sucht man am besten nach „NewUpTime“. Alle Werte werden bei einem Verbindungsaufbau zurückgesetzt, was bei MRTG leider einen Spike erzeugt.
Mittwoch, 15. April 2009
ng-upnp2mrtg nun auf SourceForge
Das Projekt ng-upnp2mrtg wird ab heute auf SourceForge gehosted.
Neuere Versionen sind künftig dort erhältlich.
Neuere Versionen sind künftig dort erhältlich.
Donnerstag, 2. April 2009
NetCologne Premium-Modem und die Statusabfrage via UPnP
Sysadmins lieben schöne Bilder. Durch die grafische Darstellung des zeitlichen Verlaufs von Systemvariablen wie dem Durchsatz einer Internet-Verbindung oder der Temperaturen von Festplatten, fallen Veränderungen gegenüber der Norm meist recht schnell auf.
Ein dafür sehr gern eingesetztes Werkzeug ist das Round Robin Database Tool (RRDtool) von Tobias Oetiker und der speziell für den Einsatz in Netzwerken angepasste Multi Router Traffic Grapher MRTG vom gleichen Author.
MRTG beherrscht SNMP, das Protokoll mit dem sich bei industriell eingesetzten Netzwerkgeräten Statusmeldungen, wie eben die übertragene Datenmenge, abfragen lassen. Router für Endkunden besitzen diese Option meist nicht. Dafür beherrschen diese zunehmend UPnP (Universal Plug and Play). Dieser Standard wurde entwickelt, damit z.B. die Internet-fähige Stereoanlage den Internet-Router für ihre Bedürfnissen konfigurieren kann.
Was die Internet-fähige Stereoanlage kann, können aber auch Schadprogramme, die den Router dann z.B. so programmieren können, dass der Rechner direkt von außen erreichbar wird. Deshalb ist diese Option bei den meisten sicherheitsbewussten Anwendern ausgeschaltet.
Neben der Programmierung eines Routers sieht UPnP aber auch die Möglichkeit der Statusabfrage vor. Leider kann MRTG Daten nicht direkt über UPnP abfragen. In der Konfigurationsdatei /etc/mrtg.cfg kann jedoch unter Target[XXX] statt einer SNMP-OID ein Programm angegeben werden, das von MRTG aufgerufen wird, um die Daten zu ermitteln und an MRTG weiterzureichen (siehe auch „man mrtg-reference“). Für die weit verbreiteten Router der Marke FritzBox kommt hier meist upnp2mrtg zum Einsatz.
Vorbereitungen beim NetCologne-Router Premium
Bei diesem NetCologne-Router kann im Expertenmodus über „Sicherheit – UPnP“ getrennt eingestellt werden, ob UPnP zur Programmierung von Portweiterleitungen und/oder (nur) zur Statusabfrage eingesetzt wird. Hier muss die UPnP-Abfrage freigeschaltet (und die UPnP-Steuerung sollte aus den oben genannten Gründe deaktiviert) werden.
Bei gleicher Gelegenheit sollte man mit „System – Zugangsschutz“ ein Passwort für die Web-Schnittstelle definieren – standardmäßig ist leider kein Passwort definiert.
Probleme bei der Abfrage mit upnp2mrtg
Leider schlägt der Aufruf von upnp2mrtg fehl. Die Standardwerte für HOST („firtz.box“) und PORT (49000) passen nicht zur NetCologne-Box.
Der HOST beim NetCologne-Router heißt „netconnect.box“ (oder man verwendet die entsprechende IP-Adresse, standardmäßig wird „192.168.0.1“ verwendet).
Port 49000 ist beim NetCologne-Router jedoch geschlossen. Ein Port-Scan zeigt, dass Port 49300 offen ist (dieser Wert liegt zumindest in der Nähe von 49000).
Jeses UPnP-Gerät sendet aber auch sog. SSDP-Notify-Pakete, um sich bekannt zu machen. Mit Wireshark können diese Pakete aufgezeichnet und analysiert werden:
Der Inhalt dieser Pakete bestätigt Port 49300 als UPnP-Port. Aber der entsprechend modifizierte Aufruf von upnp2mrtg:
sudo upnp2mrtg -a netconnect.box -p 49300
liefert kein Ergebnis.
Der Grund hierfür – so fand ich bei der Programmierung des Tools ng-upnp2mrtg heraus – liegt darin, dass der NetCologne-Router auf CR LF als Zeilenende-Zeichen besteht – die FritzBox begnügt sich auch mit dem Unix-Standardwert LF.
Unterschiede ng-upnp2mrtg.py / upnp2mrtg
upnp2mrtg ist ein Bash-Script, während ng-upnp2mrtg.py ein Python-Script ist. Python ist heutzutage auf jedem Linux-System standardmäßig installiert. Das ng-Script ist genügsam und nutzt nur die Python-Standardbibliotheken.
Wie in einem der nächsten Blog-Postings gezeigt braucht man zur Abfrage eines bestimmten Router-Werts nur vier Parameter. Diese scheinen sich von Router zu Router geringfügig zu unterscheiden. Hat man diese Information erst einmal ermittelt, lässt sich das Python-Programm leicht an andere Geräte anpassen. Sollten Sie das Programm mit anderen Router-Typen erfolgreich einsetzen, lassen Sie es mich wissen.
Die jetzige Version des Skripts ng-upnp2mrtg enthält neben den Parametern für den NetCologne-Router auch die für eine Fritzbox. Mangels Internetverbindung über eine FritzBox kann ich sie leider nicht testen. Die Auswahl erfolgt zurzeit noch durch ein- und auskommentieren am Ende des Skripts.
ng-upnp2mrtg - Was Sie brauchen
mrtg: Dieses Programm sollte über die Repositories Ihrer Distribution erhältlich sein. Ansonsten finden Sie es hier.
ng-upnp2mrtg.py: Das Skript läuft unter Python, was heute auf jedem Linux-System installiert sein sollte, und braucht keine besonderen Bibliotheken. Im Augenblick ist es hier abrufbar.
mrtg.cfg: Konfigurationsdatei für mrtg angepasst an ng-upnp2mrtg.py, Im Augenblick hier zu bekommen.
Ich werde versuchen das Skript bei einem der OpenSource-Projekt-Sites als Projekt anzumelden. Die Dateien und neuere Versionen werden dann dort abrufbar sein.
Installation von ng-upnp2mrtg
Für die folgenden Schritte brauchen Sie Root-Rechte:
Passen Sie oben im Skript ng-upnp2mrtg.py die Variablen HOST und PORT an.
Kopieren Sie das Skript nach /usr/local/bin und machen Sie es ausführbar
Die Konfigurationsdatei mrtg.cfg kommt nach /etc.
cp -a ng-upnp2mrtg.py /usr/local/bin
chmod 755 /usr/local/bin/ng-upnp2mrtg.py
cp -a mrtg.cfg /etc
Für den regelmäßige Aufruf von mrtg sorgt der folgende crontab-Eintrag:
0-59/5 * * * * env LANG=C /usr/bin/mrtg --logging /var/log/mrtg.log
Das Ganze wurde getestet mit Ubuntu 8.04, mrtg 2.14.7, Python 2.5.2.
Schwierigkeiten bei der Übernahme auf andere System sind eigentlich nicht zu erwarten... aber das sagt man ja vorher immer.
Ein dafür sehr gern eingesetztes Werkzeug ist das Round Robin Database Tool (RRDtool) von Tobias Oetiker und der speziell für den Einsatz in Netzwerken angepasste Multi Router Traffic Grapher MRTG vom gleichen Author.
MRTG beherrscht SNMP, das Protokoll mit dem sich bei industriell eingesetzten Netzwerkgeräten Statusmeldungen, wie eben die übertragene Datenmenge, abfragen lassen. Router für Endkunden besitzen diese Option meist nicht. Dafür beherrschen diese zunehmend UPnP (Universal Plug and Play). Dieser Standard wurde entwickelt, damit z.B. die Internet-fähige Stereoanlage den Internet-Router für ihre Bedürfnissen konfigurieren kann.
Was die Internet-fähige Stereoanlage kann, können aber auch Schadprogramme, die den Router dann z.B. so programmieren können, dass der Rechner direkt von außen erreichbar wird. Deshalb ist diese Option bei den meisten sicherheitsbewussten Anwendern ausgeschaltet.
Neben der Programmierung eines Routers sieht UPnP aber auch die Möglichkeit der Statusabfrage vor. Leider kann MRTG Daten nicht direkt über UPnP abfragen. In der Konfigurationsdatei /etc/mrtg.cfg kann jedoch unter Target[XXX] statt einer SNMP-OID ein Programm angegeben werden, das von MRTG aufgerufen wird, um die Daten zu ermitteln und an MRTG weiterzureichen (siehe auch „man mrtg-reference“). Für die weit verbreiteten Router der Marke FritzBox kommt hier meist upnp2mrtg zum Einsatz.
Vorbereitungen beim NetCologne-Router Premium
Bei diesem NetCologne-Router kann im Expertenmodus über „Sicherheit – UPnP“ getrennt eingestellt werden, ob UPnP zur Programmierung von Portweiterleitungen und/oder (nur) zur Statusabfrage eingesetzt wird. Hier muss die UPnP-Abfrage freigeschaltet (und die UPnP-Steuerung sollte aus den oben genannten Gründe deaktiviert) werden.
Bei gleicher Gelegenheit sollte man mit „System – Zugangsschutz“ ein Passwort für die Web-Schnittstelle definieren – standardmäßig ist leider kein Passwort definiert.
Probleme bei der Abfrage mit upnp2mrtg
Leider schlägt der Aufruf von upnp2mrtg fehl. Die Standardwerte für HOST („firtz.box“) und PORT (49000) passen nicht zur NetCologne-Box.
Der HOST beim NetCologne-Router heißt „netconnect.box“ (oder man verwendet die entsprechende IP-Adresse, standardmäßig wird „192.168.0.1“ verwendet).
Port 49000 ist beim NetCologne-Router jedoch geschlossen. Ein Port-Scan zeigt, dass Port 49300 offen ist (dieser Wert liegt zumindest in der Nähe von 49000).
Jeses UPnP-Gerät sendet aber auch sog. SSDP-Notify-Pakete, um sich bekannt zu machen. Mit Wireshark können diese Pakete aufgezeichnet und analysiert werden:
Der Inhalt dieser Pakete bestätigt Port 49300 als UPnP-Port. Aber der entsprechend modifizierte Aufruf von upnp2mrtg:
sudo upnp2mrtg -a netconnect.box -p 49300
liefert kein Ergebnis.
Der Grund hierfür – so fand ich bei der Programmierung des Tools ng-upnp2mrtg heraus – liegt darin, dass der NetCologne-Router auf CR LF als Zeilenende-Zeichen besteht – die FritzBox begnügt sich auch mit dem Unix-Standardwert LF.
Unterschiede ng-upnp2mrtg.py / upnp2mrtg
upnp2mrtg ist ein Bash-Script, während ng-upnp2mrtg.py ein Python-Script ist. Python ist heutzutage auf jedem Linux-System standardmäßig installiert. Das ng-Script ist genügsam und nutzt nur die Python-Standardbibliotheken.
Wie in einem der nächsten Blog-Postings gezeigt braucht man zur Abfrage eines bestimmten Router-Werts nur vier Parameter. Diese scheinen sich von Router zu Router geringfügig zu unterscheiden. Hat man diese Information erst einmal ermittelt, lässt sich das Python-Programm leicht an andere Geräte anpassen. Sollten Sie das Programm mit anderen Router-Typen erfolgreich einsetzen, lassen Sie es mich wissen.
Die jetzige Version des Skripts ng-upnp2mrtg enthält neben den Parametern für den NetCologne-Router auch die für eine Fritzbox. Mangels Internetverbindung über eine FritzBox kann ich sie leider nicht testen. Die Auswahl erfolgt zurzeit noch durch ein- und auskommentieren am Ende des Skripts.
ng-upnp2mrtg - Was Sie brauchen
mrtg: Dieses Programm sollte über die Repositories Ihrer Distribution erhältlich sein. Ansonsten finden Sie es hier.
ng-upnp2mrtg.py: Das Skript läuft unter Python, was heute auf jedem Linux-System installiert sein sollte, und braucht keine besonderen Bibliotheken. Im Augenblick ist es hier abrufbar.
mrtg.cfg: Konfigurationsdatei für mrtg angepasst an ng-upnp2mrtg.py, Im Augenblick hier zu bekommen.
Ich werde versuchen das Skript bei einem der OpenSource-Projekt-Sites als Projekt anzumelden. Die Dateien und neuere Versionen werden dann dort abrufbar sein.
Installation von ng-upnp2mrtg
Für die folgenden Schritte brauchen Sie Root-Rechte:
Passen Sie oben im Skript ng-upnp2mrtg.py die Variablen HOST und PORT an.
Kopieren Sie das Skript nach /usr/local/bin und machen Sie es ausführbar
Die Konfigurationsdatei mrtg.cfg kommt nach /etc.
cp -a ng-upnp2mrtg.py /usr/local/bin
chmod 755 /usr/local/bin/ng-upnp2mrtg.py
cp -a mrtg.cfg /etc
Für den regelmäßige Aufruf von mrtg sorgt der folgende crontab-Eintrag:
0-59/5 * * * * env LANG=C /usr/bin/mrtg --logging /var/log/mrtg.log
Das Ganze wurde getestet mit Ubuntu 8.04, mrtg 2.14.7, Python 2.5.2.
Schwierigkeiten bei der Übernahme auf andere System sind eigentlich nicht zu erwarten... aber das sagt man ja vorher immer.
Abonnieren
Posts (Atom)