a.cudbardb at freeradius.org
Fri Feb 7 12:57:33 CET 2014
On 6 Feb 2014, at 18:55, Alan DeKok <aland at deployingradius.com> wrote:
> Arran Cudbard-Bell wrote:
>> Hm, ok I was wrong, it does always forward retries, it's only when the request
>> is waiting to be processed or being processed by a worker that it ignores the
> Yes. That was the subject of some debate in the IETF RADIUS working
> group. The proxy acts as a "pass through" device for retransmits.
I guess that's the root of the fragment reassembly debate.
> But if the server is still working on the reqeust, the answer is
> *unknown*. So it can't proxy it, it can't respond, and it can't do
> anything other than ignore the retransmit.
>> Doesn't seem that's entirely sensible, or consistent, but ok...
> It's really the only choice.
> The server could do re-transmits itself. It did that in version 1.
> But the code was complicated and fragile. And the other people in the
> RADIUS WG though doing that would break things in the network.
I was more thinking about it in terms of the server imposing a cap on
the retransmit rate.
I've had NAS go crazy and repeatedly spam the server with Auth and Acct
requests, and it'd be nice to stop that craziness from accidentally
DoSing the proxy chain.
>> But the status checks themselves will be retried.
> Because FreeRADIUS originated the packet, and is acting like a client.
> Clients do retransmits...
Sure. I was just clarifying Buxey's response. It was unclear whether the
OP was asking whether retransmits of Access-Requests were performed when
status-server checks were enabled, or whether the status-server messages
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...
Size: 881 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Freeradius-Users