Stephan von Krawczynski <[EMAIL PROTECTED]> wrote:
> 1) It does not recognize at all vendor specific attributes. The reason is this
> code part taken from src/modules/rlm_attr_filter/rlm_attr_filter.c :
...
> if(reply_item->attribute == check_item->attribute) {
>
> Unfortunately check_item->attribute contains the vendor id and therefore can
> never match the reply_item->attribute which does not contain vendor info.
Huh? I don't see why that would be true. If the standard API's are
used to create VP's, then the 'attribute' entry ALWAYS contains the
vendor information.
> This can be dealt with through adding a "& 0xFF". My test shows that
> this works out.
Except for USR VSA's. They need "& 0xffff". See the other code in
rlm_attr_filter.c.
> 2) Unfortunately this brings up another issue, the item_type seems to be
> incorrect. Testing the stuff above shows server reply containing:
>
> X-Ascend-IPX-Alias = 3134307025
>
> which obviously :-) reads bad1bad1 in hex.
See src/lib/radiusd.c. The attribute in the *packet* is supposed to
have 4 octets of data, but doesn't.
That looks to me like the dictionaries on the server and the client
disagree about what type that attribute is.
You also haven't said *where* this attribute is coming from.
Knowing that would help.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
