FreeRadius 3.0.10, radclient status failure

[Arran Cudbard-Bell]

> On 2 Nov 2015, at 21:40, Alan DeKok <aland at deployingradius.com> wrote:
> 
> On Nov 2, 2015, at 9:31 PM, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
>> I believe the previous behaviour was correct,
> 
>  As the author of RFC 5997, I would suggest that the default is to expect Access-Accept.

Yeah it gives you an unfair advantage, you can sprinkle SHOULDs everywhere and then claim the behaviour's RFC complaint :)

>> but this'll help the people who can't read log output that explains in detail what the problem was and how to fix it.
> 
>  The problem is you don't have to specify attribute filters when sending Access-Request packets.  So the treatment of Status-Server in radclient is magical and unexpected...

I like programs to make educated guesses, and when they can't, to tell you they can't, because it's often more work debugging false assumptions.  Anyway.

Reading the RFC it seems like responding with Access-Accept, Accept-Reject or Accounting-Response is legal irrespective of the port or service, so accepting one of those three types is probably the correct behaviour.

-Arran

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20151102/3aa8225a/attachment.sig>