DHCP server lease-script: is client-sent option 55 (Parameter Request List) accessible?

RouterOS
1

Goal

I'm building a DHCP fingerprinting system. When a client gets a lease, the router calls an HTTP endpoint with client DHCP options (opt12, opt55, opt60, opt61) for device identification.

What I found

The documentation states lease-options in the lease-script is "an array of received options" but does not clarify whether this means client-sent or server-sent options.

After testing, lease-options only contains server-sent options from the ACK packet:

DHCP-OPT kLen=1 vLen=4 v=\FF\FF\FF\00     ← opt1  subnet mask
DHCP-OPT kLen=2 vLen=5 v=local            ← opt15 domain
DHCP-OPT kLen=1 vLen=4 v=\C0\A8\A8\FA    ← opt3  router
DHCP-OPT kLen=2 vLen=8 v=\C0\A8\A8\FA    ← opt42 NTP (2 servers)
DHCP-OPT kLen=2 vLen=4 v=\00\01Q\80      ← opt51 lease time
DHCP-OPT kLen=2 vLen=1 v=\05             ← opt53 msg type
DHCP-OPT kLen=2 vLen=4 v=\C0\A8\A8\FA   ← opt54 server ID
DHCP-OPT kLen=1 vLen=8 v=\C0\A8...      ← opt6  DNS

Client-sent options (opt55, opt60, opt61) are not present. opt60 and opt61 are retrievable from the lease record via:

[/ip dhcp-server lease get [find where active-address=$leaseIP] class-id]
[/ip dhcp-server lease get [find where active-address=$leaseIP] client-id]

But opt55 (Parameter Request List) is nowhere accessible.

tcpdump confirms the client is sending opt55:

Parameter-Request (55), length 11:
  Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
  Domain-Name (15), MTU (26), Static-Route (33), NTP (42)
  URL (114), Unknown (120), Classless-Static-Route (121)

Question

Is there any way to access client-sent DHCP options — specifically option 55 — from within the DHCP server lease-script? If not, is this a known limitation or is there a feature request tracking it?

The script used for testing:

:foreach k,v in=$"lease-options" do={
    :local key [:tostr $k];
    :local val [:tostr $v];
    :local keyLen [:len $key];
    :local valLen [:len $val];
    :log info ("DHCP-OPT kLen=" . $keyLen . " vLen=" . $valLen . " v=" . $val);
}
2

Unfortunately parameters provided to DHCP server lease scripts are quite limited:

  • The script is called after the lease is provided, it is not possible to modify/add sent options by script logic before the lease is provided
  • Except option 43 in vendor-specific variable, there is no access to option request sent by clients (an "array of received options" in docs is misleading, as already you figured out its actually the sent options)

There are rare mentions of this in the forum, as the main use case seems to be creating/removing static DNS entries for DHCP clients what works with current limitations.
Its still worth to direct a feature request at Mikrotik

The closes currently possible is enabling DHCP Debug log showing all options sent by clients in the log and gather statistics from there.

3

In my humble opinion, to solve the problem you are facing, it would be more appropriate to use /tool/sniffer on the router and dumpcap/tshark on the additional server.

/tool/sniffer on the router should be configured to filter incoming client-sent DHCP request packets and redirect them via streaming to the aforementioned additional server. The additional server in this setup is needed to automatically capture DHCP packets, streamed to it by the router via /tool/sniffer, and parse them by tshark to obtain client fingerprint.

The disadvantage of the approach I propose is the need to install this additional server, as well as the need to develop and implement a packet capture and decoding system based on dumpcap/tshark running as a service on this server.