Vendor Options im DHCP
Ein Kunde fragt, ob man bestimmten Nutzern per DHCP ein TR069-Server beibringen kann. Schließlich ist die Fernkonfiguration eines Kundenrouters grundsätzlich zustimmungspflichtig. Die Aufgabe besteht also darin, die entsprechende Option in der DHCP Antwort dann zu senden, wenn der richtige Router anfragt.
Standards
Was zu tun ist, steht in den Standards. Diese sind bei broadband-forum.org hinterlegt. Im Grundsatz ist die Idee ganz einfach:
- Ein Router (CPE) sendet in der DHCP Anfrage eine Option vom Typ Vendor-Class mit dem Inhalt "dslforum.org"
- Der DHCP Server erkennt die Vendor-Class und sendet eine Vendor-Option mit den benötigten Parametern.
- Die CPE kontaktiert anhand der Parameter den TR-069 Server (ACS genannt).
- Der ACS konfiguriert die CPE.
Im Original heißt es dazu:
A CPE identifies itself to the DHCP server as supporting this method by including the string “dslforum.org” (all lower case) any where in the DHCPv4 Vendor Class Identifier (option 60), in the DHCPv4 V-I Vendor Class Option (option 124) or in a DHCPv6 Vendor Class (option 16) vendor-class-data item. The CPE MAY include either DHCPv4 option 43 or DHCPv4 option 125 (not both) in a DHCPv4 parameter-request-list (option 55) in order to indicate support for and to request option 43 or option 125. If the CPE does not use option 55 in this way, the server can assume that it supports and requests option 43 (not option 125). Similarly,the CPE MAY include DHCPv6 option 17 in a DHCPv6 Option Request Option (option 6). The CPE MAY use the values received from the DHCP server in the Vendor Specific Information (DHCPv4 option 43/ DHCPv4 option 125/ DHCPv6 option 17) to set the corresponding Parameters ...
Soweit so einfach. Der Text enthält ein paar MAYs zuviel, um unmittelbar benutzbar zu erscheinen.
Als erstes fällt auf, dass es mehr als einen Typ von Vendor Optionen gibt: Die alte Form 60/43 und die neue Form 124/125 (für IPv4) und 16/17 (für IPv6). Das ist schon einmal die erste Entscheidung. Aber die ist einfach, weil sich die Parameter der neueren Vendor Optionen im Laufe der letzten paar Jahre einige Male geändert haben. Stabil blieb nur die alte Form.
Als nächstes kommt die Frage, welche Daten wirklich übersendet werden müssen und welche Folge das hat:
If the CPE obtained an ACS URL through DHCP and it cannot reach the ACS, the CPE MUST use DHCP to rediscover the ACS URL. The CPE MUST consider the ACS unreachable if it cannot establish a TCP connection to it for 300 seconds at each of the IP addresses to which the ACS URL resolves.
Primär notwendig ist also die ACS-URL und diese muss erreichbar sein. Andernfalls kommt die CPE nicht online.
Die Entscheidung, nicht sämtliche Kundenrouter mit der TR-69 Konfig zu beglücken, ist also allein dadurch gerechtfertigt.
Implementierung
Im Einsatz sind ISC DHCP Server, und diese haben eine clevere Methode Vendor Options zu konfigurieren.
option space ACS; option ACS.acs_URL code 1 = text; option ACS.acs_PROVCODE code 2 = text;
Diese Konfiguration sagt dem DHCP Server, wie die interne Struktur der Vendor Option aussieht: Es gibt zwei Untertypen mit den Codes 1 und 2, die jeweils Text enthalten. Beim Generieren der DHCP Antwort wird der DHCP Server somit die entsprechenden Tag-Length-Value Einträge erzeugen und diese dann als großen Blob in als Wert der Option 43 eintragen.
Die Interpretation der Option 43 (Vendor Option) ist der CPE überlassen, die dann hoffentlich weiß, dass hier ACS Konfiguration auszulesen ist. Was nämlich fehlt, ist die Angabe des Herstellers für den die Optionen gelten. Man muss also absolut sicher sein, welcher CPE man welche Vendor Optionen übersendet. Normalerweise erfolgt das dadurch, dass die CPE ja selbst mit der Angabe der Vendor Class in der Anfrage festgelegt hat, wie sie die Vendor Optionen verarbeiten wird.
Als nächstes kann man die Werte im DHCP Server setzen. Die URL ist statisch und der ProviderCode, mit dem sich die CPE melden soll, ist gerätespezifisch.
option ACS.acs_URL "https://acs.dsl.example:12345/path/to/tr69.app";
host xxx { option ACS.acs_PROVCODE "IDENTIFIER"; }Jetzt weiß der DHCP Server, welche Angaben er welchem Client einzupacken hat. Was er noch nicht weiß, ist, welche Optionen welchen Herstellers er überhaupt einpacken soll. Solange das nicht klar ist, liefert er nichts aus. Bei den neueren Optionen besteht das Problem nicht, weil dort der Hersteller immer mitgesendet wird.
Normalweise löst man das so, dass man die Vendor Class der Anfrage auswertet. Leider senden die CPEs diese Information aber nicht mit. Also setze ich diese Auswahl am host, denn alle anderen sollen die Optionen ja wirklich nicht bekommen.
host xxx { vendor-option-space ACS; }Nun liefert der ACS an diese CPEs die entsprechenden Optionen aus.
Geht nicht?
Aber halt! Er liefert nicht an alle CPEs. Grund ist die Option 55 (parameter-request-list) in der die CPE festlegt, welche Optionen sie in der Antwort akzeptiert. Mit dem setzen dieser Option schließt sie alle anderen Optionen für die Antwort aus. Und natürlich ist die Vendor Option (43) nicht angefordert worden. Nur dort, wo die Option 55 in der Anfrage fehlte, hat der DHCP Server auch eine Antwort geliefert.
Also muss man generell die Optionsliste erweitern:
option dhcp-parameter-request-list = concat(option dhcp-parameter-request-list,2b);
Eine berechtigte Frage ist, warum man nicht append option parameter-request-list 43 benutzt. Und die Antwort ist so einfach wie verblüffend: Diese Syntax steht nur in der Konfig des DHCP-Client zur Verfügung.
Und es geht immer noch nicht!
An der Stelle habe ich lange gesucht, weil jede Konfigurationsänderung absolut nichts bewirkt hat.
Erst nach Tagen fiel mir eine Zeile an ganz anderer Stelle in die Hände:
option meta-data code 43 = text;
Irgendjemand hatte sich einen neuen Datentyp gebaut, der den Codepunkt 43 benutzt, Damit war das komplette Vendor Option Space Processing des DHCP Servers deaktiviert.
Nach Löschen der Altlast-Zeile tut die Kiste, was sie soll.
Sich sich immer mal wieder über den Weg zu laufen... ("VolXlaser" noch ein Begriff?) hat irgendwie was...
Danke für Ihren Artikel - der Tip mit der umdefinierten Code43-Option hat mir heute eine längere TrialnError-Phase erspart!!! Danke dafür!
Grüße Tim Skopnik
1 Kommentare