In früheren Linux-Versionen hatte man in Systemen mit mehreren Ethernet-Netzwerkkarten hin und wieder das Problem, dass sich die eth-Gerätenummer z.B. nach einem Kernel-Update änderte, weil die Reihenfolge, in der Treiber aufgerufen wurden, auf einmal anders war.
Funktionen, die auf diesen Gerätenummern aufbauten - wie z.B. iptables-Firewalls - bringt dies natürlich durcheinander; und man hat sich unter Umständen ausgesperrt. Wenn der Computer dann nicht so einfach zugänglich ist, ist das... unangenehm.
Bei neueren, auf udev basierenden Systemen passiert das nicht mehr. Das System merkt sich die MAC-Adresse der Karte und weist ihr fest einen Gerätenamen zu. Das Ergebnis sind udev-Regeln, die man in /etc/udev/rules.d/70-persistent-net.rules * finden kann:
# PCI device 0x10de:0x0057 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:22:33:44:55", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
Diese Datei ist Ergebnis des Scripts /lib/udev/write_net_rules welches seinerseit von der udev-Regel /etc/udev/rules.d/75-persistent-net-generator.rules gestartet wird. (Beispiele aus Ubuntu Hardy).
In anderen Systemen, stehen diese Dateien teilweise in anderen Verzeichnissen, und die Nummer im Dateiname ist leicht verändert. Mit locate lassen sie sich aber leicht finden.
Freitag, 19. Juni 2009
Dienstag, 16. Juni 2009
Die Kehrseite der häufigen Ubuntu-Releases
Kehrseite der halbjährlichen Ubuntu-Releases ist die Tatsache, das während eines Release-Zyklus zwar Sicherheitsupdates veröffentlicht werden, Feature-Updates oder nicht sicherheitsrelevante Fehler frühestens mit dem nächsten Release behoben werden.War es im vorletzten Release (Intrepid) - wegen Änderungen im Bluetooth-Stack - der nicht mehr funktionierende Bluetooth-Dongle, so schmerzen die beiden Bugs in Jaunty dann doch:
In OpenOffice verschwinden plötzlich Tabellen aus Word-Dokumenten, und Inkscape lässt sich nach dem Update wegen Durcheinander in den zu ladenden Bibliotheken nicht mehr starten.
Diese beiden Fehler treten bei mir nur in der wohl nicht so weit verbreiteten 64-Bit-Versionen auf und sollen teilweise schon behoben sein.
Auch wenn der Besuch auf dem Ubuntu-Bugtracker-Portal Launchpad einem das warme Gefühl vermittelt, dass man mit dem Problem nicht allein ist, dem Durchschnitts-Ubuntuaner (oder heißen Sie Ubuntuniken...) also dem Durchschnitts-Ubunter-User werden diese Updates wohl frühestens ab Oktober mit Karmic zur Verfügung stehen.
Montag, 8. Juni 2009
Firefox - online auch ohne Internet
Es kommt zwar selten vor, aber hin und wieder betreibe ich meinen Ubuntu-Laptop auch ohne Verbindung zum Internet. Unterwegs - z.B. beim Erste-Hilfe-Einsatz als Computer-Doktor - ist der Zugriff auf die Laptop-Kopie meines Wikis recht nützlich.
Wenn eine Netzwerkverbindung fehlt schaltet Firefox in den Offline-Modus. Auf einen im Laptop laufenden Apache-Server kann so nicht zugegriffen werden.
Natürlich kann man nun mit "Datei - Offline arbeiten" diesen Modus wieder ausschalten. Auf die Dauer nervt diese Zwischenschritt; deshalb hier die Option, wie man ihn umgehen kann:
Mit der Eingabe about:config in der Adresszeile zeigt Firefox seine diversen Konfigurations-Optionen an, die so selten gebraucht werden, dass sich ein eigenes Panel dafür nicht lohnt. Hier sucht man nun nach
und setzt die Option auf True.
Man kann sich die Suche erleichtern, wenn man z.B. toolkit als Filterausdruck eingibt.
Hiermit wird Firefox angewiesen den Netzwerkstatus nicht beim Networkmanager zu erfragen und bleibt deshalb immer im Online-Modus. Das als Startseite konfigurierte Wiki wird nun direkt angezeigt.
Wenn eine Netzwerkverbindung fehlt schaltet Firefox in den Offline-Modus. Auf einen im Laptop laufenden Apache-Server kann so nicht zugegriffen werden.
Natürlich kann man nun mit "Datei - Offline arbeiten" diesen Modus wieder ausschalten. Auf die Dauer nervt diese Zwischenschritt; deshalb hier die Option, wie man ihn umgehen kann:
Mit der Eingabe about:config in der Adresszeile zeigt Firefox seine diversen Konfigurations-Optionen an, die so selten gebraucht werden, dass sich ein eigenes Panel dafür nicht lohnt. Hier sucht man nun nach
toolkit.networkmanager.disable
und setzt die Option auf True.
Man kann sich die Suche erleichtern, wenn man z.B. toolkit als Filterausdruck eingibt.
Hiermit wird Firefox angewiesen den Netzwerkstatus nicht beim Networkmanager zu erfragen und bleibt deshalb immer im Online-Modus. Das als Startseite konfigurierte Wiki wird nun direkt angezeigt.
Samstag, 6. Juni 2009
ng-upnp2mrtg Version 0.2.3 freigegeben
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.
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.
Samstag, 9. Mai 2009
T-Mobile und GnuPG/PGP
Ab diesem Monat gibt es die Handy-Rechnung nicht mehr auf Papier – natürlich aus Umweltschutzgründen. Wohin die gesparten Druck- und Versandkosten fließen, bleibt ungenannt.
Zu bekommen ist die Rechnung über das T-Mobile-Internet-Portal, aber auch der zusätzliche Versand per E-Mail ist vorgesehen. Diese E-Mail kann sogar mit PGP/GnuPG verschlüsselt werden. Falls der Rechnung noch der Einzelverbindungsnachweis beiliegen soll, ist die Verschlüsselung sogar zwingend vorgeschrieben.
Den Masken zum Einrichten ist eine ausführliche Seite mit Anweisungen vorgeschaltet. Jeder der in der Lage ist, ein GnuPG/PGP-Schlüsselpaar zu generieren, den öffentlichen Schlüssel auszulagern und hochzuladen, wird mit der Beschreibung keine Probleme haben...
Probleme hatte an diesem Tag hingegen der entsprechende Server bei T-Mobile, der den Versuch diese Konfiguration einzurichten mit einem „unbekannten Fehler“ quittierte. Zwar erhielt ich nach dem Einrichten die zugehörige verschlüsselte E-Mail mit der Bestätigung, der darin enthaltene Bestätigungscode wurde aber nicht angenommen. Unterdessen funktioniert aber auch das.
So sehr man T-Mobile für eine der ersten realen Einsatzmöglichkeit für GnuPG/PGP danken möchte, ein weit verbreiteter Einsatz ist nicht zuletzt wegen des umständlichen Verfahrens unwahrscheinlich.
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.
Abonnieren
Posts (Atom)