Re: Problem with attr_filter
Stephan von Krawczynski [EMAIL PROTECTED] wrote: Only half answered, I'm afraid. I tried auth_log and reply_log, but it is unclear how to find out corresponding req and reply without any id logging ... shrug You've got the source code. It's only a 1-line change. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Mon, 15 Dec 2003 09:11:26 -0500 Alan DeKok [EMAIL PROTECTED] wrote: 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). You did read 'radiusd.conf', didn't you? That question is answered there. Only half answered, I'm afraid. I tried auth_log and reply_log, but it is unclear how to find out corresponding req and reply without any id logging ... The timestamp seems not sufficient for this. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
This is my last message on this topic, in the naive hope that you will pay attention to what I'm saying. Stephan von Krawczynski [EMAIL PROTECTED] wrote: 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. Bullshit. Total, absolute, bullshit. I explained why in my previous message. Go back and read it. _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? Yes. I told you to go read dictionay.ascend. You obviously haven't. To hint again: one is a VSA, one is not. The attributes are incomparable. 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. Sorry, you're wrong. I could explain why, but you'd just argue with me again. Why does a packet come out different from 0.8.1 using the same dictionary as 0.9.3 ? drum roll Because the dictionaries have changed? And you're too damn lazy to go check? Or, you're too damn proud to follow my instructions? See, I would have thought you READ my messages, and put 2 and 2 together: 1) go read dictionary.ascend 2) if the attribute isn't being sent as a VSA, update the dictionary so that it IS sent as a VSA. You did READ the dictionary, to see if the attribute was a VSA, didn't you? You did try to update the dictionary, to make the attribute a VSA, didn't you? But I doubt you have. You're only asking questions to prove me wrong, and to avoid all of my instructions as to how to fix the problem. 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). You did read 'radiusd.conf', didn't you? That question is answered there. Obviously not... Honestly, I don't know why it's so hard for you to read my responses, and do as I say. I do know that I'm wasting my time, and I don't see the point in discussing it any further. I've told you exactly what's wrong, and I've told you exactly how to fix it. Yet that isn't good enough for you. You still argue with me, ignore what I say, and tell me I'm wrong. I can only conclude that you're uninterested in solving your problem. You're only interested in social gossip on the list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
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 0x. 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
Re: Problem with attr_filter
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
Re: Problem with attr_filter
On Sun, 14 Dec 2003 09:15:55 -0500 Alan DeKok [EMAIL PROTECTED] wrote: 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. Sorry Alan, your pretty much in the woods. I try to explain again the setup router | proxy radius server freeradius 0.9.3 /\ client 1 radius server client radius server freeradius 0.8.1SGI-based Now I have several ways to check out what is happening: 1) tcpdump on proxy-server for both client incoming packets (these show _no_ vendor info) 2) tcpdump on proxy-server for router side (these show vendor info if I patch freeradius as explained in former post. no vendor-specific attributes go through the attr_filter if I don't patch) 3) if I don't use attr_filtering (post-proxy) at all, then obviously all attributes go through, and have (of course) no vendor info. Hope this describes the situation a bit clearer. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sun, 14 Dec 2003 09:15:55 -0500 Alan DeKok [EMAIL PROTECTED] wrote: 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. Unfortunately it would not, because either they are using vendor info or not, 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. 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. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
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? Are you going to believe me, or are you going to keep telling me I'm wrong? 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. 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. 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. There will be NO patches going into the server to fix this problem. 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. 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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
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
Problem with attr_filter
Hello, I'd like to use attr_filter for post_proxy processing. My general idea is to filter only certain clients/realms and let others (the major part) just through. I thought this could be achieved by only putting the realms to filter into the attr file, but found out that all others get dropped completely then. Is this expected behaviour? If it is I obviously will have to make a catch-all/allow-all default entry. In trying to do so I experienced that I seem to be unable to include attributes from outside the standard dictionary. Is this correct? What would be the simple way of an allow-all default entry, that really allows all attributes, no matter what dictionary? I am using freeradius 0.9.3 btw. Any hints are appreciated. Regards, Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
On Sat, 13 Dec 2003 14:55:22 +0100
Stephan von Krawczynski [EMAIL PROTECTED] wrote:
[...]
If it is I obviously will have to make a catch-all/allow-all default entry.
In trying to do so I experienced that I seem to be unable to include
attributes from outside the standard dictionary. Is this correct?
Further investigation shows that in fact the rlm_attr_filter module is broken
in several ways:
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 :
while( check_item != NULL ) {
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.
This can be dealt with through adding a 0xFF. My test shows that this works
out.
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.
Am I right?
Regards,
Stephan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problem with attr_filter
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 0x. 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
