sqlippool --> ip's expiring and being allocated again
Hallo I have the following situation: pool ip's are allocated correctly, but after the lease-duration is reached, they are deleted from the radippool table. This causes the ip to be once again assigned to another user, who in turn requires a new login, since this ip won't work I have tried to enforce a "keep-alive" with acct-interim, but it doesn't work, the ip's are deleted from radippool when the lease time is up ? how can I prevent this ? Thanks, petre root@core-router:/etc/freeradius# radtest -x petreb petreb localhost 1980 radiuspass Sending Access-Request of id 7 to 127.0.0.1 port 1812 User-Name = "petreb" User-Password = "petreb" NAS-IP-Address = 1.1.1.1 NAS-Port = 1980 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=7, length=38 Acct-Interim-Interval = 120 Session-Timeout = 1195235 Framed-IP-Address = 1.1.1.2
Petre Bandac wrote:
pool ip's are allocated correctly, but after the lease-duration is reached, they are deleted from the radippool table.
That's how IP pools work.
This causes the ip to be once again assigned to another user, who in turn requires a new login, since this ip won't work
Umm... *why* won't it work? You should really figure that out.
I have tried to enforce a "keep-alive" with acct-interim, but it doesn't work, the ip's are deleted from radippool when the lease time is up ?
how can I prevent this ?
You can't. IP's are no longer valid when the lease time is up.
root@core-router:/etc/freeradius# radtest -x petreb petreb localhost 1980 radiuspass Sending Access-Request of id 7 to 127.0.0.1 port 1812 User-Name = "petreb" User-Password = "petreb" NAS-IP-Address = 1.1.1.1 NAS-Port = 1980 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=7, length=38 Acct-Interim-Interval = 120 Session-Timeout = 1195235 Framed-IP-Address = 1.1.1.2
You'll note the Session-Timeout. When IP's are assigned through RADIUS, they get sent to the NAS. The NAS is then responsible for enforcing session expiry. And when the session expires, so does the IP. If the NAS allows the IP to still be used after session expiry, then the NAS is wrong and broken. It needs to be thrown in the garbage, and replaced with a NAS that works. No amount of poking FreeRADIUS will fix a broken NAS. Alan DeKok.
On Wed, 16 Oct 2013 23:10:34 -0400 Alan DeKok <aland@deployingradius.com> wrote:
Petre Bandac wrote:
pool ip's are allocated correctly, but after the lease-duration is reached, they are deleted from the radippool table.
That's how IP pools work.
This causes the ip to be once again assigned to another user, who in turn requires a new login, since this ip won't work
Umm... *why* won't it work? You should really figure that out.
I believe this is because the same ip is allocated to two different users (I can see this with radwho); freeradius sees the ip as "free" in radippool table (since it exceeded lease-time, it has now all fields empty and is eligible for a new allocation) and hands it over to the new request
I have tried to enforce a "keep-alive" with acct-interim, but it doesn't work, the ip's are deleted from radippool when the lease time is up ?
how can I prevent this ?
You can't. IP's are no longer valid when the lease time is up.
root@core-router:/etc/freeradius# radtest -x petreb petreb localhost 1980 radiuspass Sending Access-Request of id 7 to 127.0.0.1 port 1812 User-Name = "petreb" User-Password = "petreb" NAS-IP-Address = 1.1.1.1 NAS-Port = 1980 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=7, length=38 Acct-Interim-Interval = 120 Session-Timeout = 1195235 Framed-IP-Address = 1.1.1.2
You'll note the Session-Timeout. When IP's are assigned through RADIUS, they get sent to the NAS. The NAS is then responsible for enforcing session expiry.
And when the session expires, so does the IP.
If the NAS allows the IP to still be used after session expiry, then the NAS is wrong and broken. It needs to be thrown in the garbage, and replaced with a NAS that works.
No amount of poking FreeRADIUS will fix a broken NAS.
Freeradius sits behind a pppoe server Rephrasing my question: I want to detect the lost ppp connections (I suppose there is a timeout set somewhere) and delete the ip from radippool without waiting the lease-time set in radius (something like the check dhcp does with the handled ip addresses) an excerpt of the freeradius -X is @ http://pastebin.ca/2467690 as my radius knowledge is very chaotic/hands-on approach, I appreciate any hint. Thank you for your time, petre
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Thu, Oct 17, 2013 at 4:35 PM, Petre Bandac <petre@kgb.ro> wrote:
No amount of poking FreeRADIUS will fix a broken NAS.
Freeradius sits behind a pppoe server
Rephrasing my question: I want to detect the lost ppp connections (I suppose there is a timeout set somewhere) and delete the ip from radippool without waiting the lease-time set in radius (something like the check dhcp does with the handled ip addresses)
If you can detect "lost ppp connections", then configure FR is easy. If you CAN'T detect it, then IMHO it's a sign of broken NAS, and as Alan put it, "No amount of poking FreeRADIUS will fix a broken NAS." A sane NAS would usually have some kind of method of notifying radius that a particular connection is still alive. Usually this is in the form of interim-update. FR can then be configured (if not already done so, can't remember from the back of my head) to extend the lease time whenever it receives interim update for a particular user, so that the IP will still be (correctly) marked as used. Sending the lease time to be around twice or three times interim update interval should be enough. -- Fajar
Petre Bandac wrote:
I believe this is because the same ip is allocated to two different users (I can see this with radwho);
No. That doesn't happen. The IP is being *used* by two different users. That is a very different statement.
freeradius sees the ip as "free" in radippool table (since it exceeded lease-time, it has now all fields empty and is eligible for a new allocation) and hands it over to the new request
A "free" IP means it's no longer allocated to the original user.
Freeradius sits behind a pppoe server
Then fix the PPPoE server so that it drops connections at Session-Timeout. The user will then be prevented from using the IP.
Rephrasing my question: I want to detect the lost ppp connections (I suppose there is a timeout set somewhere) and delete the ip from radippool without waiting the lease-time set in radius (something like the check dhcp does with the handled ip addresses)
You don't "detect" the lost PPP connection. The PPPoE server sends an accounting packet, with Acct-Status-Type = Stop. When FreeRADIUS sees that, it marks the session as closed, and frees the IP>
an excerpt of the freeradius -X is @ http://pastebin.ca/2467690
as my radius knowledge is very chaotic/hands-on approach, I appreciate any hint.
Blame the NAS for everything. Really. And read "man radiusd". A chaotic approach is the worst possible method to solving a problem. Alan DeKok.
Hallo I appreciate the clarifications, now I know where to start; I shall thoroughly analyze pppoe's behavior and look for the acct pkts. Thanks everybody for your time and shared knowledge On 17.10.2013 15:12, Alan DeKok wrote:
Petre Bandac wrote:
I believe this is because the same ip is allocated to two different users (I can see this with radwho);
No. That doesn't happen. The IP is being *used* by two different users. That is a very different statement.
freeradius sees the ip as "free" in radippool table (since it exceeded lease-time, it has now all fields empty and is eligible for a new allocation) and hands it over to the new request
A "free" IP means it's no longer allocated to the original user.
Freeradius sits behind a pppoe server
Then fix the PPPoE server so that it drops connections at Session-Timeout. The user will then be prevented from using the IP.
Rephrasing my question: I want to detect the lost ppp connections (I suppose there is a timeout set somewhere) and delete the ip from radippool without waiting the lease-time set in radius (something like the check dhcp does with the handled ip addresses)
You don't "detect" the lost PPP connection. The PPPoE server sends an accounting packet, with Acct-Status-Type = Stop. When FreeRADIUS sees that, it marks the session as closed, and frees the IP>
an excerpt of the freeradius -X is @ http://pastebin.ca/2467690
as my radius knowledge is very chaotic/hands-on approach, I appreciate any hint.
Blame the NAS for everything. Really.
And read "man radiusd". A chaotic approach is the worst possible method to solving a problem.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Petre Bandac Network Scientist - petre@kgb.ro
I had this problem. It happened because it was not updating the radacct table. interim-update did not work. 2013/10/16 Petre Bandac <petre@kgb.ro>:
Hallo
I have the following situation:
pool ip's are allocated correctly, but after the lease-duration is reached, they are deleted from the radippool table.
This causes the ip to be once again assigned to another user, who in turn requires a new login, since this ip won't work
I have tried to enforce a "keep-alive" with acct-interim, but it doesn't work, the ip's are deleted from radippool when the lease time is up ?
how can I prevent this ?
Thanks,
petre
root@core-router:/etc/freeradius# radtest -x petreb petreb localhost 1980 radiuspass Sending Access-Request of id 7 to 127.0.0.1 port 1812 User-Name = "petreb" User-Password = "petreb" NAS-IP-Address = 1.1.1.1 NAS-Port = 1980 rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=7, length=38 Acct-Interim-Interval = 120 Session-Timeout = 1195235 Framed-IP-Address = 1.1.1.2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- []'s ----------------------------------------- .'. Wederson Rodrigues .'. (CeBoLaRk) VIP - Vilhena Internet Provider Gerente de T.I. http://www.vipvilhena.com.br MSN: cebolark@hotmail.com SKYPE: cebolark EMAIL: wederson@vipvilhena.com.br INOC VOIP: 28240*100 Celular: 0xx69 8437-0186 Fixo: 0xx69 3322-2244 -----------------------------------------
participants (4)
-
Alan DeKok -
Fajar A. Nugraha -
Petre Bandac -
Wederson Rodrigues