When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message. If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment. Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work. auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0.
Have a look at acct_unique in radiusd.conf and adjust accordingly. Ivan Kalik Kalik Informatika ISP Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message.
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Doesn't acct_unique come after ? When the server sees a Access-request without NAS-Port, it simply gives the result I indicated in my previous mail. Then comes a problem of clearing the IP address when Accounting-Stop message is received.. I tried changing acct_unique by replacing NAS-Port by Calling-Station-Id without any success. 2008/4/22 Ivan Kalik <tnt@kalik.net>:
Have a look at acct_unique in radiusd.conf and adjust accordingly.
Ivan Kalik Kalik Informatika ISP
Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message.
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
From sqlippool.c
: if (pairfind(request->packet->vps, PW_NAS_PORT) == NULL) { DEBUG("rlm_sqlippool: unknown NAS-Port"); return RLM_MODULE_NOOP; } 2008/4/22 rsg <ranil.santhish@gmail.com>:
Doesn't acct_unique come after ?
When the server sees a Access-request without NAS-Port, it simply gives the result I indicated in my previous mail.
Then comes a problem of clearing the IP address when Accounting-Stop message is received..
I tried changing acct_unique by replacing NAS-Port by Calling-Station-Id without any success.
2008/4/22 Ivan Kalik <tnt@kalik.net>:
Have a look at acct_unique in radiusd.conf and adjust accordingly.
Ivan Kalik Kalik Informatika ISP
Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message.
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Both Accept-Request & Accounting-Request packets were updated with a bogus NAS-Port. Would like to know a better way of doing this. Ivan could you elaborate the method you proposed please? Thanks, 2008/4/22 rsg <ranil.santhish@gmail.com>:
From sqlippool.c
: if (pairfind(request->packet->vps, PW_NAS_PORT) == NULL) { DEBUG("rlm_sqlippool: unknown NAS-Port"); return RLM_MODULE_NOOP; }
2008/4/22 rsg <ranil.santhish@gmail.com>:
Doesn't acct_unique come after ?
When the server sees a Access-request without NAS-Port, it simply gives the result I indicated in my previous mail.
Then comes a problem of clearing the IP address when Accounting-Stop message is received..
I tried changing acct_unique by replacing NAS-Port by Calling-Station-Id without any success.
2008/4/22 Ivan Kalik <tnt@kalik.net>:
Have a look at acct_unique in radiusd.conf and adjust accordingly.
Ivan Kalik Kalik Informatika ISP
Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message.
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Sort of what you have done. Update NAS-Port with value of Calling-Station-Id for example. Anything that will make acct_unique unique in your scenario. Ivan Kalik Kalik Informatika ISP Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
Both Accept-Request & Accounting-Request packets were updated with a bogus NAS-Port.
Would like to know a better way of doing this. Ivan could you elaborate the method you proposed please?
Thanks,
2008/4/22 rsg <ranil.santhish@gmail.com>:
From sqlippool.c
: if (pairfind(request->packet->vps, PW_NAS_PORT) == NULL) { DEBUG("rlm_sqlippool: unknown NAS-Port"); return RLM_MODULE_NOOP; }
2008/4/22 rsg <ranil.santhish@gmail.com>:
Doesn't acct_unique come after ?
When the server sees a Access-request without NAS-Port, it simply gives the result I indicated in my previous mail.
Then comes a problem of clearing the IP address when Accounting-Stop message is received..
I tried changing acct_unique by replacing NAS-Port by Calling-Station-Id without any success.
2008/4/22 Ivan Kalik <tnt@kalik.net>:
Have a look at acct_unique in radiusd.conf and adjust accordingly.
Ivan Kalik Kalik Informatika ISP
Dana 22/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
When there's no NAS-Port in rad_request... the server doesn't assign an IP address; That's why in my opinion there's no Framed-IP-Address in Access-Accept message.
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [test/test] (from client SSS port 0 cli 44444444488) +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop } # server example Sending Access-Accept of id 56 to 192.168.1.4 port 1812 Primary-DNS-Server = 192.168.2.2 Secondary-DNS-Server = 192.168.2.2 Proxy-State = 0x30303338 Finished request 0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
rsg wrote:
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
It's currently a mandatory attribute for the IP pool module.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
Don't. The issue is that you need a unique key to assign IP's. The SQL ippool module can use any key you want. Alan DeKok.
Many thanks for the response. It's mandatory for the ippool module, but sqlippool comes with an alternative pool-key which is the Calling-Station-Id. In reality NAS-Port is NOT supported by all the GGSNs. In my opinion it should be open to be decided between NAS-Port and Calling-Station-Id depending on the service. On Tue, Apr 22, 2008 at 4:22 PM, Alan DeKok <aland@deployingradius.com> wrote:
rsg wrote:
If my reasoning is correct, I'd like to highlight that NAS-Port is not a mandatory attribute when it comes to Mobile telephony environment.
It's currently a mandatory attribute for the IP pool module.
Is there any workaround once again to bypass this. I can suggest one..i.e to update the Access-Request using unlang and hope it would work.
Don't.
The issue is that you need a unique key to assign IP's. The SQL ippool module can use any key you want.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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.
On Tue, Apr 22, 2008 at 9:24 PM, Alan DeKok <aland@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; }
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@gmail.com> wrote:
On Tue, Apr 22, 2008 at 9:24 PM, Alan DeKok <aland@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; }
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@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@gmail.com> wrote:
On Tue, Apr 22, 2008 at 9:24 PM, Alan DeKok <aland@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
2008/4/23 Ivan Kalik <tnt@kalik.net>:
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.
Yes, this was what I suggested in my first email, to update the request packets(Auth/Acct). This works well.
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!".
As you suggested I sent a bug report based on my observations. http://bugs.freeradius.org/show_bug.cgi?id=548 Thanks a lot for your valuable comments/input.
Ivan Kalik Kalik Informatika ISP
Dana 23/4/2008, "rsg" <ranil.santhish@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@gmail.com> wrote:
On Tue, Apr 22, 2008 at 9:24 PM, Alan DeKok <aland@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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I think that's the right way. If the configuration has settings to use either NAS-Port and Calling-Station-Id and the code doesn't support the second option ... Code needs fixing. Ivan Kalik Kalik Informatika ISP Dana 24/4/2008, "rsg" <ranil.santhish@gmail.com> piše:
2008/4/23 Ivan Kalik <tnt@kalik.net>:
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.
Yes, this was what I suggested in my first email, to update the request packets(Auth/Acct). This works well.
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!".
As you suggested I sent a bug report based on my observations.
http://bugs.freeradius.org/show_bug.cgi?id=548
Thanks a lot for your valuable comments/input.
Ivan Kalik Kalik Informatika ISP
Don't.
The issue is that you need a unique key to assign IP's. The SQL ippool module can use any key you want.
Alan DeKok.
Then why does it gives, -------- +- entering group post-auth rlm_sqlippool: unknown NAS-Port ++[sqlippool] returns noop ------- when NAS-Port is not found? I've set the Calling-Station-Id as the pool-key. Hope my point is clear here. Thanks,
participants (3)
-
Alan DeKok -
Ivan Kalik -
rsg