Stephan von Krawczynski <[EMAIL PROTECTED]> wrote: > > 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.
<sigh> Could you please stick to one topic? You originally said that in the SERVER, the DATA STRUCTURES didn't have the vendor information. I was confused, because that's pretty much impossible. Now, you change your mind, and say something else, about tcpdump. Stop it. It's annoying, and it makes me inclined to ignore you, until you have a consistent story. > 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. Then you're *very* confused. Go read the "dictionary.ascend" file. Both vendors are idiots, and have put their attributes into the base 256 attributes, rather than using VSA's. THAT'S why you didn't see a vendor Id: They weren't using VSA's. If you had said that in the first place, it would have helped significantly. > 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. Don't bother with any patch. Fix the client so it works. Fix the client so it sends VSA's. > 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). I doubt that very much. > 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. See? Both vendors are stupid and broken. > 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... That change has absolutely irrelevant for the problem at hand. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
