Suppose we're using PEAP or TTLS, and are in the middle of sending the
certificate chain (which is quite large and therefore requires fragmentation
into several messages). We've just received a RADIUS Access-Request containing
EAP Response with Id=5, and sent back a chunk of bytes in an EAP Req
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
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
On 24.11.2015 1.57, David Zych wrote:
> 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
On 11/30/2015 09:46 AM, Heikki Vatiainen wrote:
> On 24.11.2015 1.57, David Zych wrote:
>
>> 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
On 1.12.2015 0.28, David Zych wrote:
> Perhaps you meant rfc3748?
Yes. The other RFC number I referenced below was incorrect too.
> I do see a couple of very specific discard
> situations in rfc3748#section-4.1, but I wouldn't describe it as "many
> cases" or an overall pattern; in fact I would
