Simultaneous-Use and mysql

Ben McTee eastex.benmctee at
Mon Aug 5 16:01:27 CEST 2019

>   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

>   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

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.

More information about the Freeradius-Users mailing list