Radius event field in wrong format - latest source version

[ivlovric]

In latest compiled version on which we are testing our accounting and comparing latest build from source build with latest public release there are differences in some radius decoded fields.

For instance, we are monitoring for Radius accounting STOP events and our STOP event definition looks like this:

"Stop,%{NAS-IP-Address},%{NAS-Port},%{Acct-Session-Id},%{Acme-Session-Ingress-CallId},%{Acme-Session-Egress-CallId},%{Acme-Session-Protocol-Type},%{Calling-Station-Id},%{Called-Station-Id},%{Acct-Terminate-Cause},%{Acct-Session-Time},%{h323-setup-time},%{h323-connect-time},%{h323-disconnect-time},%{h323-disconnect-cause},%{Acme-P-Asserted-ID},%{Acme-Egress-Network-Interface-Id},%{Acme-Egress-Vlan-Tag-Value},%{Acme-Ingress-Network-Interface-Id},%{Acme-Ingress-Vlan-Tag-Value},%{Acme-Session-Egress-Realm},%{Acme-Session-Ingress-Realm},%{Acme-FlowID_FS1_F},%{Acme-FlowType_FS1_F},%{Acme-Flow-In-Realm_FS1_F},%{Acme-Flow-In-Src-Addr_FS1_F},%{Acme-Flow-In-Src-Port_FS1_F},%{Acme-Flow-In-Dst-Addr_FS1_F},%{Acme-Flow-In-Dst-Port_FS1_F},%{Acme-Flow-Out-Realm_FS1_F},%{Acme-Flow-Out-Src-Addr_FS1_F},%{Acme-Flow-Out-Src-Port_FS1_F},%{Acme-Flow-Out-Dst-Addr_FS1_F},%{Acme-Flow-Out-Dst-Port_FS1_F},%{Acme-Calling-RTCP-Packets-Lost_FS1},%{Acme-Calling-RTCP-Avg-Jitter_FS1},%{Acme-Calling-RTCP-Avg-Latency_FS1},%{Acme-Calling-RTCP-MaxJitter_FS1},%{Acme-Calling-RTCP-MaxLatency_FS1},%{Acme-Calling-RTP-Packets-Lost_FS1},%{Acme-Calling-RTP-Avg-Jitter_FS1},%{Acme-Calling-RTP-MaxJitter_FS1},%{Acme-Calling-Octets_FS1},%{Acme-Calling-Packets_FS1},%{Acme-Calling-R-Factor},%{Acme-Calling-MOS},%{Acme-FlowID_FS1_R},%{Acme-FlowType_FS1_R},%{Acme-Flow-In-Realm_FS1_R},%{Acme-Flow-In-Src-Addr_FS1_R},%{Acme-Flow-In-Src-Port_FS1_R},%{Acme-Flow-In-Dst-Addr_FS1_R},%{Acme-Flow-In-Dst-Port_FS1_R},%{Acme-Flow-Out-Realm_FS1_R},%{Acme-Flow-Out-Src-Addr_FS1_R},%{Acme-Flow-Out-Src-Port_FS1_R},%{Acme-Flow-Out-Dst-Addr_FS1_R},%{Acme-Flow-Out-Dst-Port_FS1_R},%{Acme-Called-RTCP-Packets-Lost_FS1},%{Acme-Called-RTCP-Avg-Jitter_FS1},%{Acme-Called-RTCP-Avg-Latency_FS1},%{Acme-Called-RTCP-MaxJitter_FS1},%{Acme-Called-RTCP-MaxLatency_FS1},%{Acme-Called-RTP-Packets-Lost_FS1},%{Acme-Called-RTP-Avg-Jitter_FS1},%{Acme-Called-RTP-MaxJitter_FS1},%{Acme-Called-Octets_FS1},%{Acme-Called-Packets_FS1},%{Acme-Called-R-Factor},%{Acme-Called-MOS},%{Acme-Firmware-Version},%{Acme-Local-Time-Zone},%{Acme-Post-Dial-Delay},%{Acme-Primary-Routing-Number},%{Acme-Ingress-Local-Addr},%{Acme-Ingress-Remote-Addr},%{Acme-Egress-Local-Addr},%{Acme-Egress-Remote-Addr},%{Acme-Session-Disposition},%{Acme-Disconnect-Initiator},%{Acme-Disconnect-Cause},%{Acme-SIP-Status},%{Acme-Egress-Final-Routing-Number},%{Acme-CDR-Sequence-Number},%{Client-IP-Address},%{Acct-Unique-Session-Id}"

What is different from latest public build 3.0.17 (correct value of field Acct-Unique-Session-Id) and latest compiled source code is last field in above example of stop accounting definition "Acct-Unique-Session-Id"

• in 3.0.17. that field was like this, real example: "2ed48cd17d0d1ebbb1b2c207f714615c" in
• in latest compiled radius version we get this field in this way: "\225\355\241\347\372\364\"\206\256\262\351Z\021\333&\247"

problematic field in /var/log/radius/radacct/ example: "\371궣\375\214\324\032\224y\036\200\005\242\351\220" problematic field written in linelog module "�u�[p�^f�5G ��}b"

Thanks

[alandekok]

You need to post the debug output. The template for opening an issue says this VERY clearly.

[ivlovric]

radius-accounting-latestcompiled-sessionid-wrong.txt

Sorry for that. Here is accounting Stop event captured while running "radiusd -X". Hope that is enough.

[alandekok]

(31) done request (31) finished request.

You are running the git "master" branch. Not v3.0.x

If you want to use the latest version of v3.0.x, you need touse the v3.0.x branch.

If you want to run "master" branch, then you can do that. But the behavior of the server is different from v3.0.x, and these differences are not bugs.

[arr2036]

Exactly @alandekok this is intended behaviour. There's no implicit conversion to hex at the end of value box aggregation/concatenation in the xlat code. In some cases, this is useful as the octets type contained textual data anyway. We could change this so that octets boxes in the final aggregation are auto-converted to hex, but we want to avoid doing this during nested xlat calls as its useful to have the unmolested output of nested calls passed as arguments to the calling xlat function.

Anyway, whatever the behaviour of the code doing the final conversion to a printable string, it's pretty easy to work around. Just use "%{hex:Acct-Unique-Session-ID}".