I get cranky when people don't read the documentation. After spending much time writing it, a good percentage of people go "nah, we're not going to to read that."
I understand your frustration. I tried my best to configure it on my own for many hours, combing through the documentation and list archives. Your documentation and dedication to this community is wonderful.
Despite that, I still try to help people. And for some reason, many people get mad when I point out that their questions are answered in the documentation, and that should probably have read it.
I (and many others I'm sure) appreciate it. I actually enjoy reading your colorful responses.
queries.conf:
Posting the default configuration files to the list isn't helpful.
This was posted because I've found inconsistencies in list archives where the authorize_reply_query section was commented out. I realize there are countless configuration scenarious, but during this time I've wished for a "beginning to end freeradius, mysql, simultaneous-use blocking" type tutorial. If people go Googling, they run across these threads, which (besides the Wiki and config comments) are how we troubleshoot similar scenarios. Would it not be prudent to clarify for future readers?
If you're going to run "checkrad", make sure that "snmpget" is installed, as the message above suggests.
Ah, SNMP, did not realize it was for simultaneous use checking. I thought SNMP would have only been used to disconnect users, and I'm using packet of disconnect so never looked into it further.
Otherwise, edit the client { ... } configuration, and set "nas_type = other".
Changing the nas_type from cisco to other (in the nas table) allowed the limit to work as you explained.
Setting "nas_type = other" means the server just believes whatever is in the accounting database, and doesn't run checkrad. That will likely fix the problem.
Is checkrad more efficient/preferred or should I have a reason not to trust the accounting database? For example, if the stop packet isn't received for whatever reason, does it periodically compare accounting database to actual situation and correct if a user appears online but isn't? I can see this situation causing a user to not be allowed online if something goes wrong with accounting. I just don't want to worry if that's not a likely scenario. --- The logging does not honor my msg_denied setting in radiusd.conf. The detail_YYYYMMDD logs show the output below. Can I expect my logs to not include the simultaneous use message when nas_type is set to other? Mon Aug 5 07:45:09 2019 Acct-Session-Id = "0/0/3/855_000E8E37" Cisco-AVPair = "ppp-disconnect-cause=User failed CHAP authentication" User-Name = "siptest" Acct-Authentic = RADIUS Cisco-AVPair = "connect-progress=Auth Failed" Cisco-AVPair = "nas-tx-speed=1000000000" Cisco-AVPair = "nas-rx-speed=1000000000" Acct-Session-Time = 0 Acct-Input-Octets = 0 Acct-Output-Octets = 0 Acct-Input-Packets = 0 Acct-Output-Packets = 0 Acct-Terminate-Cause = User-Error Cisco-AVPair = "disc-cause-ext=PPP CHAP Fail" Acct-Status-Type = Stop NAS-Port-Type = PPPoEoVLAN NAS-Port = 51285559 NAS-Port-Id = "0/0/3/855" Cisco-AVPair = "client-mac-address=e418.6bac.216d" Service-Type = Framed-User NAS-IP-Address = <Cisco ASR IP> Acct-Delay-Time = 0 Event-Timestamp = "Aug 5 2019 07:45:09 CDT" Tmp-String-9 = "ai:" Acct-Unique-Session-Id = "15d7264ee300eaa11e96e1b218f44ed9" Timestamp = 1565009109 Ben M.