The radpostauth table shows the rejects up until the point that a session starts in radacct and then the rejects stop in the radpostauth table, I wasn’t clear on that initially below. When the session arrives in the radacct table the customer goes back online like a full successful authentication has taken place. -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+greg.antic=stc.za.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: Friday, 13 January 2017 2:38 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: access reject problem On Jan 13, 2017, at 2:18 AM, Greg Antic <greg.antic@stc.za.com> wrote:
The user account has been disabled and the auth-type set as per radcheck output below. The logs show rejected for many hours and all of a sudden it will start a session however the postauth table shows it was rejected. It's almost like freeradius gets tired of saying no and eventually gives in and says yes.
That doesn't happen.
Below the radpostauth shows the continual rejects which it has been rejected all day then all of a sudden at 00:02:46 the session starts.
To be clear, the radpostauth table shows nothing but rejects. The radacct table shows a session.
Does anyone have an explanation or idea as to why this would occur?
The NAS is broken. What most people don't know is that authentication and accounting are entirely separate. The NAS doesn't need an Access-Accept to start an accounting session. It can just send accounting packets. So if the radpostauth table shows nothing but rejects, and there's a session in radacct... the NAS is broken. If you care to prove it to yourself, do: $ radsniff -r 'Packet-Type == Access-Accept' and leave that running for hours. You should see nothing being printed. That means the server isn't sending Access-Accept. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html