Explained Example DHCP option 121/249

  • Hi folks,

    I feel like I should share this because the appropriate syntax for this DHCP option (121 or 249) was very unclear. Even from this thread https://forum.pfsense.org/index.php?topic=26755.0

    It drove me insane trying to figure this out, but finally got it.

    It appears as though, when using string as an option for these DHCP options, the data is read from right to left.  Not to say that you need to list everything backwards.  But it only makes "sense" (hehe) because zeros in your IP address, which are listed in hex, are ignored.  Additionally, multiple routes must be entered in the same field, one after another.

    To do the hex, you can use printf to convert from hex to dec and dec to hex like so:

    printf "%x\n" 192

    printf "%d\n" 0xc0

    For example:
    If you need to create a dhcp option 121 or 249 for via

    This is wrong –> 08:0a:00:00:00:ac:10:0a:01 this will yield a route statement like this via

    This is correct –> 08:0a:ac:10:0a:01 this will yield a route statement like this via

    If you send multiple static routes to your DHCP clients do it this way:
    number 121  type string      value  08:0a:ac:10:0a:7e:0c:ac:10:ac:10:0a:7e:10:c0:a8:ac:10:0a:7e

    This will yield the following routes: via via via

    Hope it helps the next guy/gal.  :)


  • This has nothing to do with reading backwards or arbitrarily ignoring zeros.

    RFC 3442 provides the message format, which is basically a list of destination networks and the corresponding gateway - and where the destination network uses a "compact encoding".

    The "compact encoding" is one octet specifying the network mask length (e.g. 8 for a /8, 23 for a /23) followed by only the significant octets of the network address. Then follows the four octets of the gateway IP address. Repeat for each route.

    In the example in this post, the destination network is which would encode as a mask of 8, followed by the significant bits of the network, 10. In decimal 8.10, or in hex, 0x08:0x0a. Then follows the router address as four octets.

    Another example encoding, from the RFC: a subnet of would result in (decimal; converting to hex is left as an exercise for the reader). So in this case all four octets must be given and the "compact encoding" doesn't really buy anything.

Log in to reply