Ok so i tested with the patch and it looks to be the same. Wed Nov 23 08:40:39 2016 : Debug: (1) Cisco-AVPair = "dhcp-option=\0007\000\r\001\017\003\006,./\037!y\371\374+" Wed Nov 23 08:40:39 2016 : Debug: (1) rest: Value : "dhcp-option=\u00007\u0000\r\u0001\u000F\u0003\u0006,.\/\u001F!y\uFFFFFFF9\uFFFFFFFC+" I also noticed in the code that the function vp_prints_value_json is use instead of jsonquote_xlat so i did the following patch: diff --git a/src/lib/print.c b/src/lib/print.c index 5e3a353..0bf128d 100644 --- a/src/lib/print.c +++ b/src/lib/print.c @@ -583,7 +583,7 @@ size_t vp_prints_value_json(char *out, size_t outlen, VALUE_PAIR const *vp) freespace--; break; default: - len = snprintf(out, freespace, "u%04X", *q); + len = snprintf(out, freespace, "u%04X", (uint32_t) *q); if (is_truncated(len, freespace)) return (outlen - freespace) + len; out += len; freespace -= len; diff --git a/src/modules/rlm_rest/rlm_rest.c b/src/modules/rlm_rest/rlm_rest.c index ac00171..7278a58 100644 --- a/src/modules/rlm_rest/rlm_rest.c +++ b/src/modules/rlm_rest/rlm_rest.c @@ -174,7 +174,7 @@ static ssize_t jsonquote_xlat(UNUSED void *instance, UNUSED REQUEST *request, break; case '\n': - *out++ = 'b'; + *out++ = 'n'; freespace--; break; Regards Fabrice Le 2016-11-22 à 16:27, Alan DeKok a écrit :
On Nov 22, 2016, at 3:39 PM, Fabrice Durand <fdurand@inverse.ca> wrote:
i am trying to implement cisco Device sensor (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/rele...) that allow to have endpoint data like DHCP, LLDP in the radius accounting packet.
I am able to receive these specific attributes but when i want to send them to my api (PacketFence) through rlm_rest module , it looks that these attributes are not well encoded.
You can see in the raddebug trace this attribute Cisco-AVPair = "dhcp-option=\0007\000\r\001\017\003\006,./\037!y\371\374+" received from the cisco switch which is encoded to that "dhcp-option=\u00007\u0000\r\u0001\u000F\u0003\u0006,.\/\u001F!y\uFFFFFFF9\uFFFFFFFC+" The json spec says that binary data is \uXXXX where "XXXX" is 4 hex digits. So the above *mostly* looks OK. Except for the FFFFF issue... which is a sign problem.
Fixing that should be as simple as making the data unsigned...
and i am not able to decode it.
On my side i did some test with a perl json encoding code and the encoding string is suppose to be \\0007\\000\\r\\001\\017\\003\\006,.\/\\037!y\\371\\374+ Which doesn't follow the json spec.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Fabrice Durand fdurand@inverse.ca :: +1.514.447.4918 (x135) :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence (http://packetfence.org)