dhcpd não está correspondendo a esse endereço mac

Question

Na minha pequena rede, eu tenho um dispositivo simples que aparentemente está usando apenas bootp (ao contrário das extensões dhcp para inicializar) para obter seu endereço. Meu arquivo dhcpd.conf é parecido com isto

class "user" {
    match if substring(hardware, 1, 3) = 00:01:02;
    log(info, "matched to a 3com";
}

class "controller" {
    # tried matching based on two different styles I've seen on the net
    #match if substring(hardware, 1, 3) = 00:a0:45;
    match if (binary-to-ascii(16, 8, ":", substring(hardware, 0, 4)) = "1:00:a0:45");
    log(info, "found a controller");
}

subnet 192.168.0.0 netmask 255.255.0.0 {
    pool {
        allow members of "user";
        range 192.168.0.20 192.168.0.99;
        log(info, "A user just attached");
    }            

    pool {
        allow members of "controller";
        # never more than 1 on the network at a time
        range 192.168.1.240;
        log(info, "Allocated to a pwr user");
    }
}

O servidor dhcp simplesmente não corresponderá ao pool que deveria. Do log

BOOTREQUEST from 00:a0:45:95:ce:14 via eth1: BOOTP from dynamic client and no dynamic leases

O dispositivo é DENIED para as duas classes. Usando tcpdump e wireshark para comparar despejos de pacotes de um laptop e do dispositivo controlador (eu fiz temporariamente uma aula para um laptop HP, adicionei essa classe ao pool usado para "controller" e estendi o intervalo por 2 endereços), parece que a única A diferença é que o dispositivo controlador é literalmente um pacote bootp (ou seja, não possui a opção obrigatória 53 que identifica o tipo dhcp), e carrega apenas a opção 255. O laptop foi correspondido por dhcpd sem usar a conversão binary-to-ascii . Além disso, e curiosamente, o cabeçalho IP do cliente do controlador usa o endereço IP alocado pela primeira vez, 192.168.1.240, mas na seção bootp do pacote, o campo ciaddr é 0. Se ele acredita que tem uma concessão válida, não deve isso reflete isso em ciaddr ?

Por que o dhcpd não corresponde ao endereço MAC deste dispositivo?

    

Answer 1

Encontrei a resposta para este problema e queria publicá-lo. Descobriu-se que não tinha nada a ver com a forma como os padrões estavam sendo combinados. De fato,

class "user" {
    match if substring(hardware, 1, 3) = 00:01:02;
    log(info, "matched to a 3com";
}

esta é a sintaxe correta para combinar no hardware.

No entanto, este foi um caso em que os fatos me levaram à conclusão errada. Depois de analisar vários RFCs sobre bootp e dhcp, ficou claro que o dispositivo em questão não tinha a opção obrigatória de tipo DHCP, de RFC 1541 seção 3, tornando-o um cliente somente bootp. Assim, a correção veio de algo que eu não esperava que fosse necessário. A instrução range inclui o modificador dynamic-bootp , que indica que o intervalo de IPs é para clientes dhcp ou bootp. No entanto, também precisei de allow dynamic bootp clients; no conjunto da seguinte forma:

pool {
    allow dynamic bootp clients;
    allow members of "controller";
    # never more than 1 on the network at a time
    range dynamic-bootp 192.168.1.240;
    log(info, "Allocated to a pwr user");
}

Eu teria pensado que esse modificador teria sido suficiente, mas não foi. Eu precisava de ambos para realizar a tarefa.

Espero que isso seja útil para alguém.

    

Answer 2

Você precisa converter os dados em "hardware" antes de compará-los e contabilizar seu primeiro elemento que indica o tipo. Tente algo como:

class "controller" {
    match if binary-to-ascii(16,8,":",substring(hardware, 0, 4)) = "1:00:a0:45";
    log(info, "found a controller");
}

Mas se for apenas um dispositivo, por que não usar apenas um endereço fixo:

host controller-hostname {
    hardware ethernet 00:a0:45:95:ce:14;
    fixed-address 192.168.1.240;
}

Adicione "boot-dinâmico" ao pool:

pool {
    allow members of "controller";
    # never more than 1 on the network at a time
    range dynamic-bootp 192.168.1.240;
    log(info, "Allocated to a pwr user");
}