Linux Opção do servidor DHCP 43 opções encapsuladas pelo fornecedor, como formatar / codificar?

Question

Eu administro a rede para uma pequena empresa que possui uma caixa de firewall IPCop que fornece serviços DHCP à rede (e vários outros serviços). O servidor DHCP no IPCop parece ser o dhcpd e o IPCop fornece um front-end baseado na web para editar o arquivo de configuração.

Estou procurando usar a opção de opções encapsuladas de fornecedor para enviar valores específicos para as opções de DHCP 66 e 67 para um identificador de classe de fornecedor específico. O objetivo é a configuração automática de alguns telefones VoIP que suportam as opções de DHCP 66/67 e 43/60.

Eu já consegui obter opções 66 tftp-server-name e 67 bootfile-name trabalhando para configurar automaticamente os telefones. Mas é claro que essas opções são globais e enviadas para todos os clientes DHCP. Eu estou olhando para experimentar com as opções de identificador de classe de fornecedor e opções encapsuladas de fornecedor para enviar as informações de configuração automática somente para os telefones. Eu percebo que isso é provavelmente um exagero para uma rede de pequenas empresas, mas isso é tudo para ampliar meu conhecimento.

Então, comecei a ler algumas informações que estão por aí e não consigo descobrir como codificar as opções 66/67 em uma string de opções encapsuladas de fornecedor.
Aqui está o RFC relevante ... link seção 8.4 E aqui está a página man do dhcpd link em "OPÇÕES ENCAPSULADAS VENDEDOR"

Esses documentos parecem sugerir que as opções devem ser codificadas no formato hexadecimal, no entanto, olhando o exemplo da página de manual da opção de opções encapsuladas do fornecedor ...

The value of this option can be set in one of two ways.  
The first way is to simply specify the data directly,  
using a text string or a colon-separated list of hexadecimal values.  
For example:  
       option vendor-encapsulated-options
           2:4:AC:11:41:1:
           3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31:
           4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63;

Quando tento decodificar esse lote de HEX para ASCII, recebo o seguinte:
????A?????????sundhcp-server17-1????????/export/root/i86pc
Então, tenho certeza de que não estou entendendo o formato / codificação corretamente.

Aqui está meu trecho do dhcpd.conf do IPCop

subnet 192.168.1.0 netmask 255.255.255.0 #GREEN
{
        range 192.168.1.30 192.168.1.200;
        option subnet-mask 255.255.255.0;
        option domain-name "domain.com";
        option routers 192.168.1.1;
        option domain-name-servers 192.168.1.1;
        option ntp-servers 192.168.1.1;
        option netbios-name-servers 192.168.1.3;
        default-lease-time 43200;
        max-lease-time 172800;
        option vendor-encapsulated-options "hello";
        option vendor-class-identifier "snom320";
        option vendor-class-identifier "snom821";
        option bootfile-name "voipsettings/firstboot.xml";
        option tftp-server-name "http://username:[email protected]";
} #GREEN

Eu tenho os identificadores de classe de fornecedor definidos pelo valor enviado pelos telefones VoIP (Snom) na solicitação DHCP. O bootfile-name e o tftp-server-name são as opções (66/67) que eu estou procurando codificar nas opções encapsuladas do fornecedor.
Snom tem um guia em seu wiki aqui ...
http://wiki.snom.com/Networking/DHCP/Options#Auto_Provisioning_Options
(Desculpas, minha reputação é muito baixa para postar > 2 links em uma pergunta)
Esse wiki parece sugerir que eu preciso codificar o identificador de classe de fornecedor como uma "string de n octetos"
Além disso, os exemplos das opções encapsuladas do fornecedor fornecidas nesse artigo da wiki também retornam ininteligíveis ao converter de HEX para ASCII. Então, há algo crítico que não estou entendendo aqui.

Alguém pode me dar um resumo de como formatar / codificar essas opções de DHCP corretamente?

    

Answer 1

A Opção 43 do DHCP é um pouco estranha. Os fornecedores podem tratá-lo da maneira que quiserem - alguns esperam que os números das opções correspondam aos números das opções de DHCP, outros não.

A estrutura básica é de 1 byte para uma ID de opção, 1 byte para o comprimento dos dados da opção (n), então n bytes dos dados da opção real - e, enxágue e repita.

Vamos pegar o exemplo do dhcp-options. Eles colocaram as novas linhas em lugares estratégicos para facilitar a leitura. Na realidade, a configuração que eles configuraram é exatamente isso:

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;

É muito difícil de ler, a menos que você saiba o que está procurando. Vamos dividir as partes:

• Byte 1, 0x02 . Isso diz que esse bloco é config para a opção número 2. Como isso é interpretado depende do fornecedor.
• Byte 2, 0x04 . Isso diz que os dados da opção 2 ocuparão os próximos 4 bytes.
• Bytes 3-6, 0xAC114101 . Esses quatro bytes são os dados reais. Como você viu quando tentou decodificá-lo, não são dados legíveis.
• Byte 7, o início do próximo bloco de opções , 0x03 . Toda a cadeia começa de novo, isso diz que a seguinte configuração é para a opção 3.
• e assim por diante, por 3 seções

Outro exemplo, da página wiki 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 em hexadecimal é 66, para o código de opção 66.
• Byte 2, 0x0c . Comprimento de 12 bytes.
• Bytes 3-14, 0x687474703a2f2f7465737400 . Este é http://test com um byte nulo ( 0x00 ) no final. Não tenho certeza porque eles têm isso lá.
• Byte 15, 0x43 . Opção 67.
• Byte 16, 0x12 . Comprimento de 18 bytes.
• Bytes 17 a 34, 0x736e6f6d2f73657474696e67732e70687000 . %código%. Novamente, o byte nulo no final.

Então, digamos que você precisa construir uma opção 43 com snom/settings.php como opção 66 e http://phone.example.com como opção 67.

• Byte 1, código de opção 66, phonesettings.txt
• Byte 2, comprimento de 24 bytes em 0x42 , portanto, http://phone.example.com
• Bytes 3-26, os dados. %código%
• Byte 27, código de opção 67, 0x18
• Byte 28, comprimento de 17 bytes em 0x687474703a2f2f70686f6e652e6578616d706c652e636f6d , portanto, 0x43
• Bytes 29 a 45, dados. %código%

Então, uma string de configuração completa de:

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 isso não funcionar, tente adicionar os bytes nulos ao final das strings de dados (e aumente o tamanho do campo de acordo) como em seu exemplo - eles podem desejar bytes nulos no final de cada opção ou um mesmo número de bytes para o comprimento de cada opção. Essa é a desvantagem da opção 43 - eles podem fazer o que quiserem!

    

Answer 2

Essa é definitivamente a maneira mais complicada de configurar a opção 43. Em vez disso, você deve usar a sintaxe "espaço de opção de fornecedor" do ISC que permite que você obtenha uma leitura humana do que você configurou e evite erros:

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

    

Answer 3

Lembre-se de usar o encapsulamento local:

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;