On Sat, 13 Dec 2003 15:09:03 -0500
"Alan DeKok" <[EMAIL PROTECTED]> wrote:
> 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.
Hm, this was my first thought, too. But I checked the incoming data via tcpdump
as a hexdump and had to find out that there was no vendor info.
> > 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.
In fact this citation of mine was a bit irritating, the output was generated by
radtest, but radtest falsely interpreted the vendor which was no Ascend but
Bintec. On Bintec this attribute is STRING. So besides the major vendor id
problem, there was a problem with interpreting the attribute without vendor
knowledge. This led me to the patch described below, which is just ugly.
> You also haven't said *where* this attribute is coming from.
> Knowing that would help.
This is the funny part: I have two setups that produce packets without vendor
ids, first is freeradius-0.8.1 (I really checked the dictionary on this one,
the ID is in the dictionary, but packets do not contain any). The second is
some SGI-based radius server I have no hands on. This one neither sends
vendor info and was configured for completely different clients than the
freeradius installation. So basically we have incoming proxy-packets for two
different vendors from two very different installations, both containing no
vendor info at all.
I made a patch to replace the attribute from reply_item with the one from
check_item before copying it to reply_tmp, but that is a real hack. I wonder if
there is a clean solution at all, though...
--
Regards,
Stephan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
