About definition of conflicting condition
Alan DeKok
aland at deployingradius.com
Thu Apr 20 16:01:55 CEST 2017
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.
More information about the Freeradius-Users
mailing list