Maintained by: NLnet Labs

[Unbound-users] Potential Bug

W.C.A. Wijngaards
Thu Jun 30 13:04:21 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Robert,

On 06/29/2011 04:59 PM, W.C.A. Wijngaards wrote:
> Hi Robert,
> 
> On 06/29/2011 04:32 PM, Robert Fleischman wrote:
>> I said:
> 
>>>> 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?
> 
>> Your response:
> 
>>> 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.
> 
>> Okay, I agree.
> 
>> Consider this:  Assume my Internet connection goes out for a bit, thus
>> no replies come
>> in, so, queries pile up quickly.
> 
>> Consider the following code path during this outage:
> 
>> mesh_new_client() -> mesh_make_new_space() -> Code in
>> mesh_make_new_space() decides jostle is needed ->
>> mesh_state_delete() -> mesh_state_cleanup()
> 
>> That causes num_reply_addrs to NOT be decremented.
> 
>> Now my Internet connection comes back, BUT, num_reply_addrs got so
>> high that the "16 times" limit goes into effect.  Now I get all my
>> queries dropped even though there is no error or problem anymore.
> 
>> My temporary outage caused num_reply_addrs to grow and there is no way
>> for it to come back down.  So, I'm stuck dropping queries until a
>> restart of the server.
> 
> You are correct, and I was wrong.  It should be fixed.
> 
> Thanks for the report (and persistence :-) )

Fixed in the svn trunk development of unbound.

This code path is triggered by jostled queries.  It is not triggered by
ordinary timeouts or servfails.

Best regards,
   Wouter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJODFg0AAoJEJ9vHC1+BF+NY7EP/09UNK3W3/GIL1cD8LrQaJfJ
sKBTm9JSoAYrq7EM3AdfF9NCVhxooMZn77V+g7CSz0+DF90JTQ0zl17hKmn46opG
fl3zPIvvzH/bfV43Lhk+ybusayEW8rS/xQBMxBIfye2hEH+s9S4QRb26slg5+RE2
M/DcMby1A+xMzcjt4uP81ecSKRA/lkws7Bpdm9DwAb4JwTb21wQfAkFF8jmcmN1s
NIVYoL7WOMahc+pRbGveffVN86S6+qwhemc+4ZUkf5ZbF7MVIiJYVJ5HeFhe/rum
5cLiQW6NzAfSwgXqn1gT84XDJfK4VEdPOBVh/24MgBoNu7PCqOrq8sD4pZ0LuAWo
2QuGvJQtCD0usCsEw+k1ti48Ut2xb9YhBzS2Y4jGsqpezf9MuF5CGSM95Uv6CWEi
enS93f8Khzc86G8iwTtE0pACbXGD2mEraIR76iTin0bko19Zf0sP03HOt0eKPhM7
a6enlNTpBl5tB3hegRm9oR5x9YzP0C8uL1C0V41QwBYM4VA8S/jffEqebmqWequq
HoPhi0ZsqecNZSg3CmARwMvTs7kvGPsc+7nR27h6HXYDNdvGXsM0t+mMivFv3p4N
V+jMKTAUZxRsrhNioqRAcc6UdEug/d8Esces+HvfdjiGODR18otJgyVI5Q41N5yy
b9KgIOuom4AOmW97hu3g
=Qty3
-----END PGP SIGNATURE-----