On Sun, 14 Dec 2003 14:05:19 -0500 "Alan DeKok" <[EMAIL PROTECTED]> wrote:
> Stephan von Krawczynski <[EMAIL PROTECTED]> wrote: > > > 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. > > > > Unfortunately it would not, > > If you know more about RADIUS & the server than I do, why are you > asking questions? Because there may be others out there that see the same issues but are not quite able to browse the source for further investigation. Stuff like this discussion enters some archives and can be found by people looking for it. And _that_ is why I began this discussion, and _not_ because I am requesting any help. I can very well help myself in this issue. > Are you going to believe me, or are you going to > keep telling me I'm wrong? You are not wrong, you simply don't listen or don't at least try to understand the problem, again: I have a freeradius 0.8.1 and let it send vendor attributes to a freeradius 0.9.3 proxy that tries to filter _that very same_ vendor attributes and does not recognise them. _That_ is a real issue. It is likely that 0.8.1 is different somehow regarding vendor info behaviour (maybe buggy, I don't know). My expectation was you had some knowledge about this. Do you? > > but the situation while comparing in rlm_attr_filter is that the > > reply_item has no vendor info, whereas the check_item (remember: > > from _same_ vendor!) has one. And _that_ is the primary problem. > > Absolutely not. You haven't understood what I'm saying. > > To repeat in short, simple, words: Vendor attributes are different > from non-vendor attributes. I know. > If the names look similar to you, that's > an illusion, and has nothing to do with the problem at hand. If the > attribute numbers look similar, that, too, is unimportant. .. as long as they don't belong to the _same_ dictionary, which is exactly the case here. > The attributes are different. One is a VSA, and the other is not. > The code will never be able to compare them as "identical", because > they're not identical. The RADIUS packet itself says they're > different, so the server treats them as different. Why does a packet come out different from 0.8.1 using the same dictionary as 0.9.3 ? > There will be NO patches going into the server to "fix" this > problem. I did not talk about this. I talked about a patch I tried to bring more light into the issue. > > Thinking about it another possible solution may be to create a > > patch-dictionary where the attributes contain no vendor info and use > > these in attr_filter. That sounds like a reasonable no-source-patch > > solution to this problem. > > Nonsense. Total nonsense. Go READ the "dictionary.ascend", like I > TOLD YOU. It ALREADY lists the attributes without vendor info. And > as you've seen, this causes problems. > > As I said in my previous message, BOTH vendors have used the same > NON-VENDOR attribute space for their attributes. This is stupid of > them, and is the entire source of the problem. Stop trying to "fix" > the server by making it even more broken in ways you've already said > you didn't like. > > Go fix the clients to send the attributes as VSA's. That will solve > the problem. I'll bet a simple edit of a dictionary file is all > that's needed. Hoho! You are slightly touching the problem: must freeradius 0.8.1 be fixed to produce the same radius packets 0.9.3 can understand/filter? > There are probably ways to use the server to re-write the attributes > to make sense (so attr_filter works), but I don't see any point in > explaining them, until it's clear that you've understood what else > I've said. I have heard about attr_rewrite, thanks. But I guess this is overcomplicating the whole story. Something that came to my mind while debugging was: is there a (simple) way to make freeradius write a protocol of all access-packets very like the accounting packets' protocol (detail-file)? I mean besides freeradius debugging mode. That would be very handy (I really don't like tcpdump for long-term protocols). Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
