On Apr 28, 2015, at 10:25 AM, Juan Pablo L. <jpablolorenzetti@hotmail.com> wrote:
Hi Alex, thanks for your prompt answer as always, i have added all code related to the management of this field, i m certainly that i m doing it wrong but cant see where .. am i missing some code to make this work ? as far as i knew:
1. i needed to add the field in the dictionary (new field is 90.3): # The next set of attributes contain sub-types ATTRIBUTE 3GPP2-Prepaid-Acct-Quota 90 tlv ATTRIBUTE 3GPP2-Prepaid-Acct-Quota-QuotaIDentifier 90.1 integer ATTRIBUTE 3GPP2-Prepaid-Acct-Quota-VolumeQuota 90.2 integer ATTRIBUTE 3GPP2-Prepaid-Acct-Quota-VolumeQuotaOverflow 90.3 integer
Note that is "integer". i.e. 4 octets.
4. access the value in the module: volume_quota_overflow->vp_integer
That should all work.
those are the steps that i m following but there is something wrong because regardless of what i do in the module code freeradius does not recognise the field when the request comes in anyways so i think anything after that will fail too.
freeradius still shows this field in the logs as: Attr-26.5535.90.3 = 0x0000
i.e. 2 octets. You're getting that value because the attribute in the packet is malformed. Change the dictionary to use type "short", or fix the NAS so that it sends the correct format.
after adding the new field in the dictionary and restarting the server, what else is needed to make freeradius recognise the field, and display it properly in the logs? because maybe that is the problem, that freeradius still does not pick up the new field. thanks!!!
The NAS needs to send the attribute in the format specified by the dictionary. If the two disagree, you'll see "Attr-..." instead of "3GPP2-..." Alan DeKok.