Is only ever set to 1 from what I can grep of the code. So when listen.c calls /* * Find the original request in the request list */ oldreq = rl_find_proxy(packet); which in turn executes node = rbtree_find(proxy_tree, &myrequest); if (node) { maybe = rbtree_node2data(proxy_tree, node); rad_assert(maybe->proxy_outstanding > 0); maybe->proxy_outstanding--; /* * Received all of the replies we expect. * delete it from both trees. */ if (maybe->proxy_outstanding == 0) { rl_delete_proxy(&myrequest, node); } } pthread_mutex_unlock(&proxy_mutex); return maybe; How can it be possible (what parts of the code have I not paid sufficient attention to) for this to happen in listen.c ? /* * If there is already a reply, maybe this one is a * duplicate? */ if (oldreq->proxy_reply) { if (memcmp(oldreq->proxy_reply->vector, packet->vector, sizeof(oldreq->proxy_reply->vector)) == 0) { radlog(L_ERR, "Discarding duplicate reply from home server %s port %d - ID: %d for request %d", inet_ntop(packet->src_ipaddr.af,
Joe Maimon <jmaimon@ttec.com> wrote:
Is only ever set to 1 from what I can grep of the code.
Did I mention that code sucks? I've bene looking into redesigning the "refresh_request" code, which will touch this area, too. I've been trying to avoid edge conditions, race conditions, and still have the code readable, without the dumb bugs it has today. So far, either I haven't had time, or I haven't been successful. Alan DeKok.
Alan DeKok wrote:
Joe Maimon <jmaimon@ttec.com> wrote:
Is only ever set to 1 from what I can grep of the code.
Did I mention that code sucks?
As all my code looks far far worse, I can hardly say that. I chalk up your pronouncment on the condition of the code as originating from your excellent high standards.
I've bene looking into redesigning the "refresh_request" code, which will touch this area, too. I've been trying to avoid edge conditions, race conditions, and still have the code readable, without the dumb bugs it has today.
I thank you and appreciate all the enormous efforts you and the other developers put into freeradius, a truly outstanding product, notwithstanding this details that I have found myself getting involved in due to my predilection for using cvs unstable software.
So far, either I haven't had time, or I haven't been successful.
Whatever you manage to do, I will be gratefull and try to test it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
Joe Maimon <jmaimon@ttec.com> wrote:
I thank you and appreciate all the enormous efforts you and the other developers put into freeradius, a truly outstanding product, notwithstanding this details that I have found myself getting involved in due to my predilection for using cvs unstable software.
Thanks. Your comments have helped catch a few things we've missed. Before 2.0 is released, we need to: a) fix refresh_reques b) clean up realm & home server handling (which will add IPv6) c) patch rlm_eap to allow modules to link to each other d) write docs explaining the differences between 1.0 and 2.0 Alan DeKok.
Frank Cusack <fcusack@fcusack.com> wrote:
Release 1.1? Or is that going to be skipped.
Given that the CVS head (mostly) supports IPv6, and has a whack of other changes, I'd like to move to 2.0. This also lets us make minor but necessary incompatible changes, and tell people "It's OK, because it's a major version rev". Alan DeKok.
participants (3)
-
Alan DeKok -
Frank Cusack -
Joe Maimon