Decoding HEX data in accounting interim-updates

[Callum Barr]

Thank you so much Arran - just what I was after :)





On 19/03/14 11:19 am, "Arran Cudbard-Bell" <a.cudbardb at freeradius.org>
wrote:

>
>> We have an Alcatel-Lucent 7750SR ­
>
>Oh, i'm sorry.
>
>> when it sends its interim-updates ­ we
>> get an output like the following;
>> 
>> 	Alc-Acct-O-statmode = "0x1 v4-v6"
>> 	Alc-Acct-O-Inprof-Octets-64 = 0x0001000000000002a19e
>> 	Alc-Acct-O-Outprof-Octets-64 = 0x00010000000000000000
>> 	Alc-Acct-O-Inprof-Pkts-64 = 0x00010000000000000e32
>> 	Alc-Acct-O-Outprof-Pkts-64 = 0x00010000000000000000
>> 	Alc-Acct-O-statmode = "0x2 v4-v6"
>> 	Alc-Acct-O-Inprof-Octets-64 = 0x00020000000000000000
>> 	Alc-Acct-O-Outprof-Octets-64 = 0x00020000000000000000
>> 	Alc-Acct-O-Inprof-Pkts-64 = 0x00020000000000000000
>> 	Alc-Acct-O-Outprof-Pkts-64 = 0x00020000000000000000
>> 	Alc-Acct-O-statmode = "0x3 v4-v6"
>> 	Alc-Acct-O-Inprof-Octets-64 = 0x00030000000000000000
>> 	Alc-Acct-O-Outprof-Octets-64 = 0x00030000000000000000
>> 	Alc-Acct-O-Inprof-Pkts-64 = 0x00030000000000000000
>> 	Alc-Acct-O-Outprof-Pkts-64 = 0x00030000000000000000
>> 	Alc-Acct-I-statmode = "0x8001 v4-v6"
>> 	Alc-Acct-I-Hiprio-Octets_64 = 0x80010000000000012442
>> 	Alc-Acct-I-Lowprio-Octets_64 = 0x80010000000000000000
>> 	Alc-Acct-I-Hiprio-Packets_64 = 0x80010000000000000996
>> 	Alc-Acct-I-Lowprio-Packets_64 = 0x80010000000000000000
>> 	Alc-Acct-I-statmode = "0x8002 v4-v6"
>> 	Alc-Acct-I-Hiprio-Octets_64 = 0x80020000000000000000
>> 	Alc-Acct-I-Lowprio-Octets_64 = 0x80020000000000000000
>> 	Alc-Acct-I-Hiprio-Packets_64 = 0x80020000000000000000
>> 	Alc-Acct-I-Lowprio-Packets_64 = 0x80020000000000000000
>> 	Alc-Acct-I-statmode = "0x8003 v4-v6"
>> 	Alc-Acct-I-Hiprio-Octets_64 = 0x80030000000000000000
>> 	Alc-Acct-I-Lowprio-Octets_64 = 0x80030000000000000000
>> 	Alc-Acct-I-Hiprio-Packets_64 = 0x80030000000000000000
>> 	Alc-Acct-I-Lowprio-Packets_64 = 0x80030000000000000000
>> 
>> 
>> Each of the Alc-Acct-I-Hiprio-Octets_64 counters are formatted as
>>follows;
>> 
>> Eg. 0x80010000000000012442 where the first 2B represent the queue ID and
>> the last 8B represent the octet counter in hex.
>> 
>> So ­ queue 1, 74818 octets
>> 
>> How can I manipulate the data to put it into our database correctly?
>
>if (Alc-Acct-I-Hiprio-Octets_64 =~ /^([0-9a-f]{4})([0-9a-f]+)/) {
>	update request {
>		Tmp-Octets-0 := "%{1}"
>		Tmp-Octets-1 := "%{2}"
>	}
>	update request {
>		# Queue ID
>		Tmp-Integer-0 := "%{integer:Tmp-Octets-0}"
>		
>		# Counter
>		Tmp-Integer64-0 := "%{integer:Tmp-Octets-1}"
>	}
>}
>
>Pfft, tags, why group information together when you can munge it into
>the same attribute value?
>
>You'll need to use one of the later 3.0.x versions where "%{integer:}"
>can integerise most attribute types. Just re-reading the code...
>it assumes the octet string in the attribute is network order, so you
>should be OK with byte order.
>
>If Alcatel have done something truly bizarre and used a little endian
>encoding (which it doesn't look like they have). We could add a htons
>xlat. eww.
>
>Or you could write your own module and register a custom xlat, which'd
>be the more efficient way of doing the conversion.
>
>Arran Cudbard-Bell <a.cudbardb at freeradius.org>
>FreeRADIUS Development Team
>
>FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>