Freeradius server randomly loses attribute value when using compound expansion in rlm_rest

[rosbly]

Our Freeradius server handles accounting requests and forwards them as HTTP/Rest requests to another application, using the rlm_rest module. We are using Freeradius 3.0.21 on CentOS 7.8

With the following rest configuration, Freeradius sometimes evaluates %{jsonquote:%{hex:&Framed-IPv6-Prefix}} as an empty string, instead of the expected hex value:

(...)
    accounting {
        tls = ${..tls}
        uri = http://127.0.0.1:{{ accounting_service_port }}/accounting
        method = 'post'
        body = 'json'
        data = '{"type":"%{jsonquote:%{Acct-Status-Type}}", \
            "accountingSessionId":"%{jsonquote:%{Acct-Session-Id}}", \
            "apn":"%{jsonquote:%{Called-Station-Id}}", \
            "msisdn":"%{jsonquote:%{Calling-Station-Id}}", \
            "ipv4":"%{jsonquote:%{Framed-IP-Address}}", \
            "framedIpv6Prefix":"%{jsonquote:%{hex:&Framed-IPv6-Prefix}}", \
            (...)

This behavior occurs very rarely (around 0.001%-0.006% of requests), and does not seem to be related with the input. Rather, one server will start repeating this behavior a few times during a short period before going back to normal, while the other servers are still 100% OK.

We took network captures of both Freeradius Radius input and its corresponding HTTP output, with examples of mismatches (IPv6 in Radius packet, empty string in corresponding Rest request). I can send you a screenshot of an example as a private message (this is production data).

By removing jsonquote, this problem disappears. "framedIpv6Prefix":"%{hex:&Framed-IPv6-Prefix}" is always correctly evaluated and we never get any empty values.

Obviously, jsonquote is superfluous after an hex expansion, but this is an unexpected behavior and it may hide a more general problem.

This bug was very hard to spot, and we could not reproduce it in our test environment even by injecting large amount of Radius requests. I suspect some data variability may be needed in order to trigger it.

Please let me know if you need more information.

Thanks for your support,
Sylvain

[arr2036]

You'll need to eliminate the different xlats involved to see if it's an issue with any of them. Try creating the value outside of the module, inserting it into a temporary attribute, and referencing that in the data section.

[rosbly]

Hi arr,

Unfortunately I won't be able to reproduce with the proposed configuration, since the system is now in production. And I could not reproduce the issue in our test environment using an injection tool.

All the information I have comes from the time when the system was not yet in use, but receiving real data.

I know this is not ideal to make further investigations.

However, we could gather this observation:

• %{hex:&Framed-IPv6-Prefix} is always correctly valued
• %{jsonquote:%{hex:&Framed-IPv6-Prefix}} sometimes yields an empty value

[arr2036]

Good to know. It's a weird one for sure. There shouldn't be any shared globals for json quote, it just uses the json-c library to do the encoding... very weird. I think it's likely to be a json-c issue if it's specific to that expansion.