Hello Gerard - The Status-Server request is processed by the Client clause - it doesn't get passed to any Handler(s).
See the code in Radius/Client.pm. regards Hugh On 23 Dec 2010, at 20:08, Gerard Alcorlo Bofill wrote: > Hello Hugh, > > any other ideas why is not capturing this kind of requests my handler? > > Thank you in advance. > > -- > Gerard > > Al 17/12/10 14:18, En/na Ryter Remo ha escrit: >> Hi Gerard, >> >> You are totally right - this hack won't survive any updates. >> A config based solution would definitely be preferred. >> >> You are right as well with the handler - at least a valid >> client handler will be needed in order to accept a request >> (or default handler will probably do it as well). >> >> Cheers, >> --Remo >> >> -----Original Message----- >> From: Gerard Alcorlo Bofill [mailto:[email protected]] >> Sent: Freitag, 17. Dezember 2010 13:18 >> To: Ryter Remo >> Cc: [email protected] >> Subject: Re: [RADIATOR] Control the Status-Server requests >> >> Hi Remo, >> >> thank you for your solution. >> This reminds me that I did something similar for an old version of >> Radiator but after upgrading I forgot to add this hack. >> If nobody can give an alternative I'll add your solution. But a config >> solution would be better because we wouldn't need to remember to add >> the hack after an upgrade. And in fact, my handler would have to match >> this queries, wouldn't it? >> >> Thanks! >> >> -- >> Gerard >> >> >> Al 17/12/10 12:57, En/na Ryter Remo ha escrit: >>> Hi Gerard, >>> >>> I had the same goal but I simply did a small change in Client.pm (look for >>> this code snippet: "if ($code eq 'Status-Server')"). >>> >>> There I just add a small if clause to ensure that only requests from the >>> localhost were accepted. Something like this: "if ($self->{Name} == >>> "127.0.0.1") { }" >>> >>> So I provide the detailed statistics for requests from localhost and only a >>> simple "I'm OK" when everybody else asks - I think this can be easily >>> extended to allow a list of trusted clients. >>> >>> Hope this helps. >>> --Remo >>> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of Gerard Alcorlo Bofill >>> Sent: Freitag, 17. Dezember 2010 12:38 >>> To: [email protected] >>> Subject: [RADIATOR] Control the Status-Server requests >>> >>> Hi, >>> >>> I'm trying to control the Status-Server requests. My goal is just to >>> permit the querying of my radius status only by some clients. >>> My first handler in the configuration is this one below, but no request >>> matches it. >>> >>> <Handler Request-Type=Status-Server> >>> <AuthBy FILE> >>> Filename /dev/null >>> # StripFromReply Reply-Message >>> AddToReply Reply-Message="Informacio no disponible" >>> </AuthBy> >>> AddToReply Port-Limit="9999" >>> AuthLog LogSenseTunel >>> </Handler> >>> >>> When this trial works, I'm going to strip the "Reply-Message" from the >>> answer. But for now, I just want to add some information to the answer >>> like the Port-Limit or another Reply-Message field. >>> >>> Any ideas why my "Status-Server" request don't match to any realm and >>> all Status-Server requests are answered with the status information? >>> >>> Thanks >>> >> _______________________________________________ >> radiator mailing list >> [email protected] >> http://www.open.com.au/mailman/listinfo/radiator > _______________________________________________ > radiator mailing list > [email protected] > http://www.open.com.au/mailman/listinfo/radiator 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
