Re: How to extract vendor specific information from Sub-Option 9 of Option 82

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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html