ISC DHCP Options not working?

[CJ]

Has anyone gotten DHCP Options to work with ISC?  The threads I've found seem to imply that the UI isn't working correctly to set them.  No matter what I put in the Advanced Options field, nothing ever gets sent.

https://forum.opnsense.org/index.php?topic=23468.msg111581#msg111581

https://forum.opnsense.org/index.php?topic=21879.msg103411#msg103411

I know at one point the UI was doing something because I was getting an error message in the DHCP logs regarding the hostname I put in, but I'm not even seeing that currently.  I've tested Text, String, and IP/Host options with no result.

[Patrick M. Hausen]

Working as intended. I use them in a production environment and I never had any problem. See screen shot for an example - that's the Unifi Controller address in our company network.

Kind regards,
Patrick

[CJ]

Working as intended. I use them in a production environment and I never had any problem. See screen shot for an example - that's the Unifi Controller address in our company network.

I set my Option 43 just like you show and it still doesn't show up in the packet capture.

Code: [Select]

ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC, length 300, xid 0xf8cfc318, Flags [none] (0x0000)
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    Requested-IP Option 50, length 4: 192.168.1.1
    MSZ Option 57, length 2: 576
    Parameter-Request Option 55, length 7:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
      Domain-Name, BR, NTP
    Vendor-Class Option 60, length 10: "EngeniusAP"
    Hostname Option 12, length 10: "EWS276-FIT"
ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    OPNSENSE.67 > DHCPIP.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xf8cfc318, Flags [none] (0x0000)
  Your-IP DHCPIP
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: OPNSENSE
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.255.0
    Default-Gateway Option 3, length 4: OPNSENSE
    Domain-Name-Server Option 6, length 4: OPNSENSE
    Hostname Option 12, length 10: "EWS276-FIT"
    Domain-Name Option 15, length 6: "DOMAIN"

I'm not finding any sort of error in the logs indicating that it didn't pick up the option.

[CJ]

Looking through the dhcpd.conf file this is what's getting inserted.

Code: [Select]

  option custom-opt15-0 01:04:D9:1D:2D:4D;
Regardless of what I select for option type, it just appends it to that custom line.  The option number seems to be completely ignored.

[meyergru]

The option number gets inserted at the top of the file. There should be a line like this which defines the type:

Code: [Select]

option custom-opt15-0 code 43 = string;
Only the content part is in the specific subnet section.

I just tried it in 24.1.2_1 and it works.

As for why it does not show in the packet capture: I know that DHCP / BOOTP packets are rather limited in length (300 bytes). If you specify too many options, they are chopped off, AFAIR, see this. I once had to shorten the path of a tftp boot file name in order not to drop something else.

[CJ]

The option number gets inserted at the top of the file. There should be a line like this which defines the type:

Code: [Select]

option custom-opt15-0 code 43 = string;
Only the content part is in the specific subnet section.

I just tried it in 24.1.2_1 and it works.

As for why it does not show in the packet capture: I know that DHCP / BOOTP packets are rather limited in length (300 bytes). If you specify too many options, they are chopped off, AFAIR, see this. I once had to shorten the path of a tftp boot file name in order not to drop something else.

You are correct.  I hadn't paid enough attention to the beginning of the file.

This is the only option I have configured.  The only others are the routers and DNS options.  I would think it would properly handle that.

[meyergru]

According to RFC 1048, the vendor extensions are only 64 bytes. From your packet dump, you can see that there are these options within that field already:

Code: [Select]

  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: OPNSENSE
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.255.0
    Default-Gateway Option 3, length 4: OPNSENSE
    Domain-Name-Server Option 6, length 4: OPNSENSE
    Hostname Option 12, length 10: "EWS276-FIT"
    Domain-Name Option 15, length 6: "DOMAIN"

These add up to 4+3+6+6+6+6+6+12+8 = 57 bytes, so the option 43 (which takes up 6 bytes) will most probably not fit in. Maybe there is yet another field that did not make it in before that.

You could try to set "option dhcp-option-overload".

[CJ]

According to RFC 1048, the vendor extensions are only 64 bytes. From your packet dump, you can see that there are these options within that field already:

Code: [Select]

  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: OPNSENSE
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.255.0
    Default-Gateway Option 3, length 4: OPNSENSE
    Domain-Name-Server Option 6, length 4: OPNSENSE
    Hostname Option 12, length 10: "EWS276-FIT"
    Domain-Name Option 15, length 6: "DOMAIN"

