Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Verifying DHCP option 121 is actually being sent

    DHCP and DNS
    2
    6
    1.7k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      dprus
      last edited by

      Hi all,

      I'm trying to get my pfSense router's DHCPD to send a static route to clients using the DHCP 121 option. I've added the following String value under "Additional BOOTP/DHCP Options":

      Option Number: 121, Type: String, Value: 18:c0:a8:02:c0:a8:01:01

      My belief is that this should cause clients to create a new route to 192.168.2.0/24 via 192.168.1.1. However, none of my clients are creating this entry when they get assigned an IP.

      I've looked at the logging in the pfSense UI and I don't see anything that seems to show the DHCP Service is actually sending the 121 option to clients. I just see the usual DHCPOFFER, ACK, etc. lines.

      So my question is if there's any way to increate the verbosity of the DHCP log file in pfSense so that it will actually show me if the 121 option is actually getting sent to clients?

      Thanks all!

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        I would do a packet capture on that and then look at what is really being sent.

        1 Reply Last reply Reply Quote 0
        • D
          dprus
          last edited by

          OK, that was a good idea and it did confirm my suspicion. This is what I see in Wireshark:

          Doesn't look like option 121 is being sent to the clients.

          1 Reply Last reply Reply Quote 0
          • D
            dprus
            last edited by

            OK, I think I figured out what the issue is because I noticed that another client on my machine requested a lease and was sent 121. I was like, WTF?! Why is 121 only being sent to certain clients?

            Well, the specific client I'm working with is setup with a static lease. It looks like when you configure an option to be sent in the DHCP Server it only gets sent to the non-static lease clients and not the static lease clients (this appears to be due to how the dhcpd.conf gets generated by the UI).

            I went into the static lease and the GUI doesn't allow you to add any options for static leases.

            Is this a bug?

            1 Reply Last reply Reply Quote 0
            • D
              dprus
              last edited by

              OK, I think I figured out exactly what's going on. Turns out it's not a "bug" but a missing feature.

              The issue is that the client that was not receiving option 121 was sending out a specific list of options it wanted the DHCP server to send. By default the ISC DHCP Server that pfSense uses adhere's to the client's request and, since the client doesn't explicitly request option 121, it doesn't send it.

              Turns out the ISC DHCP Server does support the ability to force an option to be sent even if a client doesn't request it but that functionality is not exposed in the GUI. There is a pretty old feature request that already exists to enable this functionality in the pfSense UI: https://redmine.pfsense.org/issues/4899

              Good news is that there is a workaround. I edited "/etc/inc/services.inc" and right after the line "{$custoptions}" I added: "option dhcp-parameter-request-list 121,249;" which tells the ISC DHCP Server to always send both options 121 and 249 whether or not the clients explicitly request them. And, it worked!

              Hopefully that feature request above will be approved / implemented someday so that the Advanced Options listed in the GUI for the DHCP Server will have a checkbox alongside each option that says something like "forcefully send this to clients even if they don't explicitly request it".

              1 Reply Last reply Reply Quote 0
              • KOMK
                KOM
                last edited by

                Bear in mind that your change will likely get overwritten at the next pfSense upgrade.

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.