rlm_sqlippool

[Ivan Kalik]

No idea. That check must have some purpose.

Usual workaround for this is to rewrite (update in freeradius speak)
NAS-Port attribute with the value of Calling-Station-Id (in unlang,
perl, ...). That sorts out missing NAS-Port in the request.

There are way too many places where NAS-Port needs to be changed in the
configuration, and you might need to alter code as well - hence "ONLY
change this if you know what you are doing!".

Ivan Kalik
Kalik Informatika ISP


Dana 23/4/2008, "rsg" <ranil.santhish at gmail.com> piše:

>raddb/sqlippool.conf
>
> ## Using Calling-Station-Id works for NAS that send fixed NAS-Port
> ## ONLY change this if you know what you are doing!
> ## pool-key = "%{NAS-Port}"
> pool-key = "%{Calling-Station-Id}"
>
>
>What I suggest is that we take the "NAS that send fixed NAS-Port"
>condition off from RLM_SQLIPPOOL module.
>
>Because, as I said before it is NOT a must to send the NAS-Port always
>(e.g. some GGSNs)
>
>What would be the consequences of taking it off?
>
>Thanks,
>
>
>
>On Tue, Apr 22, 2008 at 9:43 PM, rsg <ranil.santhish at gmail.com> wrote:
>> On Tue, Apr 22, 2008 at 9:24 PM, Alan DeKok <aland at deployingradius.com> wrote:
>>  > rsg wrote:
>>  >  > In my opinion it should be open to be decided between NAS-Port and
>>  >  > Calling-Station-Id depending on the service.
>>  >
>>  >   Which is why you can edit the queries in the SQL ippool module.
>>  >
>>  >   If the non-SQL ippool module doesn't do what you want, fix it, and
>>  >  supply a patch.
>>  >
>>  >
>>  >
>>  >   Alan DeKok.
>>
>>  No I'm referring to the SQL ippool;
>>
>>  The following entry gives the result what I've indicated in my first mail.
>>
>>
>>  From sqlippool.c
>>
>>        :
>>        if (pairfind(request->packet->vps, PW_NAS_PORT) == NULL) {
>>                DEBUG("rlm_sqlippool: unknown NAS-Port");
>>                return RLM_MODULE_NOOP;
>>        }
>>
>-
>List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
>