Linux-DHCP-Serveroption 43 Hersteller-Encapsulated-Options, wie wird formatiert/kodiert?

DHCP Option 43 ist ein etwas seltsames Biest. Anbieter können es behandeln, wie sie wollen - einige erwarten, dass die Optionsnummern mit den DHCP-Optionsnummern übereinstimmen, andere nicht.

Die Grundstruktur ist 1 Byte für eine Options-ID, 1 Byte für die Länge der Optionsdaten (n), dann n Bytes der eigentlichen Optionsdaten - und, spülen und wiederholen.

Nehmen wir das Beispiel von dhcp-options. Sie haben die Zeilenumbrüche an strategischen Stellen platziert, um das Lesen zu erleichtern. In Wirklichkeit ist die Einstellung, die sie konfiguriert haben, nur diese:

02:04:AC:11:41:01:03:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:04:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

Was ziemlich schwer zu lesen ist, es sei denn, Sie wissen, wonach Sie suchen. Lassen Sie uns die Teile aufschlüsseln:

• Byte 1, 0x02 . Dies besagt, dass dieser Block für Option Nummer 2 konfiguriert ist. Wie das interpretiert wird, ist Sache des Anbieters.
• Byte 2, 0x04 . Dies besagt, dass die Daten für Option 2 die nächsten 4 Bytes belegen werden.
• Bytes 3-6, 0xAC114101 . Diese vier Bytes sind die eigentlichen Daten. Wie Sie beim Entschlüsseln gesehen haben, handelt es sich nicht um lesbare Daten.
• Byte 7, der Beginn des nächsten Optionsblocks , 0x03 . Die ganze Kette beginnt wieder von vorne, das besagt, dass die folgende Konfiguration für Option 3 ist.
• und so weiter, für 3 Abschnitte

Ein weiteres Beispiel von der snom-Wiki-Seite:

42:0c:68:74:74:70:3a:2f:2f:74:65:73:74:00:43:12:73:6e:6f:6d:2f:73:65:74:74:69:6e:67:73:2e:70:68:70:00;

• Byte 1, 0x42 . 42 in Hex ist 66, für Optionscode 66.
• Byte 2, 0x0c . Länge 12 Bytes.
• Bytes 3-14, 0x687474703a2f2f7465737400 . Das ist http://test mit einem Nullbyte (0x00 ) am Ende. Ich bin mir nicht sicher, warum sie das dort haben.
• Byte 15, 0x43 . Möglichkeit 67.
• Byte 16, 0x12 . 18 Byte Länge.
• Bytes 17-34, 0x736e6f6d2f73657474696e67732e70687000 . snom/settings.php . Wieder das Null-Byte am Ende.

Nehmen wir also an, Sie müssen eine Option 43 mit http://phone.example.com konstruieren als Option 66 und phonesettings.txt als Option 67.

• Byte 1, Optionscode 66, 0x42
• Byte 2, Länge 24 Bytes auf http://phone.example.com , also 0x18
• Bytes 3-26, die Daten. 0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
• Byte 27, Optionscode 67, 0x43
• Byte 28, Länge 17 Bytes auf phonesettings.txt , also 0x11
• Bytes 29-45, Daten. 0x70686f6e6573657474696e67732e747874

Also eine vollständige Konfigurationszeichenfolge von :

42:18:68:74:74:70:3a:2f:2f:70:68:6f:6e:65:2e:65:78:61:6d:70:6c:65:2e:63:6f:6d:43:11:70:68:6f:6e:65:73:65:74:74:69:6e:67:73:2e:74:78:74;

Wenn das nicht funktioniert, versuchen Sie, die Nullbytes am Ende der Datenzeichenfolgen hinzuzufügen (und das Längenfeld entsprechend zu erhöhen), wie in ihrem Beispiel - sie möchten entweder Nullbytes am Ende jeder Option oder eine gerade Anzahl von Bytes für die Länge jeder Option. Das ist der Nachteil von Option 43 – sie können tun, was sie wollen!

Das ist definitiv die beschissenste Art, die Option 43 zu konfigurieren. Sie sollten stattdessen die "Vendor Option Space"-Syntax des ISC verwenden, die es Ihnen ermöglicht, eine menschliche Lesung Ihrer Konfiguration zu erhalten und Fehler zu vermeiden:

option space db;
option db.db-server code 1 = ip-address;
option db.loginid code 2 = text;
option db.db-name code 3 = text;

Jean-Yves Bisiaux

Denken Sie daran, die lokale Kapselung zu verwenden:

option space cisco;
option cisco.wlc code 241 = array of ip-address;
option local-encapsulation code 43 = encapsulate cisco;
option cisco.wlc 10.7.3.6, 10.7.3.2;