I noticed that "mesh_new_client" will drop incoming queries if you
have more that "16" times "mesh->max_reply_states" (which is set to
the number of queries per thread).
Question: Why 16? What is the logic here? Shouldn't this be based
on memory and not a multiple of "number of queries per thread"?
Potential Bug: In "mesh_state_cleanup", I noticed that
"comm_point_drop_reply" is called to remove unset replies, HOWEVER, it
does not appear that either "stats_dropped" is incremented or more
importantly "num_reply_addrs" is not decremented. Doesn't this lack
of a decrement potentially cause the "16 times" limit go into effect and
prematurely drop queries?
I noticed that "mesh_new_client" will drop incoming queries if you
have more that "16" times "mesh->max_reply_states" (which is set to
the number of queries per thread).
Question: Why 16? What is the logic here? Shouldn't this be based
on memory and not a multiple of "number of queries per thread"?
It is to protect the memory from being flooded with reply addrs. Every
query that gets serviced needs to be able to have one or more reply
addrs, otherwise it is quite useless. So that is why it is based on the
number of queries per thread. And then some maximum above it. I have
not seen reports of the limit getting hit, perhaps in IPv6 if DoSed with
random source IPs.
Potential Bug: In "mesh_state_cleanup", I noticed that
"comm_point_drop_reply" is called to remove unset replies, HOWEVER, it
does not appear that either "stats_dropped" is incremented or more
importantly "num_reply_addrs" is not decremented. Doesn't this lack
of a decrement potentially cause the "16 times" limit go into effect and
prematurely drop queries?
The num_reply_addrs is decremented when a reply is sent (which can be an
error if the mesh state is removed because of an error). The
mesh_state_cleanup indeed does not cleanup the num_reply_addrs value
correctly, but this routine is only called from the mesh_state_delete
function. Thus it does not present a bug.