Re: Delete one value of multiple attribute(Class)
Okis Chuang wrote:
Actually I can write a short perl script to do this, but I try to do with pure unlang.
Unlang is not really intended to do that.
In fact, the reason why I need this function is that sometimes we treat some attributes as temporary variable for generating another attribute value pair.
Use Tmp-String-0, or Tmp-Octets-0 instead. That way the problem goes away. See "dictionary.freeradius.internal" for more examples.
Then erase it before sending request or reply out. So I am wondering would majority of FR user do this things like this?
And you don't need to erase the Tmp-* attributes before sending a packet. They will *never* show up in a packet. Alan DeKok. ------------- Hi Alan, Thanks for reply. Yes, I totally can understand the solution you recommend, and I've been using this skill for quite a long time. But the situation I encountered is : 1. I need to save some information returned in Access-Accept from external AAA in the attribute *Class* at the section *post-auth*. So it will return back to gateway. 2. Then gateway will send Accounting-Start to my server. In this time, I need to pop out the information I saved in the attribute *Class* in the section *accounting* so that I can generate the avp what I need. Hence, it cannot work by using Tmp-XXX internal attribute because those two events occur in two different sessions to FreeRADIUS. I thought Tmp-* attributes will not exist across two sessions at the same time. So that way I must choose some kind of attribute that gateway must return back for saving temporary attribute value. Concerning about total available length of Class in our wifi gateway, I don't want to do such a waste on attribute Class. Again, just like I said before, because Class is a multi-value attribute I can't find a way to remove a specific value from entire Class array. But anyway, if this is too much for unlang I can use perl to fulfill this definitely. Just curious about if unlang can totally achieve this. :P Cheers, Okis.
On 17.07.2013 12:29, Okis Chuang wrote:
But the situation I encountered is :
1.I need to save some information returned in Access-Accept from external AAA in the attribute **Class** at the section **post-auth**. So it will return back to gateway.
2.Then gateway will send Accounting-Start to my server. In this time, I need to pop out the information I saved in the attribute **Class** in the section **accounting** so that I can generate the avp what I need.
Hence, it cannot work by using Tmp-XXX internal attribute because those two events occur in two different sessions to FreeRADIUS.
I thought Tmp-* attributes will not exist across two sessions at the same time.
So that way I must choose some kind of attribute that gateway must return back for saving temporary attribute value.
Well with the release 3.0.0 you can use the new rlm_cache module that will allow to do that quite easily. And (again with 3.0.0) you can do a foreach on your multi valued attributes, and erase those you don't need in the loop. Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
Okis Chuang wrote:
But the situation I encountered is :
It helps to describe the situation *accurately*. Otherwise, you're wasting everyone's time.
1. I need to save some information returned in Access-Accept from external AAA in the attribute **Class** at the section **post-auth**. So it will return back to gateway.
That's what Class is for.
2. Then gateway will send Accounting-Start to my server. In this time, I need to pop out the information I saved in the attribute **Class** in the section **accounting** so that I can generate the avp what I need.
That works already.
So that way I must choose some kind of attribute that gateway must return back for saving temporary attribute value.
Concerning about total available length of Class in our wifi gateway, I don’t want to do such a waste on attribute Class.
If the WiFi gateway doesn't support a long Class attribute, it won't support *two* Class attributes, either. You're better off storing session information in a database. Using the WiFi gateway as a session database is a very bad idea. Alan DeKok.
participants (3)
-
Alan DeKok -
Okis Chuang -
Olivier Beytrison