andreapepa wrote: > Ok, but that field is not present in radpostauth too...and i mean > ...correlate between tables
As Arran said, you can't. This is RADIUS. It's not perfect. >> How do you know? > > doing the tests with jradius i've noticed that if you send an auth + start > request without a stop you can create this situation, would be the case when > the nas reboot or power down in the middle of the auth phase, and so you > have this kind of entry in DB. I understand that. What I meant was how does the RADIUS server know when a particular user is not online? The answer is "It doesn't". > Yes reject auth are not stored but replies are, if configured to log them, > would be helpful to modify the postauth query to insert the "unique session > ID" in a new radpostauth field? This is RADIUS. It can't be done in any reliable way. > Finally.. i also can check fro time to time the packets or byte fields to > see if the sessios is still alive...but this metod would not be better than > matching with replies in radpostauth , ...i believe. Ask the NAS is the session is still alive. This is RADIUS. The RADIUS server has no idea what the user session is doing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