These add up to 4+3+6+6+6+6+6+12+8 = 57 bytes, so the option 43 (which takes up 6 bytes) will most probably not fit in. Maybe there is yet another field that did not make it in before that.

You could try to set "option dhcp-option-overload".

I get what you're saying, but where I'm struggling is with the fact that this is a default OPNsense configuration.  Create an interface, turn on DHCP, and set option 43.  That's it.  And yet somehow there's not room for the option?  If it doesn't fit I can't imagine how something like a TFTP boot path would.

In any case, I think something else is going on with my setup.  I removed the static lease, which is what was causing the hostname option to be included, but all that did is remove it.  No additional options showed up.  Here is the packet capture for that.  I also realized I didn't include the full handshake but I don't think it makes a difference.

Code: [Select]

ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC, length 300, xid 0x52f35c59, Flags [none] (0x0000)
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Discover
    Requested-IP Option 50, length 4: 192.168.1.1
    MSZ Option 57, length 2: 576
    Parameter-Request Option 55, length 7:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
      Domain-Name, BR, NTP
    Vendor-Class Option 60, length 10: "EngeniusAP"
    Hostname Option 12, length 10: "EWS276-FIT"

ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    OPNSENSE.67 > DHCPIP.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x52f35c59, Flags [none] (0x0000)
  Your-IP DHCPIP
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Offer
    Server-ID Option 54, length 4: OPNSENSE
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.255.0
    Default-Gateway Option 3, length 4: OPNSENSE
    Domain-Name-Server Option 6, length 4: OPNSENSE
    Domain-Name Option 15, length 6: "DOMAIN"

ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from MAC, length 300, xid 0x52f35c59, secs 1, Flags [none] (0x0000)
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: Request
    Requested-IP Option 50, length 4: DHCPIP
    Server-ID Option 54, length 4: OPNSENSE
    MSZ Option 57, length 2: 576
    Parameter-Request Option 55, length 7:
      Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
      Domain-Name, BR, NTP
    Vendor-Class Option 60, length 10: "EngeniusAP"
    Hostname Option 12, length 10: "EWS276-FIT"

ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    OPNSENSE.67 > DHCPIP.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x52f35c59, secs 1, Flags [none] (0x0000)
  Your-IP DHCPIP
  Client-Ethernet-Address MAC
  Vendor-rfc1048 Extensions
    Magic Cookie 0x63825363
    DHCP-Message Option 53, length 1: ACK
    Server-ID Option 54, length 4: OPNSENSE
    Lease-Time Option 51, length 4: 7200
    Subnet-Mask Option 1, length 4: 255.255.255.0
    Default-Gateway Option 3, length 4: OPNSENSE
    Domain-Name-Server Option 6, length 4: OPNSENSE
    Domain-Name Option 15, length 6: "DOMAIN"
Hopefully someone with a working option 43 can post a packet capture from their setup.  I plan on upgrading to 24 soon but I haven't had a large enough period of available downtime in case I run into any problems.  Even though upgrades are usually quick and painless, I like to make sure I have the time.

[CJ]

I figured out why option 43 isn't showing up.  ISC is only sending back the specific options that the client is asking for since it's providing a list via option 55.

In order to get option 43 to be sent I need to set my own option 55 that sets all of the options to send to the client.  There doesn't seem to be a way to just add options, so every option needs to be explicitly declared.  Also, it apparently needs to be done via hex, so option 43 ends up being 2B.

[meyergru]

It does not have to be specified in hex in dhcpd.conf: I am quite sure that it is 43 in the config file. This is the decimal code for a vendor-specific option assigned by IANA.

Every working example I have seen that does not use the more specific "option space" variant has 43 in it.

Correct on the client option 55. You client also allows for more than 300 bytes via client option 57. So you simply looked at answers for the wrong client type.

I just had the "usual" settings (as described, 43 decimal, string encoding and 01:04:c0:a8:66:14 as value) and got this from a Unifi AP request:

Code: [Select]

# tcpdump -i igc0_vlan6 -e -n -vv udp port 67 or port 68
tcpdump: listening on igc0_vlan6, link-type EN10MB (Ethernet), capture size 262144 bytes
19:36:50.630652 70:a7:41:44:44:44 > 00:e2:69:44:44:44, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 41318, offset 0, flags [DF], proto UDP (17), length 328)
    192.168.66.27.68 > 192.168.66.2.67: [udp sum ok] BOOTP/DHCP, Request from 70:a7:41:44:44:44, length 300, xid 0xb47ad23, Flags [none] (0x0000)
          Client-IP 192.168.66.27
          Client-Ethernet-Address 70:a7:41:44:44:44
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 70:a7:41:44:44:44
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 8:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Vendor-Option
            Vendor-Class Option 60, length 4: "ubnt"
            Hostname Option 12, length 5: "anvil"
