Hello. 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. All IDs were used and it returned to 0. Both of the ID-0 packets were valid and had the same src/dst ip/port and length, but the request authenticators and AVP(User-Name) were different. So, please let me ask two questions about it. [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. 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. 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. 4.1. Access-Request Upon receipt of an Access-Request from a valid client, an appropriate reply MUST be transmitted. I was wondering if checking AVPs at least User-Name might not be bad, or should I think conflict is included in duplication? [Q2] If I try to skip the duplicate/conflict check, is it OK that setting the member "nodup" of struct rad_listen to true? I'd appreciate it.
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.
Thank you for your answer, Alan. What you wrote makes sense to me. Here's my understanding. If there's something wrong, please point it out. Otherwise, no reply is needed. [Criteria to see if packets are duplicate] Code, ID, src/dest port, src/dest IP address, and request authenticator # On this point, contents(AVPs) are never picked up. [As for conflicting packets] As far as the above applies, they're similar to duplicate packets, and the difference is that the former have different request authenticators and AVPs. Regards
participants (2)
-
Alan DeKok -
Yuka K