How to extract vendor specific information from Sub-Option 9 of Option 82
Hi all, is it possible to automatically decode Vendor Specific Information from inocoming DHCP packet in freeradius 3.2.28? In DHCP Discover Option 82 -> Sub-Option 9 I am receiving vendor specific information and I'd like to have it automatically decoded. If I got the docs right, I need to create a dictionary and then the defined attributes should be accessible by %{dhcp_options:<Attribute-ref>} (after enabling dhcp mod) I am a bit struggling with writing the dictionary tbh (I've checked also the suggested dictionary.alcatel.sr and dictionary.erx). I am interested in two TLVs: enterprise number: 0000061b (dec: 1563) 03: length: 0a (dec: 10) data: 444d 5a2d 434f 532d 3032 ("DMZ-COS-02") 01: length: 0e (dec: 14) data: 4554 492d 5250 442d 504f 5254 2d30 ("ETI-RPD-PORT-0") I was able to get the information with "unpack" from DHCP-Vendor-Specific-Information but am wondering whether this can be achieved by defining a custom dictionary and using dhcp_options ? Regards -- Ľudovít Mikula
On Sep 5, 2025, at 4:31 AM, Ľudovít Mikula <ludovit.mikula@mikori.sk> wrote:
is it possible to automatically decode Vendor Specific Information from inocoming DHCP packet in freeradius 3.2.28?
The DHCP xlat just uses the normal DHCP decoder, but there are limitations.
In DHCP Discover Option 82 -> Sub-Option 9 I am receiving vendor specific information and I'd like to have it automatically decoded.
If I got the docs right, I need to create a dictionary and then the defined attributes should be accessible by %{dhcp_options:<Attribute-ref>} (after enabling dhcp mod)
The issue is that in v3, DHCP is already a "vendor" dictionary. So it can't do vendor inside of vendor.
I am a bit struggling with writing the dictionary tbh (I've checked also the suggested dictionary.alcatel.sr and dictionary.erx).
I am interested in two TLVs:
enterprise number: 0000061b (dec: 1563)
03: length: 0a (dec: 10) data: 444d 5a2d 434f 532d 3032 ("DMZ-COS-02")
01: length: 0e (dec: 14) data: 4554 492d 5250 442d 504f 5254 2d30 ("ETI-RPD-PORT-0")
I was able to get the information with "unpack" from DHCP-Vendor-Specific-Information but am wondering whether this can be achieved by defining a custom dictionary and using dhcp_options ?
Not in v3. And, of course, v4 supports this. We're using it in production with DHCP vendor options. Alan DeKok.
Thank you Alan, we're in transition to v4, but still need to support some installations on v3. I noticed an odd behavior of unpack when upacking to octets: (0) EXPAND %{unpack:&DHCP-Vendor-Specific-Information %{expr:&control:Tmp-Integer-5} integer} (0) --> 1563 (0) &Tmp-Integer-0 := 1563 (0) EXPAND %{unpack:&DHCP-Vendor-Specific-Information %{expr:&control:Tmp-Integer-5 + 4} byte} (0) --> 52 (0) &Tmp-Integer-1 := 52 (0) EXPAND %{unpack:&DHCP-Vendor-Specific-Information %{expr:&control:Tmp-Integer-5 +4 +1} octets(%{expr:&control:Tmp-Integer-1})} (0) --> 030a444d5a2d434f532d3032010e4554492d5250442d504f52542d300207756e69636173740e07000100000079000d040a666f07 (0) &Tmp-Octets-0 := 0x3033306134343464356132643433346635333264333033323031306534353534343932643532353034343264353034663532353432643330303230373735366536393633363137333734306530373030303130303030303037393030306430343061363636663037 The expand of the unpack shows correct hex value of the data, but when assigned to Tmp-Octets-0, it's hex encoded again. It's not only printed to log that way, but actually stored as such. When I unpack first byte from Tmp-Octets-0 into an integer, it's returned as value 48 (hex 30) instead of 3 (hex 03): (0) &Tmp-Integer-8 := 0 (0) update control { (0) EXPAND %{unpack:&control:Tmp-Octets-0 %{expr:&control:Tmp-Integer-8} byte} (0) --> 48 (0) &Tmp-Integer-0 := 48 The size of Tmp-Octets-0 is also 104 (double the size of the unpacked data: (0) if (&control:Tmp-Integer-0 == 1563 && "%{length:&control:Tmp-Octets-0}" >= 2) { (0) EXPAND %{length:&control:Tmp-Octets-0} (0) --> 104 Is this by design? -- Ľudovít Mikula
On Sep 5, 2025, at 12:34 PM, Ľudovít Mikula <ludovit.mikula@mikori.sk> wrote:
The expand of the unpack shows correct hex value of the data, but when assigned to Tmp-Octets-0, it's hex encoded again. It's not only printed to log that way, but actually stored as such. When I unpack first byte from Tmp-Octets-0 into an integer, it's returned as value 48 (hex 30) instead of 3 (hex 03): .. Is this by design?
If you read the documentation for the unpack module: # When "octets(len)" is used, the output is printed as hex. e.g. for # the above example with Class: # # %{unpack:&Class 4 octets(4)} # # Will return the hex string "02030405" It's not only by design, but it's documented behavior. If you want to assign that hex string to an attribute of type "octets", don't quote the string, but do add a "0x" in front of it, so that the parser knows that it should parse the hex data back to raw bytes. Alan DeKok.
participants (2)
-
Alan DeKok -
Ľudovít Mikula