rihad wrote: > Ivan Kalik wrote: >> Exactly. The only problem being your inability to comprehend that >> freeradius is not faulty but it is your perl script that can't cope. > Why do you not understand that even if I put "sleep 1" right before > finishing a request in my auth/acct Perl scripts, meaning each request > would take at least 1 second to process, freeradius shouldn't care!
Everyone understands that. No one *cares*. It's not *relevant*. > It > shouldn't be canceling the current request if another packet arrives a > couple of seconds later! Yes, it should. You've been told why. If you don't understand the explanation, go read the messages again. > Being swamped by requests it SHOULD be able to > make progress, ... working on requests that it will send to the NAS, and which the NAS will ignore. It's like asking a web server to continue processing a client request after the client has closed the TCP connection. After all, the web server is still making progress! Let's waste more CPU time rendering content that will *NEVER* make it to the client! That's a dumb idea. > and not be stomping on its toes canceling current > requests without any progress. And for that when.tv_sec = 1 should be a > bit higher, so it SHOULD be configurable, because some poor soul might > still prefer 2-5 second NAS timeout. If your NAS is transmitting a two packets with the same source IP, port, RADIUS code, and ID within 1 second... it's broken. No amount of "fixing" FreeRADIUS will change that. No amount of outright denial will change that. No amount of ignoring our explanations will change that. Now stop arguing on this list. It is impossible to convince us that wasting CPU time is a good idea. (And ignoring our explanations makes it clear that you have no interest in educating yourself) You have the source code to the server: butcher it to do whatever you want. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
