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:
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).
Die interessanten variablen Teile sind fett dargestellt. Dies sind zum einen die URL in der ersten Zeile, und in der Zeile SOAPACTION den – nennen wir ihn – Dienstbezeichner (vor dem #-Zeichen mit 'urn:schemas-upnp.org' beginnend) und die darauf anzuwendende Aktion (hinter dem #).

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 OK
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>
Man 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.

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.
Die IP-Adresse ist meist mit der des Routers identisch, doch spätestens bei der Port-Nummer wird es schwierig. So verwendet die FritzBox Port 49000, das NetCologne-Modem hingegen Port 49300.

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.1
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
Auch 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.
  • 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.
Tell me more...

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.
Stellen Sie der <SCPDURL> 'http://IP-Adresse:Port/' voran und geben Sie sie im Browser ein.

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.
Somit hätten wir also alle Informationen zusammen, die wir für die Abfrage brauchen.

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.

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.