19:36:50.631121 00:e2:69:44:44:44 > 70:a7:41:44:44:44, ethertype IPv4 (0x0800), length 345: (tos 0x0, ttl 64, id 47339, offset 0, flags [none], proto UDP (17), length 331)
    192.168.66.2.67 > 192.168.66.27.68: [udp sum ok] BOOTP/DHCP, Reply, length 303, xid 0xb47ad23, Flags [none] (0x0000)
          Client-IP 192.168.66.27
          Your-IP 192.168.66.27
          Server-IP 192.168.66.7
          Client-Ethernet-Address 70:a7:41:44:44:44
          file "netboot.xyz.kpxe"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 192.168.66.2
            Lease-Time Option 51, length 4: 1440
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.66.2
            Domain-Name-Server Option 6, length 4: 192.168.66.2
            Hostname Option 12, length 5: "anvil"
            Domain-Name Option 15, length 6: "tarzan"
            NTP Option 42, length 4: 192.168.66.2
            Vendor-Option Option 43, length 6: 1.4.192.168.66.20

So, this "just works". As you can see, the Unifi AP also accepts up to 576 octets (and there are only 303), plus it requests "Vendor-Option" explicitely. I also tried specifying something longer, namely a domain search list. It was neither requested via option 55 nor delivered by dhcpd.

[CJ]

It does not have to be specified in hex in dhcpd.conf: I am quite sure that it is 43 in the config file. This is the decimal code for a vendor-specific option assigned by IANA.

Every working example I have seen that does not use the more specific "option space" variant has 43 in it.

Correct on the client option 55. You client also allows for more than 300 bytes via client option 57. So you simply looked at answers for the wrong client type.

I just had the "usual" settings (as described, 43 decimal, string encoding and 01:04:c0:a8:66:14 as value) and got this from a Unifi AP request:

Code: [Select]

# tcpdump -i igc0_vlan6 -e -n -vv udp port 67 or port 68
tcpdump: listening on igc0_vlan6, link-type EN10MB (Ethernet), capture size 262144 bytes
19:36:50.630652 70:a7:41:44:44:44 > 00:e2:69:44:44:44, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 64, id 41318, offset 0, flags [DF], proto UDP (17), length 328)
    192.168.66.27.68 > 192.168.66.2.67: [udp sum ok] BOOTP/DHCP, Request from 70:a7:41:44:44:44, length 300, xid 0xb47ad23, Flags [none] (0x0000)
          Client-IP 192.168.66.27
          Client-Ethernet-Address 70:a7:41:44:44:44
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Client-ID Option 61, length 7: ether 70:a7:41:44:44:44
            MSZ Option 57, length 2: 576
            Parameter-Request Option 55, length 8:
              Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
              Domain-Name, BR, NTP, Vendor-Option
            Vendor-Class Option 60, length 4: "ubnt"
            Hostname Option 12, length 5: "anvil"
19:36:50.631121 00:e2:69:44:44:44 > 70:a7:41:44:44:44, ethertype IPv4 (0x0800), length 345: (tos 0x0, ttl 64, id 47339, offset 0, flags [none], proto UDP (17), length 331)
    192.168.66.2.67 > 192.168.66.27.68: [udp sum ok] BOOTP/DHCP, Reply, length 303, xid 0xb47ad23, Flags [none] (0x0000)
          Client-IP 192.168.66.27
          Your-IP 192.168.66.27
          Server-IP 192.168.66.7
          Client-Ethernet-Address 70:a7:41:44:44:44
          file "netboot.xyz.kpxe"
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 192.168.66.2
            Lease-Time Option 51, length 4: 1440
            Subnet-Mask Option 1, length 4: 255.255.255.0
            Default-Gateway Option 3, length 4: 192.168.66.2
            Domain-Name-Server Option 6, length 4: 192.168.66.2
            Hostname Option 12, length 5: "anvil"
            Domain-Name Option 15, length 6: "tarzan"
            NTP Option 42, length 4: 192.168.66.2
            Vendor-Option Option 43, length 6: 1.4.192.168.66.20

So, this "just works". As you can see, the Unifi AP also accepts up to 576 octets (and there are only 303), plus it requests "Vendor-Option" explicitely. I also tried specifying something longer, namely a domain search list. It was neither requested via option 55 nor delivered by dhcpd.

I'm just going by what the ISC docs say and what I was able to get to work.  https://kb.isc.org/docs/aa-00334

