About definition of conflicting condition

[Alan DeKok]

On Apr 19, 2017, at 9:32 PM, Yuka K <kyuka8632 at gmail.com> wrote:
> During fast-requesting tests on ver.3.0.13, I found the following
> errors in the log.
> 
> Sun Apr 16 15:04:36 2017 : Error: Received conflicting packet from
> client localhost port 30430 - ID: 0 due to unfinished request.
> Giving up on old request.

  Which means that the client sent a new packet of ID 0, before the server was done processing an old packet of ID 0.

> [Q1]
> I thought Access-Accept was returned, but like this case, even if AVPs
> are different and valid, the new one is regarded as a conflicting one.
> Then, if the previous request's process is under QUEUED or RUNNING,
> it's dropped.

  Yes.

> I've read RFC 5080 about "duplicate", but I want to know the definition
> of a "conflicting" packet based on RFCs, as the following is mentioned
> in RFC 2865.

  RFC 2865 is years old, and is silent on a large number of topics.  That's why RFC 5080 was written, and RFC 6158.

>  3.1.  Packet Format
>  The RADIUS server can detect a duplicate request if it has the same
>  client source IP address and source UDP port and Identifier within
>  a short span of time.

  And, it has to compare the request authenticator.  See RFC 5080 Section 2.2.2 for a discussion on this topic.

  That's a *duplicate* packet.  Not a *different* packet.  i.e. a conflicting one.

>  4.1.  Access-Request
>  Upon receipt of an Access-Request from a valid client, an appropriate
>  reply MUST be transmitted.

  Yes, well, that statement is wrong.  Or at least, incomplete.

  What happens when a server has *two* packets from a clint with the same ID, src/dst ip/port, but different request authenticators?

  It cannot respond to both, as the client will ignore one of the replies.

> I was wondering if checking AVPs at least User-Name might not be bad,
> or should I think conflict is included in duplication?

  Checking packet contents is wrong.

> [Q2]
> If I try to skip the duplicate/conflict check, is it OK that setting
> the member "nodup" of struct rad_listen to true?

  Don't skip those checks.  The server won't behave well.

  The server is designed under the assumption that the packets are keyed by ID, code, src/dst ip/port.  If you change the code to allow *multiple* packets with the same key, bad things will happen.

  Alan DeKok.