TBH, the simplest thing is to *not* use "foreach". I'd guess that the Cisco- AVPair attributes come in the same order all the time. So you can just rely on that. e.g.
if (Cisco-AVPair[0] =~ /^dhcp-option=/) { update request { Tmp-Integer-0 := "%{unpack:&Cisco-AVPair[0] 12 integer}" } }
That will get you the binary data (4 octets) into Tmp-Integer-0.
Thank you Alan. It works. AVPs always come in the same order. The unpacked data looks correctly. The last modest question yet - how the get the rest of the attribute (string following the TLV binary code)?
i.e. *manually* check that Cisco-AVPair[0] is the "dhcp-option". Then, *manually* check that the binary data you want is at byte offset 12. And then write an "unpack" rule to do that...
Alan DeKok.
-
On Feb 26, 2018, at 4:38 AM, Kylián Martin <kylianm@plzen.eu> wrote:
TBH, the simplest thing is to *not* use "foreach". I'd guess that the Cisco- AVPair attributes come in the same order all the time. So you can just rely on that. e.g.
if (Cisco-AVPair[0] =~ /^dhcp-option=/) { update request { Tmp-Integer-0 := "%{unpack:&Cisco-AVPair[0] 12 integer}" } }
That will get you the binary data (4 octets) into Tmp-Integer-0.
Thank you Alan. It works. AVPs always come in the same order. The unpacked data looks correctly. The last modest question yet - how the get the rest of the attribute (string following the TLV binary code)?
Keep using %{unpack: ... } Alan DeKok
participants (2)
-
Alan DeKok -
Kylián Martin