I'm not following the rest of your example.  The whole reason 55 isn't required for Ubiquiti is because it requests 43.  I have no idea why the Engenius AP doesn't despite their documentation specifying that it's used the same way.  I'm not sure how other DHCP servers handle option 55.  I've also found out that different AP manufacturers want different things in option 43.  Unfortunately I can't find an example online for Engenius and I'm still waiting for the company to respond with the proper format.

[meyergru]

I'm just going by what the ISC docs say and what I was able to get to work.  https://kb.isc.org/docs/aa-00334

That bit refers to the content of the option, not the number by which it goes.

I'm not following the rest of your example.  The whole reason 55 isn't required for Ubiquiti is because it requests 43.

Right. Client request option 55 is used to request specific server response options (like 43). I never said anything about specifying option 55 yourself. It is only that both your AP and Unifi APs use option 55, plus Unifi actually requests server option 43 (Vendor-Option). The Engenius does use option 55, but does not request the vendor-option, which makes no sense at all if it can use it.

I have no idea why the Engenius AP doesn't despite their documentation specifying that it's used the same way. 
I'm not sure how other DHCP servers handle option 55. 

Neither do I. An considering that they say they use option 43, this is even more mysterious, especially considering that ISC-DHCP is so widespread that it factually sets the standard.

I've also found out that different AP manufacturers want different things in option 43.  Unfortunately I can't find an example online for Engenius and I'm still waiting for the company to respond with the proper format.

The standard states that 43 is a vendor-specific option. Every vendor can do whatever he likes with that. This is the main reason why Unifi usually proposes to use an intelligent match to see if the requestor wants to see the Unifi-specific data in option 43. You can see that in my linked example for the "option space" variant. They use something like:

Code: [Select]

match if substring (option vendor-class-identifier, 0, 4) = "ubnt";

which matches only for Unifi devices. That is beyond the GUI configuration abilities of OpnSense.

Alas, the Engenius documentation says: "Utilize DHCP option43 to send FitController service IP to devices", but states no details. Every vendor has its own variant, as I said. You can see a fair amount of variants here. Still, you will have to rely on Engenius about what the actually want.

[CJ]

I'm just going by what the ISC docs say and what I was able to get to work.  https://kb.isc.org/docs/aa-00334

That bit refers to the content of the option, not the number by which it goes.

Yes.  And the content of the option is the numbers of the other options, but in hex.  Hence my comment that 43 has to be done as 2B.

I'm not following the rest of your example.  The whole reason 55 isn't required for Ubiquiti is because it requests 43.

Right. Client request option 55 is used to request specific server response options (like 43). I never said anything about specifying option 55 yourself. It is only that both your AP and Unifi APs use option 55, plus Unifi actually requests server option 43 (Vendor-Option). The Engenius does use option 55, but does not request the vendor-option, which makes no sense at all if it can use it.

When specified by the client, option 55 is a request for specific server response options.  But when specified on the server, it forces those specific server response options.  Not sure if other dhcp servers are that way, but that's how ISC handles it.

I've also found out that different AP manufacturers want different things in option 43.  Unfortunately I can't find an example online for Engenius and I'm still waiting for the company to respond with the proper format.

The standard states that 43 is a vendor-specific option. Every vendor can do whatever he likes with that. This is the main reason why Unifi usually proposes to use an intelligent match to see if the requestor wants to see the Unifi-specific data in option 43. You can see that in my linked example for the "option space" variant. They use something like:

Code: [Select]

match if substring (option vendor-class-identifier, 0, 4) = "ubnt";

which matches only for Unifi devices. That is beyond the GUI configuration abilities of OpnSense.

From what I can tell, it's not really needed.  There seems to be three main standards.  The 0104IP hex, just the IP, and whatever Ruckus does.

Alas, the Engenius documentation says: "Utilize DHCP option43 to send FitController service IP to devices", but states no details. Every vendor has its own variant, as I said. You can see a fair amount of variants here. Still, you will have to rely on Engenius about what the actually want.

Agreed.  The Engenius documentation can be lacking.  Unfortunately, most manufacturers are bad at addressing things other than a flat, open subnet with full internet access.  Once I get the correct info, I'll probably make a separate blog post about just it as I couldn't find it documented anywhere online.

[meyergru]

When you have the info, you could also give it to the folks running the calculator. It would come in handy if it was known and could be automated...

[CJ]

When you have the info, you could also give it to the folks running the calculator. It would come in handy if it was known and could be automated...

Which one?  There appear to be several calculators.