On Apr 19, 2017, at 9:32 PM, Yuka K <kyuka8632@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.