Hello Alan, Hello Gerard -
What exactly would you like to see happen with these requests?
Please refer to this document for details of what is recommended:
http://tools.ietf.org/html/draft-ietf-radext-status-server-09
And here is what currently happens:
…..
Radiator-4.7 hugh$ perl radpwtst -noauth -noacct -code Status-Server -auth_port
1645 -acct_port 1646
sending Status-Server…
Fri Dec 24 09:45:47 2010: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 65514 ....
Code: Status-Server
Identifier: 77
Authentic: R<229><141>+<151><150><144><189>I<178><130><239>J<215><183><27>
Attributes:
Fri Dec 24 09:45:47 2010: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 65514 ....
Code: Access-Accept
Identifier: 77
Authentic: <195><246><30><246><134><130><215><20><224><163>j<166>b<3><18>f
Attributes:
Reply-Message = "Radiator Radius server version 4.7"
Reply-Message = "Running on TiTi.local since Fri Dec 24 09:44:48 2010"
Reply-Message = "0 Requests in the last second"
Reply-Message = "0 Access accepts"
Reply-Message = "0 Access challenges"
Reply-Message = "0 Access rejects"
Reply-Message = "0 Access requests"
Reply-Message = "0 Accounting requests"
Reply-Message = "0 Accounting responses"
Reply-Message = "0 Bad authenticators in authentication requests"
Reply-Message = "0 Bad authenticators in accounting requests"
Reply-Message = "0 Total Bad authenticators in requests"
Reply-Message = "0 Dropped access requests"
Reply-Message = "0 Dropped accounting requests"
Reply-Message = "0 Total dropped requests"
Reply-Message = "0 Duplicate access requests"
Reply-Message = "0 Duplicate accounting requests"
Reply-Message = "0 Total duplicate requests"
Reply-Message = "0 Malformed access requests"
Reply-Message = "0 Malformed accounting requests"
Reply-Message = "0 Total proxied requests with no reply"
Reply-Message = "0 Total proxied requests"
Reply-Message = "0 Total requests"
Reply-Message = "0 Average response time"
OK
…..
Note that there is an optional flag for the <Client ….> clause(s) to send
additional information, but this is disabled by default as its use can easily
generate UDP packets that are too large to send.
>From the Radiator 4.7 reference manual ("doc/ref.pdf"):
5.5.15 StatusServerShowClientDetails
Normally, when a Status-Server request is received, Radiator will reply with
some sta- tistics including the total number of requests handled, the current
request rate etc. When you set the optional StatusServerShowClientDetails for a
Client, the reply to Status- Server will also include details about that
Client. This can result in a lengthy reply packet. The default is not to send
the additional Client details for any Clients.
<Client xxx>
# Show stats about this client in Server-Status replies
StatusServerShowClientDetails
Secret xxx ....
</Client>
regards
Hugh
On 23 Dec 2010, at 22:19, Alan Buxey wrote:
> hi,
>
> is there a quick hack for the status-server for client so that it just sends
> an 'UP' or 'OKAY' back rather than try authentication or send back server
> details?
>
> alan
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
