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