HI Alan Many thanks for your quick response.
We have a device which sends individual traffic counters for several
different services. The dicitionary is as follows:
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
...
ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 17 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 18 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 19 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 20 integer64
That might work...
In the accounting packet these attribtues are grouped into individual VSAs as follows:
If you want *real* grouping, you need to use TLVs. i.e. one master attribute, and the sub-attributes within that.
Here the fact that the five attributes are gouped together in a single VSA means that they all contain data which pertains to the same service.
That's what you mean. But that's not how RADIUS works. The attributes are all in a flat space.
When FreeRADIUS processes the packet the attribtues are as I understand it added to one long list and I can access them individually by their index.
Yes.
However, as I understand it the ordering of RADIUS attributes is not something which is normally guaranteed
RADIUS guarantees ordering of attributes which have the same number. It does NOT guarantee ordering of attributes which have a different number.
This restriction applies to VSAs, soo.
and I would like to ask is whether there is any way in unlang or by other means to figure out which which sub attribtues came from the same parent attribute.
No. But you can fix the dictionary:
VENDOR VasExperts 43823
BEGIN-VENDOR VasExperts
... ATTRIBUTE VasExperts-Acct-Traffic 16 tlv ATTRIBUTE VasExperts-Acct-Traffic-Class-Name 16.1 string ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Octets 16.2 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Octets 16.3 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Input-Packets 16.4 integer64 ATTRIBUTE VasExperts-Acct-Traffic-Class-Output-Packets 16.5 integer64 ...
These attributes will be packed into one parent attribute: VasExperts-Acct-Traffic. And ordering of THAT attribute is guaranteed.
I am slightly confused. At the moment the sub-attribtues are grouped into parent attributes of type Vendor-Specific (26) and presumably the ordering of this attribute is preserved (as the numnber 26 is the same). As I understand it the important thing is that the ordering of the sub-attributes is preserved after flattening. For example I receive two VSAs: Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class1" , VasExperts-Acct-Traffic-Class-Output-Octets = 10] Vendor-Specific = [VasExperts-Acct-Traffic-Class-Name = "class2" , VasExperts-Acct-Traffic-Class-Output-Octets = 20] Here 10 bytes of "class1" data were downloaded and 20 bytes of "class2" data. After flattening I would like: VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Name = "class2 VasExperts-Acct-Traffic-Class-Output-Octets = 20 The following variations would also be kind of OK: VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 or VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Name = "class2" or ... However any variation where the ordering of VasExperts-Acct-Traffic-Class-Name is not the same as the ordering of VasExperts-Acct-Traffic-Class-Output-Octets after flattening would be a problem: VasExperts-Acct-Traffic-Class-Name = "class2" VasExperts-Acct-Traffic-Class-Name = "class1" VasExperts-Acct-Traffic-Class-Output-Octets = 10 VasExperts-Acct-Traffic-Class-Output-Octets = 20 But as far as I can see this can't happen so there is actually no problem at all