Re: [RADIATOR] Delayed Stop Record and Active Sessions
Hello Rohan - Depending on the actual delay, you may be able to do something clever with the timestamps. regards Hugh On 22 Feb 2014, at 08:21, rohan.henry @cwjamaica.com rohan.he...@cwjamaica.com wrote: Thanks for the feedback Heikki. I am thinking that the suggestion would solve the problem but defeats the state limit function. It means that a connection would now become unique based on Acct-Session-Id which changes for every connection and would grant access to the same user multiple times since the new Acct-Session-Id will not allow a database match. Rohan On Wed, Feb 19, 2014 at 3:40 PM, Heikki Vatiainen h...@open.com.au wrote: On 02/19/2014 09:22 PM, rohan.henry @cwjamaica.com wrote: How can fix an issue where the DeleteQuery statement in my Sessions DB config deletes the row for a new active session because of a delayed Stop record? A quick idea: Do you think the DeleteQuery could be changed to include Acct-Session-Id in the query. That is, the NAS-Port, etc, and Acct-Session-Id must match the existing entry. If the session has been replaced, the delete will not match any rows because the new entry on the row it would otherwise match has a different session id that belongs to the new session. Please let us know how this works. Thanks, Heikki Scenario: 1. A session is up (and row entered in the database for active session) 2. The session is dropped because of a premature disconnection (eg. modem line cable unplugged) but Stop record is delayed. 3. New session is created after modem line cable is restored (and after DeleteQuery statement removes database row for previous session) 4. The delayed Stop record finally comes in - the DeleteQuery statement now removes the row for the active session (An unwanted behavior). How do I compensate for the delayed Stop record that is causing active session database records to be deleted? -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator -- Hugh Irvine h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Delayed Stop Record and Active Sessions
Hi Rohan, I think you pretty much should be deleting sessions using the session id included in the delete criteria, for accuracy. But, NOT using the session id in your count query. The 'state limit' function i think you are referring to is tough to do. I assume you mean user session limits. I don't think you can actually implement session limits accurately. It's just not possible to do it accurately. yes, the options are there and the idea exists, but i don't think it can ever be as accurate as you would expect it to be. Even if you solve your issues described here, there's always a possibility active sessions fail/drop/die and your device still holds onto that session for a given time until it realize that the session truly is lost, then sends the Stop packet. Maybe your problem is not delayed stop packets, but sessions that just have not stopped yet because the device still thinks the session is active. So ya, when user logs back in, if you for example have session limits of 1, you are now rejecting your user. My personal experience is you need to have a very solid infrastructure (like fiber) to your customers and a low 'keep alive' time in order to have strict user session limits. But, for an infrastructure like cable/dsl where sync's are lost, things drop, and other problems, you may want to think about using n + 1. Meaning, your desired session limit, plus 1. This allows your customer to always log back in if their session drops but they're old session still shows active. Yes, they can now have 1 more session than you want to allow. It's a trade off. If you want to be strict, you have to expect your users to be rejected due to dead sessions. On 21/02/14 04:21 PM, rohan.henry @cwjamaica.com wrote: Thanks for the feedback Heikki. I am thinking that the suggestion would solve the problem but defeats the state limit function. It means that a connection would now become unique based on Acct-Session-Id which changes for every connection and would grant access to the same user multiple times since the new Acct-Session-Id will not allow a database match. Rohan On Wed, Feb 19, 2014 at 3:40 PM, Heikki Vatiainen h...@open.com.au mailto:h...@open.com.au wrote: On 02/19/2014 09:22 PM, rohan.henry @cwjamaica.com http://cwjamaica.com wrote: How can fix an issue where the DeleteQuery statement in my Sessions DB config deletes the row for a new active session because of a delayed Stop record? A quick idea: Do you think the DeleteQuery could be changed to include Acct-Session-Id in the query. That is, the NAS-Port, etc, and Acct-Session-Id must match the existing entry. If the session has been replaced, the delete will not match any rows because the new entry on the row it would otherwise match has a different session id that belongs to the new session. Please let us know how this works. Thanks, Heikki Scenario: 1. A session is up (and row entered in the database for active session) 2. The session is dropped because of a premature disconnection (eg. modem line cable unplugged) but Stop record is delayed. 3. New session is created after modem line cable is restored (and after DeleteQuery statement removes database row for previous session) 4. The delayed Stop record finally comes in - the DeleteQuery statement now removes the row for the active session (An unwanted behavior). How do I compensate for the delayed Stop record that is causing active session database records to be deleted? -- Heikki Vatiainen h...@open.com.au mailto:h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au mailto:radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] AuthLog SYSLOG - LogOpt PID
On 02/21/2014 05:58 PM, Kurt Bauer wrote: Too easily find the logs from various servers apart I added a custom LogIdent parameter per Server, which works as expected. The problem now is, that Radiator appends the pid in square brackets to the LogIdent, which means, that the central tool identifies a new source whenever radiator is restarted, as the LogIdent as a whole changes. Is there away to omit the pid? Hello Kurt, have you tried using for example, cons as LogOpt option value? It appears this option is ignored by the recent Sys::Syslog modules. I tried with just leaving LogOpt empty, which apparently doesn't work. As a more permanent solution, I think an empty value can be allowed by Radiator for LogOpt to turn off any non-default options. Thanks, Heikki -- Heikki Vatiainen h...@open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP, DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc. ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
