Networking

NAVIGATION
CATEGORIES
REFERRENCE
LINKS
  • Possible Bug in valuepair / rlm_file etc etc.

    2 answers - 1031 bytes - related search similar search Add To My Delicious Add To My Stumble Upon Add To My Google Mark Add To My Facebook Add To My Digg Add To My Reddit

    Alister Winfield <alister.winfield (AT) uk (DOT) easynet.netwrote:
    I have found a potential bug in the way rlm_file or valuepair does the
    xlat of %{var} items. These are supposedly dynamic, being based on a
    per-packet replacement. The following example can be done a different
    way but its the simplest example I can think of ;-)
    Yeah, it's a bug. The "users" file originally didn't have variable
    expansion, and once we added it, things like this happen.
    Am I missing something here and if not I'll be back soon with a complete
    patch (Currently I just save the old check_item and put it back which is
    fine in a single thread but not so clever in a threaded system).
    Rather, if flags.xlat is set, do:
    VALUE_PAIR *new_check = rad_malloc(sizeof(*new_check));
    memcpy(new_check, check, sizeof(*new_check));
    new_check->next = NULL
    paircmp( new_check)
    pairfree(&new_check);
    Alan DeKok.
    -
    List info/subscribe/unsubscribe? See
  • No.1 | | 1704 bytes | |

    Fri, 2005-10-21 at 13:51 -0400, Alan DeKok wrote:
    Alister Winfield <alister.winfield (AT) uk (DOT) easynet.netwrote:
    I have found a potential bug in the way rlm_file or valuepair does the
    xlat of %{var} items. These are supposedly dynamic, being based on a
    per-packet replacement. The following example can be done a different
    way but its the simplest example I can think of ;-)

    Yeah, it's a bug. The "users" file originally didn't have variable
    expansion, and once we added it, things like this happen.

    Am I missing something here and if not I'll be back soon with a complete
    patch (Currently I just save the old check_item and put it back which is
    fine in a single thread but not so clever in a threaded system).

    Rather, if flags.xlat is set, do:

    VALUE_PAIR *new_check = rad_malloc(sizeof(*new_check));
    memcpy(new_check, check, sizeof(*new_check));
    new_check->next = NULL
    paircmp( new_check)
    pairfree(&new_check);

    Alan DeKok.

    Are you suggesting this in valuepair.c inside the loop that walks the
    check items, or in rlm_file which I suspect would require the full check
    items list to be copied to keep everything sane? I suspect you mean in
    valuepair.c but thought it wise to ask ;).

    Anyway just noticed another unfortunate feature in rlm_file.c. The !=
    and !~ tests only notice if the very first matching attribute doesn't
    match the value / regex but there is no way of asking the question does
    this attribute value pair NT exist anywhere in the packet. I have a fix
    for this which involves effectively doing a positive match then
    inverting the response if required.
  • No.2 | | 753 bytes | |

    Alister Winfield wrote:

    Anyway just noticed another unfortunate feature in rlm_file.c.

    function?

    Do you mean in src/main/valuepair.c paircmp() (cvs renamed to
    paircompare() )?

    The !=
    and !~ tests only notice if the very first matching attribute doesn't
    match the value / regex but there is no way of asking the question does
    this attribute value pair NT exist anywhere in the packet. I have a fix
    for this which involves effectively doing a positive match then
    inverting the response if required.

    paircmp() loops every av.

    Perphaps if you posted your fix simple schmoes like me can take a look.
    It wont actually buy you anything if I do, but perhaps some others might
    be interested.

Re: Possible Bug in valuepair / rlm_file etc etc.


max 4000 letters.
Your nickname that display:
In order to stop the spam: 5 + 4 =
QUESTION ON "Networking"

EMSDN.COM