P.S. Sorry, I posted to the developers-list, but I meant the users-list, so here it should be discussed: M. S. wrote:
Can I put this in bugzilla? Seems like simultaneous use is completely broken in 2.x which is a fairly significant feature.
To me checkrad seems to be broken too. I'm using 2.0.5 without virtual servers. Checkrad says, my NAS is Unknown when it is invoked, although I have it in my clients.conf: client testerx { ipaddr = 212.x.x.x secret = xxxxxxx nastype = erx } radiusd -X [...] auth: user supplied User-Password matches local User-Password +- entering group session expand: /usr/local/var/log/radius/radutmp -> /usr/local/var/log/radius/radutmp expand: %{User-Name} -> smith checkrad: Unknown NAS 212.x.x.x, not checking ++[radutmp] returns ok Multiple logins (max 1) [MPP attempt]: [smith] (from client testerx port 1610612780 cli #erx705#E60#44) Found Post-Auth-Type Reject WARNING: Unknown value specified for Post-Auth-Type. Cannot perform requested action. Sending Access-Reject of id 88 to 212.x.x.x port 50000 Reply-Message := "\r\nYou are already logged in - access denied\r\n\n" Finished request 2. [...] For our customers I have Simultaneous-Use := 1 in my users-file and checkrad is invoked, when a stale session in radutmp is found: # radwho -ir smith,04279558,PPP,S1610612780,Wed 12:2,212.x.x.x,x.x.x.x It is possible, that in 2.0.3 checkrad was ok, because I noticed no problems with Simultaneous-Use there ... but maybe accidentally. Is it really a bug in freeradius-2.0.5? oz
oz wrote:
M. S. wrote:
Can I put this in bugzilla? Seems like simultaneous use is completely broken in 2.x which is a fairly significant feature.
I would agree. I'm not sure why it's broken...
To me checkrad seems to be broken too. I'm using 2.0.5 without virtual servers. ... checkrad: Unknown NAS 212.x.x.x, not checking
Arg. I don't know why that doesn't work.
It is possible, that in 2.0.3 checkrad was ok, because I noticed no problems with Simultaneous-Use there ... but maybe accidentally.
If it works in 2.0.3 that would be good to know. It would help track down where the problem is.
Is it really a bug in freeradius-2.0.5?
Yes. Alan DeKok.
Alan DeKok wrote:
oz wrote:
M. S. wrote:
Can I put this in bugzilla? Seems like simultaneous use is completely broken in 2.x which is a fairly significant feature.
I would agree. I'm not sure why it's broken...
To me checkrad seems to be broken too. I'm using 2.0.5 without virtual servers. ... checkrad: Unknown NAS 212.x.x.x, not checking
Arg.
I don't know why that doesn't work.
It is possible, that in 2.0.3 checkrad was ok, because I noticed no problems with Simultaneous-Use there ... but maybe accidentally.
If it works in 2.0.3 that would be good to know. It would help track down where the problem is.
Is it really a bug in freeradius-2.0.5?
Yes.
Alan DeKok.
Hello, I guess, I tracked it down. I started radiusd -X of version 2.0.3 in my 2.0.5 environment, and compared the console messages between the two versions. I noticed, that 2.0.5 didn't read in all my NAS clients. It stopped, where one client definition had no secret set, with this message: [...] client as5200 { ipaddr = 192.168.101.2 require_message_authenticator = no shortname = "as5200" } /usr/local/etc/raddb/clients.conf[310]: secret must be at least 1 character long Version 2.0.5 then rejects all users from *all the other* clients, when checkrad is invoked and when radiusd wasn't able to read in the clients.conf before completely: auth: user supplied User-Password matches local User-Password +- entering group session expand: /usr/local/var/log/radius/radutmp -> /usr/local/var/log/radius/radutmp expand: %{User-Name} -> smith checkrad: Unknown NAS 212.x.x.x, not checking ++[radutmp] returns ok Multiple logins (max 1) [MPP attempt]: [smith] (from client testerx port 1610612780 cli #erx705#E60#44) Found Post-Auth-Type Reject WARNING: Unknown value specified for Post-Auth-Type. Cannot perform requested action. Sending Access-Reject of id 9 to 212.x.x.x port 50000 Reply-Message := "\r\nYou are already logged in - access denied\r\n\n" Finished request 2. Going to the next request When the clients.conf contains only valid clients, checkrad is invoked as it should: auth: user supplied User-Password matches local User-Password +- entering group session expand: /usr/local/var/log/radius/radutmp -> /usr/local/var/log/radius/radutmp expand: %{User-Name} -> smith checkrad: unknown NAS type erx rlm_radutmp: Failed to check the terminal server for user 'smith'. ++[radutmp] returns fail Login OK: [smith] (from client testerx port 1610612780 cli #erx705#E60#44) (... *this* checkrad message is ok, because the original checkrad-script isn't aware of my custom NAS type erx). So it is not a severe bug of checkrad in 2.0.5, it just behaves strange, when some clients in clients.conf are no correctly defined. Kind regards, oz
oz wrote:
I guess, I tracked it down. I started radiusd -X of version 2.0.3 in my 2.0.5 environment, and compared the console messages between the two versions.
I noticed, that 2.0.5 didn't read in all my NAS clients. It stopped, where one client definition had no secret set, with this message: [...] client as5200 { ipaddr = 192.168.101.2 require_message_authenticator = no shortname = "as5200" } /usr/local/etc/raddb/clients.conf[310]: secret must be at least 1 character long
Ok... so that client definition was wrong. Version 2.0.5 *should* fail to start at that point. Hmm... I've tracked down the issue and committed a fix to CVS.
Version 2.0.5 then rejects all users from *all the other* clients, when checkrad is invoked and when radiusd wasn't able to read in the clients.conf before completely:
Well... yes. If it can't read the clients, it doesn't know about them. So the underlying issue is that the client configuration was wrong, and the server was too liberal in allowing an invalid configuration. The checkrad code still works.
When the clients.conf contains only valid clients, checkrad is invoked as it should:
i.e. "when the server starts properly", checkrad works. When the server doesn't start properly, it doesn't.
So it is not a severe bug of checkrad in 2.0.5, it just behaves strange, when some clients in clients.conf are no correctly defined.
I've fixed it. The server now refuses to start if the client definitions are wrong. Alan DeKok.
On Wed, 02 Jul 2008 18:02:18 +0200 Alan DeKok <aland@deployingradius.com> wrote:
i.e. "when the server starts properly", checkrad works. When the server doesn't start properly, it doesn't.
So it is not a severe bug of checkrad in 2.0.5, it just behaves strange, when some clients in clients.conf are no correctly defined.
I've fixed it. The server now refuses to start if the client definitions are wrong.
Alan DeKok.
Thank you, Alan! oz
participants (2)
-
Alan DeKok -
oz