Decoding HEX data in accounting interim-updates

[Arran Cudbard-Bell]

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/mailman/private/freeradius-users/attachments/20140318/c3718919/attachment.pgp>