freeradius3: filling vp_strvalue for INTEGER attributes - off by default?
Hi. We have a module that used to work in with freeradius 2.1. It has the following code: if ((vp = pairfind(request->packet->vps, PW_NAS_PORT_TYPE)) != NULL && strcmp((char const *)vp->vp_strvalue, "Wireless-802.11") == 0) In freeradius 2.1 (and configuration it had) was initialized with actual string value of this attribute, in freeradius 3.0 vp_strvalue is not initialized (causing module to crush of course). I know it is the the best to check integer value but still.. I am curious if anybody know is this a intended code change or it is a glitch in my 3.0 configuration? -- Boris Lytochkin Yandex NOC +7 (495) 739 70 00 ext. 7671
On Feb 26, 2016, at 7:46 AM, Boris Lytochkin <lytboris@yandex-team.ru> wrote:
We have a module that used to work in with freeradius 2.1. It has the following code:
if ((vp = pairfind(request->packet->vps, PW_NAS_PORT_TYPE)) != NULL && strcmp((char const *)vp->vp_strvalue, "Wireless-802.11") == 0)
NAS-Port-Type is an integer. You should be checking the integer value of the attribute, not the string value.
In freeradius 2.1 (and configuration it had) was initialized with actual string value of this attribute, in freeradius 3.0 vp_strvalue is not initialized (causing module to crush of course). I know it is the the best to check integer value but still..
It's "best" because it's correct.
I am curious if anybody know is this a intended code change or it is a glitch in my 3.0 configuration?
Your code was wrong. Check the integer value. Alan DeKok.
Hi. Yep, I did a fix and the code now works correctly. Still the question is unanswered - why 2.1 code had correct vp_strvalue and 3.0 does not. Funny thing, VALUE_PAIR_DATA in 2.1 is a union too so I have no idea how the code below ever worked. :) On 26.02.2016 16:16, Alan DeKok wrote:
On Feb 26, 2016, at 7:46 AM, Boris Lytochkin <lytboris@yandex-team.ru> wrote:
We have a module that used to work in with freeradius 2.1. It has the following code:
if ((vp = pairfind(request->packet->vps, PW_NAS_PORT_TYPE)) != NULL && strcmp((char const *)vp->vp_strvalue, "Wireless-802.11") == 0) NAS-Port-Type is an integer. You should be checking the integer value of the attribute, not the string value.
In freeradius 2.1 (and configuration it had) was initialized with actual string value of this attribute, in freeradius 3.0 vp_strvalue is not initialized (causing module to crush of course). I know it is the the best to check integer value but still.. It's "best" because it's correct.
I am curious if anybody know is this a intended code change or it is a glitch in my 3.0 configuration? Your code was wrong. Check the integer value.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
-- Boris Lytochkin Yandex NOC +7 (495) 739 70 00 ext. 7671
On Feb 26, 2016, at 8:59 AM, Boris Lytochkin <lytboris@yandex-team.ru> wrote:
Yep, I did a fix and the code now works correctly. Still the question is unanswered - why 2.1 code had correct vp_strvalue and 3.0 does not. Funny thing, VALUE_PAIR_DATA in 2.1 is a union too so I have no idea how the code below ever worked. :)
In 2.0, vp_strvalue was a fixed-length array in all VALUE_PAIRs. So it's possible to put a string value there for non-string attributes. The problem was that the array was fixed length. So longer attributes were impossible. Even ones which were used internally, and didn't go into a RADIUS packet. In 3.0, vp_strvalue is a pointer to a character array. That character array can be any length. As a result, we can have attributes of any length. But... there's no longer a fixed-length array associated with an "integer" attribute. So you can't look at the vp_strvalue, because it doesn't exist. Alan DeKok.
participants (2)
-
Alan DeKok -
Boris Lytochkin