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