Opzione server DHCP Linux 43 opzioni incapsulate dal fornitore, come formattare/codificare?

L'opzione DHCP 43 è un po' strana. I fornitori possono trattarlo come vogliono:alcuni si aspettano che i numeri di opzione corrispondano ai numeri di opzione DHCP, altri no.

La struttura di base è 1 byte per un ID opzione, 1 byte per la lunghezza dei dati dell'opzione (n), quindi n byte dei dati effettivi dell'opzione - e, risciacqua e ripeti.

Prendiamo l'esempio da dhcp-options. Hanno bloccato le nuove righe in punti strategici per facilitarne la lettura. In realtà, l'impostazione che hanno configurato è proprio questa:

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;

Il che è piuttosto difficile da leggere se non sai cosa stai cercando. Analizziamo le parti:

• Byte 1, 0x02 . Questo dice che questo blocco è configurato per l'opzione numero 2. Il modo in cui viene interpretato dipende dal fornitore.
• Byte 2, 0x04 . Questo dice che i dati per l'opzione 2 occuperanno i successivi 4 byte.
• Byte 3-6, 0xAC114101 . Questi quattro byte sono i dati effettivi. Come hai visto quando hai provato a decodificarlo, non sono dati leggibili.
• Byte 7, l'inizio del prossimo blocco di opzioni , 0x03 . L'intera catena ricomincia, questo dice che la seguente configurazione è per l'opzione 3.
• e così via, per 3 sezioni

Un altro esempio, dalla pagina wiki di snom:

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 esadecimale è 66, per il codice opzione 66.
• Byte 2, 0x0c . Lunghezza di 12 byte.
• Byte 3-14, 0x687474703a2f2f7465737400 . Questo è http://test con un byte nullo (0x00 ) sulla fine. Non so perché ce l'abbiano lì.
• Byte 15, 0x43 . Opzione 67.
• Byte 16, 0x12 . Lunghezza 18 byte.
• Byte 17-34, 0x736e6f6d2f73657474696e67732e70687000 . snom/settings.php . Di nuovo, il byte nullo alla fine.

Quindi, diciamo che devi costruire un'opzione 43 con http://phone.example.com come opzione 66 e phonesettings.txt come opzione 67.

• Byte 1, codice opzione 66, 0x42
• Byte 2, lunghezza di 24 byte su http://phone.example.com , quindi 0x18
• Byte 3-26, i dati. 0x687474703a2f2f70686f6e652e6578616d706c652e636f6d
• Byte 27, codice opzione 67, 0x43
• Byte 28, lunghezza di 17 byte su phonesettings.txt , quindi 0x11
• Byte 29-45, dati. 0x70686f6e6573657474696e67732e747874

Quindi, una stringa di configurazione completa di :

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;

Se ciò non funziona, prova ad aggiungere i byte nulli alla fine delle stringhe di dati (e aumenta di conseguenza il campo della lunghezza) come nel loro esempio:possono desiderare byte nulli alla fine di ciascuna opzione o un numero pari di byte per la lunghezza di ogni opzione. Questo è lo svantaggio dell'opzione 43:possono fare quello che vogliono!

Questo è sicuramente il modo più scadente per configurare l'opzione 43. Dovresti invece utilizzare la sintassi "vendor option space" di ISC che ti consente di ottenere una lettura umana di ciò che hai configurato ed evitare errori:

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

Ricorda di usare local-incapsulation:

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;