Hello Jared -
At 13:38 -0800 01/1/15, [EMAIL PROTECTED] wrote:
>Hello,
>
> I'm stumped, I've looked, I've read, I've tried, and I am stumped.
>I'm evaluating radiator and I have had absolutely no success getting
>MaxSessions to function. Below is my config and debug information.
>
> I am testing this config with the radpwtst tool and the following
>arguments:
>partisan:/usr/local/radiator# radpwtst -user admin -password admin
>Called-Station-Id=1234 -s 127.0.0.1 -nostop
>
> I would expect, with my config and the command above, the second
>time the command is issued radiator would deny my login because of the
>"-nostop" argument and not having received a stop argument for the
>previous login. This does not appear to be the case.
>
> I have noticed one thing. If I I set MaxSessions 1 to MaxSession 0
>then it will deny the login. Below is the debug output from 2 tests with
>the above command.
.......
>
>Debug Output:
>
>partisan:/usr/local/radiator# ./radiusd -log_stdout -trace 4
>Mon Jan 15 15:43:57 2001: DEBUG: Reading users file
>/usr/local/radiator/users
>This Radiator license will expire on 2001-03-01
>This Radiator license will stop operating after 1000 requests
>To purchase an unlimited full source version of Radiator, see
>http://www.open.com.au/radiator/ordering.html
>
>Mon Jan 15 15:43:57 2001: INFO: Server started: Radiator 2.17.1 on
>partisan (DEM
>O)
>Mon Jan 15 15:44:23 2001: DEBUG: Packet dump:
>*** Received from 127.0.0.1 port 1035 ....
>Code: Access-Request
>Identifier: 68
>Authentic: 1234567890123456
>Attributes:
> User-Name = "admin"
> Service-Type = Framed-User
> NAS-IP-Address = 203.63.154.1
> NAS-Port = 1234
> NAS-Port-Type = Async
> User-Password =
>"<152><239>2<196><193>\<4><246><188>8<9><160><216>}x<153
>>"
> Called-Station-Id = "1234"
>
>Mon Jan 15 15:44:23 2001: DEBUG: Handling request with Handler 'Realm='
>Mon Jan 15 15:44:23 2001: DEBUG: Deleting session for admin,
>203.63.154.1, 1234
......
>
>Mon Jan 15 15:44:28 2001: DEBUG: Packet dump:
>*** Received from 127.0.0.1 port 1035 ....
>Code: Access-Request
>Identifier: 73
>Authentic: 1234567890123456
>Attributes:
> User-Name = "admin"
> Service-Type = Framed-User
> NAS-IP-Address = 203.63.154.1
> NAS-Port = 1234
> NAS-Port-Type = Async
> User-Password =
>"<152><239>2<196><193>\<4><246><188>8<9><160><216>}x<153
>>"
> Called-Station-Id = "1234"
>
>Mon Jan 15 15:44:28 2001: DEBUG: Handling request with Handler 'Realm='
>Mon Jan 15 15:44:28 2001: DEBUG: Deleting session for admin,
>203.63.154.1, 1234
Have a close look at the contents of the debug above.
You will notice that as you have not specified a NAS-IP-Address and
NAS-Port, they are defaulting to "203.63.154.1" and "1234".
You will also note that Radiator attempts to be self-healing in the
face of possible lost accounting packets, and so when it sees an new
access request from 203.63.154.1/1234 it will do a delete of that
entry from the session database. Therefore, every request using the
same values will always be accepted, which is of course what you want
in a production environment, as you don't want stale records in the
session database to result is refused connections.
The reason that this is done is because by definition on a "classic"
NAS, you can never have a new request from a NAS-IP-Address/NAS-Port
pair that already has a session active.
If you want to test multiple sessions you need to send radpwtsts with
-nostop *and* vary at least the NAS-Port value.
hth
Hugh
--
NB: I am travelling this week, so there may be delays in our correspondence.
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
