0

I'm trying to use an existing dhcpd to autoconfigure Raritan networked PDUs. This works roughly like PXE booting: there are additional DHCP options that direct the device to fetch a config file via TFTP. However, it uses vendor DHCP options to do this.

I have defined the option space, and a new class for the PDUs. I can see that my class is being matched (I set the DNS and domain-name differently inside the class, and those options are sent). However, the vendor-specific options are not sent (checked with dhcpdump). The server has no problem with the config though (that it logs anyway).

What can cause it to not send vendor options?

set vendor-string = option vendor-class-identifier;

option space RARITAN code width 1 length width 1 hash size 3;
option RARITAN.pdu-tftp-server code 1 = ip-address;
option RARITAN.pdu-update-control-file code 2 = text;
option RARITAN.pdu-update-magic code 3 = text;

class "PDUs" {
    match if option vendor-class-identifier = "Raritan PDU 1.0";
    vendor-option-space RARITAN;
    option vendor-class-identifier "Raritan PDU 1.0";
    option domain-name-servers 1.1.1.1;
    option domain-name "pdu.net";
    option RARITAN.pdu-tftp-server 10.251.0.9;
    option RARITAN.pdu-update-control-file "raritan-update.cfg";
    option RARITAN.pdu-update-magic "20180822-0005";
}

Nothing in any of the existing scopes uses vendor-option-space, so I don't think there are any conflicts there.

AnotherHowie
  • 206
  • 3
  • 13
  • I would at least try to be consistent in your capitalisation `vendor-option-space` or `option space` `RARITAN` might not match `class "raritan"` because of case sensitivity. – HBruijn Aug 22 '18 at 12:59
  • They are different objects. Also, the server does match the class - I get the non-vendor options. The case/name of the option-space matches in both cases. As far as I understand it, the class could be called "huskies". Is that incorrect? – AnotherHowie Aug 22 '18 at 13:14
  • I have little to no idea how the vendor encapsulated options are supposed to be implemented or work actually, but the difference in case is something that just caught my eye. From past experience I know that things such as meaningful white space and case (in)sensitivity in unexpected places can make for difficult debugging and those are a blind-spot of mine when I think I followed [an example](https://www.isc.org/wp-content/uploads/2017/08/dhcp41options.html#VENDOR%20ENCAPSULATED%20OPTIONS) almost verbatim. – HBruijn Aug 22 '18 at 13:30
  • 1
    gotcha... for the sake of argument, I just checked, and it doesn't make a difference what the class is called. – AnotherHowie Aug 22 '18 at 13:34
  • I'd do a quick packet capture on the dhcp server to ensure the devices are actually sending "Raritan PDU 1.0" as the vendor. Edit: Nevermind, just noticed you said the class was matched. – Brandon Xavier Aug 22 '18 at 13:51
  • Is it possible that there exist a limitation in dhcpdump? What does tcpdump/wireshark show? Perhaps the vendor specific options are sent to the PDUs but they incorrectly process them (for whatever reason). – Tommiie Aug 23 '18 at 10:26
  • I believe it's just a wrapper around tcpdump, but I've just checked with tshark and see the same thing. – AnotherHowie Aug 23 '18 at 11:02

0 Answers0