[RADIATOR] duplicate EAP Responses

[David Zych]

On 11/23/2015 09:26 AM, Heikki Vatiainen wrote:
> On 19.11.2015 3.08, David Zych wrote:
>
>> Side note regarding the code branch of EAP_21 and EAP_25 which
>> generates that "Nothing to read or write" message: even if a peer is
>> behaving weirdly, is it really ever a good idea to deliberately not
>> reply to an EAP Response?  The NAS is still waiting for a RADIUS
>> reply, and not sending one gives the impression that Radiator simply
>> dropped the RADIUS Access-Request (which is precisely the symptom
>> that led me down this rabbit hole).
>
> You can change this with 'EAPErrorReject' flag in the AuthBy. This
> changes the error behaviour so that a REJECT is sent instead of ignoring
> the request. It does sound that a reject is a better way to respond.
> We'll check this.

Thanks! I hadn't noticed that flag before.

Its description in the manual says "The RFCs say that IGNORE is the 
correct behaviour, but..." -- do you know what RFC language in 
particular this is referring to?  I am most definitely not an expert and 
might have overlooked something elsewhere, but I just noticed that 
rfc3579#section-2.2 seems to offer helpful and relevant guidance, 
recommending an Access-Reject for fatal errors or in the case of 
non-fatal errors an Access-Challenge option (up to a limit of 5 invalid 
EAP packets within a single session).

One more thought on this sub-topic: regardless of what RADIUS reply we 
eventually send back (or don't), I think it would be very helpful for 
Radiator to log EAP errors with at least INFO severity level so that 
they'll be visible in a typical production environment.  Currently I 
only see them in DEBUG.

> That comes to the main topic, thanks for the extensive debugging and the
> logs you have gathered. We'll check the duplicate handling too and I
> will get back to you, and the list, when I have something to report.

Looking forward to it!  I figured it might take some time.  :)

Thanks,
David