FreeRadius 3.0.10, radclient status failure
Freeradius users, I upgraded from the freeradius package provided in Ubuntu 14.04.03 to Freeradius 3.0.10 and the radclient command I was using to track the status of the server is no longer providing the server status as it used to: # echo "Message-Authenticator = '0x00',FreeRADIUS-Statistics-Type = 3" | /usr/local/bin/radclient -c 1 -r 1 -t 8 -s 127.0.0.1:18121 status adminsecret (0) Can't determine expected response to Status-Server request, specify a well known RADIUS port, or add a Response-Packet-Type attribute to the request of filter # echo "Message-Authenticator = 0x00" | radclient 127.0.0.1:18121 status adminsecret (0) Can't determine expected response to Status-Server request, specify a well known RADIUS port, or add a Response-Packet-Type attribute to the request of filter previously the status module was listening on 18120, but now there is a section responsible for authentication: $PREFIX/sites-enabled/inner-tunnel: server inner-tunnel { ... listen { ipaddr = 127.0.0.1 port = 18120 type = auth } $PREFIX/sites-enabled/status: server status { listen { type = status ipaddr = 127.0.0.1 port = 18121 } ... Any advice is appreciated, Dennison Williams
On Nov 2, 2015, at 6:41 PM, Systems Administrator <dennison@dark-heart.net> wrote:
I upgraded from the freeradius package provided in Ubuntu 14.04.03 to Freeradius 3.0.10 and the radclient command I was using to track the status of the server is no longer providing the server status as it used to:
# echo "Message-Authenticator = '0x00',FreeRADIUS-Statistics-Type = 3" | /usr/local/bin/radclient -c 1 -r 1 -t 8 -s 127.0.0.1:18121 status adminsecret (0) Can't determine expected response to Status-Server request, specify a well known RADIUS port, or add a Response-Packet-Type attribute to the request of filter
I've pushed a fix to the v3.0.x branch in git. The default expected response should be Access-Accept. Alan DeKok.
On 2 Nov 2015, at 21:14, Alan DeKok <aland@deployingradius.com> wrote:
On Nov 2, 2015, at 6:41 PM, Systems Administrator <dennison@dark-heart.net> wrote:
I upgraded from the freeradius package provided in Ubuntu 14.04.03 to Freeradius 3.0.10 and the radclient command I was using to track the status of the server is no longer providing the server status as it used to:
# echo "Message-Authenticator = '0x00',FreeRADIUS-Statistics-Type = 3" | /usr/local/bin/radclient -c 1 -r 1 -t 8 -s 127.0.0.1:18121 status adminsecret (0) Can't determine expected response to Status-Server request, specify a well known RADIUS port, or add a Response-Packet-Type attribute to the request of filter
I've pushed a fix to the v3.0.x branch in git. The default expected response should be Access-Accept.
I believe the previous behaviour was correct, 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. Though it'll now fail in an obscure and annoying way (that doesn't explain exactly what the problem was an how to fix it) when sending Status-Server requests to a non standard accounting port. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Nov 2, 2015, at 9:31 PM, Arran Cudbard-Bell <a.cudbardb@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.
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 suggest that having magical behaviour is wrong. I suggest that having defaults which work in most cases are correct and useful.
Though it'll now fail in an obscure and annoying way (that doesn't explain exactly what the problem was an how to fix it) when sending Status-Server requests to a non standard accounting port.
Or, we could fix radclient to not care what the response is to Status-Server. That would be the better approach. Alan DeKok.
On 2 Nov 2015, at 21:40, Alan DeKok <aland@deployingradius.com> wrote:
On Nov 2, 2015, at 9:31 PM, Arran Cudbard-Bell <a.cudbardb@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Systems Administrator