Re: [RADIATOR] Radiator+Mikrotik
Well! I stand corrected. -- Nathan Hugh Irvine wrote: Hello Sergio - Yes - have a look at the current packages in the “Radius/Nas/…” directory of the Radiator-4.14 distribution. regards Hugh > On 23 Jan 2015, at 13:41, sergio wrote: > > hello > > It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm > > >> -Original Message- >> From: nath...@fsr.com >> Sent: Mon, 8 Dec 2014 05:30:26 -0800 >> To: m.abdelsa...@wimd.com.kw, radiator@open.com.au >> Subject: Re: [RADIATOR] Radiator+Mikrotik >> >> On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote: >> >>> Hello all, >>> >>> As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, >>> the hook script will send Disconnect-Request to Mikrotik once the >>> session >>> exceeds the quota, here is how i send Disconnect-Request: >> >> [snip] >> >>> This works fine but the problem is that user can't re-authenticate again >>> because it reaches Maxsessions although I have this in my config file: >> >> [snip] >> >>> The user would successfully authenticate again when I manually remove >>> the >>> session from RADONLINE by executing the DeleteQuery. >> >> It has been a while since I have had to look at/think about this, but as >> I recall, this is how it works: >> >> DeleteQuery doesn't get executed unless the Radiator server receives >> Accounting-Stop from the MikroTik. >> >> PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued >> by MikroTik RouterOS; I can't remember and I will have to simulate this >> later and run a packet capture to see what happens. (Maybe if you are >> running an older version of RouterOS, try upgrading? It could be a bug >> that got fixed later, and they have definitely had their share of RADIUS >> client bugs in the past.) >> >> In any case, you can work around a problem where Radiator does not >> receive Accounting-Stop by having Radiator verify that any active >> sessions for the user that are recorded in the RADONLINE table are valid >> at the moment that the user tries to authenticate again. Radiator does >> this by executing an SNMP query to the NAS that is on record for each >> session to see if the Session-ID for that row in the table is still >> valid. If the NAS does not return anything for the OID, then Radiator >> assumes the session is dead and purges that entry from RADONLINE, >> reducing MaxSessions count by 1. >> >> To enable this functionality, you need to make sure that SNMP is enabled >> and configured on each MikroTik NAS, you need to make sure that Net-SNMP >> is installed and configured on the Radiator server, and you need to add >> these options to your Client clause in your Radiator config file: >> >> >>[...] >># MikroTik supports this MIB >>NasType CiscoSessionMIB >>SNMPCommunity public >> >> >> Replace 'public' with the SNMP community string that you have configured >> on the MikroTik. >> >> We also made a slight change to the Radiator code, because by default, if >> Radiator does not get a response back from its SNMP "get" to the >> MikroTik, it gives the benefit of the doubt to RADONLINE. We have found >> that more often than not, it is better to give the benefit of the doubt >> to the user. That way, a user is not unfairly punished by problems with >> our NAS or problems on our network that might make it impossible for >> Radiator to communicate with our NAS. Here is the patch to make that >> change in behavior: >> >> diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm >> Radius-patched/Nas/CiscoSessionMIB.pm >> --- Radius/Nas/CiscoSessionMIB.pm2009-10-26 15:23:55.0 -0700 >> +++ Radius-patched/Nas/CiscoSessionMIB.pm2014-12-08 05:20:02.0 >> -0800 >> @@ -39,7 +39,7 @@ >> $client->{SNMPCommunity}, >> "$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id"); >> >> -return 1 if (!$result || $result =~ /no response/i); # Could not >> SNMP. Assume still there >> +return 0 if (!$result || $result =~ /no response/i); # Could not >> SNMP. Give benefit of doubt to user. >> return 0 if $result =~ /no such variable/i; # Not in the MIB means >> no such session >> return uc($1) eq uc($name) >> if ($result =~ /^.*\"([^"]+)".*$/); >> >> Hope this helps, >> >> -- >> Nathan Ande
Re: [RADIATOR] Radiator+Mikrotik
Hello Sergio - Yes - have a look at the current packages in the “Radius/Nas/…” directory of the Radiator-4.14 distribution. regards Hugh > On 23 Jan 2015, at 13:41, sergio wrote: > > hello > > It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm > > >> -Original Message- >> From: nath...@fsr.com >> Sent: Mon, 8 Dec 2014 05:30:26 -0800 >> To: m.abdelsa...@wimd.com.kw, radiator@open.com.au >> Subject: Re: [RADIATOR] Radiator+Mikrotik >> >> On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote: >> >>> Hello all, >>> >>> As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, >>> the hook script will send Disconnect-Request to Mikrotik once the >>> session >>> exceeds the quota, here is how i send Disconnect-Request: >> >> [snip] >> >>> This works fine but the problem is that user can't re-authenticate again >>> because it reaches Maxsessions although I have this in my config file: >> >> [snip] >> >>> The user would successfully authenticate again when I manually remove >>> the >>> session from RADONLINE by executing the DeleteQuery. >> >> It has been a while since I have had to look at/think about this, but as >> I recall, this is how it works: >> >> DeleteQuery doesn't get executed unless the Radiator server receives >> Accounting-Stop from the MikroTik. >> >> PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued >> by MikroTik RouterOS; I can't remember and I will have to simulate this >> later and run a packet capture to see what happens. (Maybe if you are >> running an older version of RouterOS, try upgrading? It could be a bug >> that got fixed later, and they have definitely had their share of RADIUS >> client bugs in the past.) >> >> In any case, you can work around a problem where Radiator does not >> receive Accounting-Stop by having Radiator verify that any active >> sessions for the user that are recorded in the RADONLINE table are valid >> at the moment that the user tries to authenticate again. Radiator does >> this by executing an SNMP query to the NAS that is on record for each >> session to see if the Session-ID for that row in the table is still >> valid. If the NAS does not return anything for the OID, then Radiator >> assumes the session is dead and purges that entry from RADONLINE, >> reducing MaxSessions count by 1. >> >> To enable this functionality, you need to make sure that SNMP is enabled >> and configured on each MikroTik NAS, you need to make sure that Net-SNMP >> is installed and configured on the Radiator server, and you need to add >> these options to your Client clause in your Radiator config file: >> >> >>[...] >># MikroTik supports this MIB >>NasType CiscoSessionMIB >>SNMPCommunity public >> >> >> Replace 'public' with the SNMP community string that you have configured >> on the MikroTik. >> >> We also made a slight change to the Radiator code, because by default, if >> Radiator does not get a response back from its SNMP "get" to the >> MikroTik, it gives the benefit of the doubt to RADONLINE. We have found >> that more often than not, it is better to give the benefit of the doubt >> to the user. That way, a user is not unfairly punished by problems with >> our NAS or problems on our network that might make it impossible for >> Radiator to communicate with our NAS. Here is the patch to make that >> change in behavior: >> >> diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm >> Radius-patched/Nas/CiscoSessionMIB.pm >> --- Radius/Nas/CiscoSessionMIB.pm2009-10-26 15:23:55.0 -0700 >> +++ Radius-patched/Nas/CiscoSessionMIB.pm2014-12-08 05:20:02.0 >> -0800 >> @@ -39,7 +39,7 @@ >> $client->{SNMPCommunity}, >> "$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id"); >> >> -return 1 if (!$result || $result =~ /no response/i); # Could not >> SNMP. Assume still there >> +return 0 if (!$result || $result =~ /no response/i); # Could not >> SNMP. Give benefit of doubt to user. >> return 0 if $result =~ /no such variable/i; # Not in the MIB means >> no such session >> return uc($1) eq uc($name) >> if ($result =~ /^.*\"([^"]+)".*$/); >> >> Hope this helps, >> >> -- >> Nathan Anderson >> First Step Internet, LL
Re: [RADIATOR] Radiator+Mikrotik
I'm not sure that I see what the point of that would be. RouterOS uses the same MIB as Cisco does, so having to keep 2 nearly-identical modules in sync with each other would be silly. To be clear, the modification I made to the CiscoSessionMIB wasn't for the sake of compatibility with RouterOS. It was to change Radiator's behavior in the event that it got no SNMP response from the NAS. This modification would be equally valuable to someone using a Cisco NAS who wanted the same behavior. If anything, it would be nice to have this as a configurable option in Radiator. -- Nathan Anderson First Step Internet, LLC nath...@fsr.com sergio wrote: hello It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm > -Original Message- > From: nath...@fsr.com > Sent: Mon, 8 Dec 2014 05:30:26 -0800 > To: m.abdelsa...@wimd.com.kw, radiator@open.com.au > Subject: Re: [RADIATOR] Radiator+Mikrotik > > On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote: > >> Hello all, >> >> As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, >> the hook script will send Disconnect-Request to Mikrotik once the >> session >> exceeds the quota, here is how i send Disconnect-Request: > > [snip] > >> This works fine but the problem is that user can't re-authenticate again >> because it reaches Maxsessions although I have this in my config file: > > [snip] > >> The user would successfully authenticate again when I manually remove >> the >> session from RADONLINE by executing the DeleteQuery. > > It has been a while since I have had to look at/think about this, but as > I recall, this is how it works: > > DeleteQuery doesn't get executed unless the Radiator server receives > Accounting-Stop from the MikroTik. > > PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued > by MikroTik RouterOS; I can't remember and I will have to simulate this > later and run a packet capture to see what happens. (Maybe if you are > running an older version of RouterOS, try upgrading? It could be a bug > that got fixed later, and they have definitely had their share of RADIUS > client bugs in the past.) > > In any case, you can work around a problem where Radiator does not > receive Accounting-Stop by having Radiator verify that any active > sessions for the user that are recorded in the RADONLINE table are valid > at the moment that the user tries to authenticate again. Radiator does > this by executing an SNMP query to the NAS that is on record for each > session to see if the Session-ID for that row in the table is still > valid. If the NAS does not return anything for the OID, then Radiator > assumes the session is dead and purges that entry from RADONLINE, > reducing MaxSessions count by 1. > > To enable this functionality, you need to make sure that SNMP is enabled > and configured on each MikroTik NAS, you need to make sure that Net-SNMP > is installed and configured on the Radiator server, and you need to add > these options to your Client clause in your Radiator config file: > > > [...] > # MikroTik supports this MIB > NasType CiscoSessionMIB > SNMPCommunity public > > > Replace 'public' with the SNMP community string that you have configured > on the MikroTik. > > We also made a slight change to the Radiator code, because by default, if > Radiator does not get a response back from its SNMP "get" to the > MikroTik, it gives the benefit of the doubt to RADONLINE. We have found > that more often than not, it is better to give the benefit of the doubt > to the user. That way, a user is not unfairly punished by problems with > our NAS or problems on our network that might make it impossible for > Radiator to communicate with our NAS. Here is the patch to make that > change in behavior: > > diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm > Radius-patched/Nas/CiscoSessionMIB.pm > --- Radius/Nas/CiscoSessionMIB.pm 2009-10-26 15:23:55.0 -0700 > +++ Radius-patched/Nas/CiscoSessionMIB.pm 2014-12-08 05:20:02.0 > -0800 > @@ -39,7 +39,7 @@ >$client->{SNMPCommunity}, >"$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id"); > > -return 1 if (!$result || $result =~ /no response/i); # Could not > SNMP. Assume still there > +return 0 if (!$result || $result =~ /no response/i); # Could not > SNMP. Give benefit of doubt to user. > return 0 if $result =~ /no such variable/i; # Not in the MIB means > no such session > return uc($1) eq uc($name) > if ($result =~ /^.*\"([^"]+)".*$/); > > Hope this hel
Re: [RADIATOR] Radiator+Mikrotik
hello It is possible to create a package for the Mikrotik? MikrotikSessionMIB.pm > -Original Message- > From: nath...@fsr.com > Sent: Mon, 8 Dec 2014 05:30:26 -0800 > To: m.abdelsa...@wimd.com.kw, radiator@open.com.au > Subject: Re: [RADIATOR] Radiator+Mikrotik > > On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote: > >> Hello all, >> >> As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, >> the hook script will send Disconnect-Request to Mikrotik once the >> session >> exceeds the quota, here is how i send Disconnect-Request: > > [snip] > >> This works fine but the problem is that user can't re-authenticate again >> because it reaches Maxsessions although I have this in my config file: > > [snip] > >> The user would successfully authenticate again when I manually remove >> the >> session from RADONLINE by executing the DeleteQuery. > > It has been a while since I have had to look at/think about this, but as > I recall, this is how it works: > > DeleteQuery doesn't get executed unless the Radiator server receives > Accounting-Stop from the MikroTik. > > PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued > by MikroTik RouterOS; I can't remember and I will have to simulate this > later and run a packet capture to see what happens. (Maybe if you are > running an older version of RouterOS, try upgrading? It could be a bug > that got fixed later, and they have definitely had their share of RADIUS > client bugs in the past.) > > In any case, you can work around a problem where Radiator does not > receive Accounting-Stop by having Radiator verify that any active > sessions for the user that are recorded in the RADONLINE table are valid > at the moment that the user tries to authenticate again. Radiator does > this by executing an SNMP query to the NAS that is on record for each > session to see if the Session-ID for that row in the table is still > valid. If the NAS does not return anything for the OID, then Radiator > assumes the session is dead and purges that entry from RADONLINE, > reducing MaxSessions count by 1. > > To enable this functionality, you need to make sure that SNMP is enabled > and configured on each MikroTik NAS, you need to make sure that Net-SNMP > is installed and configured on the Radiator server, and you need to add > these options to your Client clause in your Radiator config file: > > > [...] > # MikroTik supports this MIB > NasType CiscoSessionMIB > SNMPCommunity public > > > Replace 'public' with the SNMP community string that you have configured > on the MikroTik. > > We also made a slight change to the Radiator code, because by default, if > Radiator does not get a response back from its SNMP "get" to the > MikroTik, it gives the benefit of the doubt to RADONLINE. We have found > that more often than not, it is better to give the benefit of the doubt > to the user. That way, a user is not unfairly punished by problems with > our NAS or problems on our network that might make it impossible for > Radiator to communicate with our NAS. Here is the patch to make that > change in behavior: > > diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm > Radius-patched/Nas/CiscoSessionMIB.pm > --- Radius/Nas/CiscoSessionMIB.pm 2009-10-26 15:23:55.0 -0700 > +++ Radius-patched/Nas/CiscoSessionMIB.pm 2014-12-08 05:20:02.0 > -0800 > @@ -39,7 +39,7 @@ >$client->{SNMPCommunity}, >"$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id"); > > -return 1 if (!$result || $result =~ /no response/i); # Could not > SNMP. Assume still there > +return 0 if (!$result || $result =~ /no response/i); # Could not > SNMP. Give benefit of doubt to user. > return 0 if $result =~ /no such variable/i; # Not in the MIB means > no such session > return uc($1) eq uc($name) > if ($result =~ /^.*\"([^"]+)".*$/); > > Hope this helps, > > -- > Nathan Anderson > First Step Internet, LLC > nath...@fsr.com > ___ > radiator mailing list > radiator@open.com.au > http://www.open.com.au/mailman/listinfo/radiator Can't remember your password? Do you need a strong and secure password? Use Password manager! It stores your passwords & protects your account. Check it out at http://mysecurelogon.com/password-manager ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Radiator+Mikrotik
On Monday, December 08, 2014 12:16 AM, Mahmoud Abdelsalam wrote: > Hello all, > > As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, > the hook script will send Disconnect-Request to Mikrotik once the session > exceeds the quota, here is how i send Disconnect-Request: [snip] > This works fine but the problem is that user can't re-authenticate again > because it reaches Maxsessions although I have this in my config file: [snip] > The user would successfully authenticate again when I manually remove the > session from RADONLINE by executing the DeleteQuery. It has been a while since I have had to look at/think about this, but as I recall, this is how it works: DeleteQuery doesn't get executed unless the Radiator server receives Accounting-Stop from the MikroTik. PoD/Disconnect-Request may or may not cause Accounting-Stop to be issued by MikroTik RouterOS; I can't remember and I will have to simulate this later and run a packet capture to see what happens. (Maybe if you are running an older version of RouterOS, try upgrading? It could be a bug that got fixed later, and they have definitely had their share of RADIUS client bugs in the past.) In any case, you can work around a problem where Radiator does not receive Accounting-Stop by having Radiator verify that any active sessions for the user that are recorded in the RADONLINE table are valid at the moment that the user tries to authenticate again. Radiator does this by executing an SNMP query to the NAS that is on record for each session to see if the Session-ID for that row in the table is still valid. If the NAS does not return anything for the OID, then Radiator assumes the session is dead and purges that entry from RADONLINE, reducing MaxSessions count by 1. To enable this functionality, you need to make sure that SNMP is enabled and configured on each MikroTik NAS, you need to make sure that Net-SNMP is installed and configured on the Radiator server, and you need to add these options to your Client clause in your Radiator config file: [...] # MikroTik supports this MIB NasType CiscoSessionMIB SNMPCommunity public Replace 'public' with the SNMP community string that you have configured on the MikroTik. We also made a slight change to the Radiator code, because by default, if Radiator does not get a response back from its SNMP "get" to the MikroTik, it gives the benefit of the doubt to RADONLINE. We have found that more often than not, it is better to give the benefit of the doubt to the user. That way, a user is not unfairly punished by problems with our NAS or problems on our network that might make it impossible for Radiator to communicate with our NAS. Here is the patch to make that change in behavior: diff -r -d -u -N Radius/Nas/CiscoSessionMIB.pm Radius-patched/Nas/CiscoSessionMIB.pm --- Radius/Nas/CiscoSessionMIB.pm 2009-10-26 15:23:55.0 -0700 +++ Radius-patched/Nas/CiscoSessionMIB.pm 2014-12-08 05:20:02.0 -0800 @@ -39,7 +39,7 @@ $client->{SNMPCommunity}, "$Radius::Nas::CiscoMIB.9.150.1.1.3.1.2.$session_id"); -return 1 if (!$result || $result =~ /no response/i); # Could not SNMP. Assume still there +return 0 if (!$result || $result =~ /no response/i); # Could not SNMP. Give benefit of doubt to user. return 0 if $result =~ /no such variable/i; # Not in the MIB means no such session return uc($1) eq uc($name) if ($result =~ /^.*\"([^"]+)".*$/); Hope this helps, -- Nathan Anderson First Step Internet, LLC nath...@fsr.com ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
[RADIATOR] Radiator+Mikrotik
Hello all, As Mikrotik doesn't support COA for PPPoE, so I used Disconnect-Request, the hook script will send Disconnect-Request to Mikrotik once the session exceeds the quota, here is how i send Disconnect-Request: my @coa_attrs = ("User-Name=$user_name", "Acct-Session-Id=$sess_id", "Framed-IP-Address=$framed_ipaddress"); my @cmd_args = ("-noacct", "-noauth", "-time","-code", "Disconnect-Request"); push @cmd_args, ("-trace", "4", "-bind_address", "0.0.0.0", "-auth_port", "3799", "-secret", "bla", "-s", "10.11.11.2"); my @cmd = ("radpwtst"); system (@cmd, @cmd_args, @coa_attrs); This works fine but the problem is that user can't re-authenticate again because it reaches Maxsessions although I have this in my config file: Identifier tamesql DBSourcedbi:ODBC:IRONMAN DBUsername user DBAuth pass AddQueryinsert into RADONLINE \ (USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP, FRAMEDIPADDRESS, NASPORTTYPE, SERVICETYPE) \ values \ ('%n', '%N', %{NAS-Port}, '%{Acct-Session-Id}', %{Timestamp}, '%{Framed-IP-Address}', '%{NAS-Port-Type}', '%{Service-Type}') DeleteQuery delete from RADONLINE where USERNAME='%n' and NASIDENTIFIER='%N' and NASPORT=%{NAS-Port} ClearNasQuery delete from RADONLINE where NASIDENTIFIER='%N' CountQuery select NASIDENTIFIER, NASPORT, ACCTSESSIONID, FRAMEDIPADDRESS from RADONLINE where USERNAME='%n' The user would successfully authenticate again when I manually remove the session from RADONLINE by executing the DeleteQuery. Best Regards, Mahmoud Abdelsalam. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator