<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Yes, Peter's commit fixed the issue I saw. It removed the srand()
from RLS so that it no longer affected the Via branch param
generator.<br>
<br>
Do you think that the Via branch should be protected against this?
For example using the srutils unique ID function instead of rand()?<br>
<br>
Hugh<br>
<br>
On 20/04/2012 11:39, Daniel-Constantin Mierla wrote:
<blockquote cite="mid:4F913CE2.7060301@gmail.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hello,<br>
<br>
had not time yet to get and look properly at this thread, is the
issue fixed by Peter's commit related to some srand() usage?<br>
<br>
Cheers,<br>
Daniel<br>
<br>
On 4/16/12 1:15 PM, Hugh Waite wrote:
<blockquote cite="mid:4F8BFF3A.4080902@crocodile-rcs.com"
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
I now realise that rls was deliberately using the same sequence
of random numbers to satisfy RFC4662 §5.5<br>
<blockquote>
<p>5.5. Instance Attributes</p>
<p> Each resource element contains zero or more instance
elements. These<br>
instance elements are used to represent a single notifier
for the<br>
resource. For event packages that allow forking, multiple
virtual<br>
subscriptions may exist for a given resource. Multiple
virtual<br>
subscriptions are represented as multiple instance elements
in the<br>
corresponding resource element. For subscriptions in which
forking<br>
does not occur, at most one instance will be present for a
given<br>
resource.</p>
<p> The "id" attribute contains an opaque string used to
uniquely<br>
identify the instance of the resource. The "id" attribute is
unique<br>
only within the context of a resource. Construction of this
string<br>
is an implementation decision. Any mechanism for generating
this<br>
string is valid, as long as uniqueness within the resource
is<br>
assured.</p>
</blockquote>
Seeding srand() with the values 0, 1, 2... always gives the same
sequence of ID strings. Maybe someone has an opinion on whether
this should be implemented differently, or whether a value
should be stored for situations where multiple resource
instances are removed/reordered.<br>
<br>
Maybe kamailio should use a unique ID (from srutils) in the Via
header for uac requests (in modules/tm/h_table.h) anyway, to
prevent a module from affecting Via branch params by using
srand().<br>
<br>
Regards,<br>
Hugh<br>
<br>
On 13/04/2012 15:26, Hugh Waite wrote:
<blockquote cite="mid:4F883782.6060706@crocodile-rcs.com"
type="cite">Hi, <br>
One of the places that uses rand() is
modules/tm/h_table.c:init_synonym_id . Requests generated by
kamailio (as a uac) use this to generate the Via branch tag.
If any module calls srand(), it affects the Via branch for
subsequent requests. <br>
<br>
The actual bug we found is in rls/notify.c:generate_string().
The add_resource_instance() function will re-seed srand() with
0 (zero), leading to nearly every NOTIFY sent by rls having
the same "random" number in the Via branch. I am sure this was
the cause of lost replies, timeouts and dropped subscriptions
that we were seeing (and appears to have gone away after
removing it). <br>
<br>
Although, I could just remove the srand from rls notify.c, I
wondered if it should be using a different random function,
and also whether init_synonym_id should use something more
unique for the Via branch parameter. <br>
<br>
A quick check has shown a few places that call srand() within
the code, although they probably have less drastic
consequences. <br>
<br>
Regards, <br>
Hugh <br>
<br>
On 13/04/2012 14:01, Daniel-Constantin Mierla wrote: <br>
<blockquote type="cite">Hello, <br>
<br>
I haven't looked at the issue reported by Hugh, so by now
just comments on srutils/sruid. <br>
<br>
The idea was to have an unique id generator without linking
to an external library -- my first purpose was to use it for
temporary GRUU ids (RFC5627), I am just about to push to
master the gruu support in registrar/usrloc. <br>
<br>
Then I thought it might be useful in other places, such as
dialog unique id. <br>
<br>
I added it as part of lib, since its target usage was for
modules so far, but if needed for some core processing, the
two files (rather small by now) can be moved in the core. <br>
<br>
Cheers, <br>
Daniel <br>
<br>
On 4/13/12 2:50 PM, Henning Westerholt wrote: <br>
<blockquote type="cite">On Friday 13 April 2012, Hugh Waite
wrote: <br>
<blockquote type="cite">I have a question about random
number generation within kamailio. <br>
<br>
A number of modules use rand() to get a random value and
in some places <br>
is re-seeding with srand(). I believe this is dangerous
because rand() <br>
is used in the Via branch tag generator. <br>
We have detected some real bugs (where srand is
reseeding with 0 for <br>
every message, causing transaction mis-matching) but I'm
not sure of the <br>
correct way to fix this (other than remove srand()). <br>
<br>
Should all modules be using a 'core' random function
(e.g. in srutils?) <br>
? And if so, is this library documented? <br>
<br>
Regards, <br>
Hugh <br>
</blockquote>
Hi Hugh, <br>
<br>
for the purpose getting a pseudo-random number (i.e. not
for cryptographic <br>
functionality) we should consolidate on a single random
function. There is the <br>
recent introduced srutils/sruid code, then there exists a
(IMHO stronger) <br>
pseudo-random number generator in rand/fastrand and then
there is of course <br>
rand(). <br>
<br>
Maybe Daniel can comment about the purpose of the srutils
function, IMHO <br>
consolidating on fastrand or one of the stronger function
(d_rand etc..) from <br>
stdlib.h would be fine. <br>
<br>
The re-seeding the internal state of rand() with srand
during runtime sounds <br>
wrong toe me and should be removed/ fixed. <br>
<br>
Viele Grüße/ best regards, <br>
<br>
Henning Westerholt <br>
<br>
_______________________________________________ <br>
sr-dev mailing list <br>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
sr-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla
Kamailio Advanced Training, April 23-26, 2012, Berlin, Germany
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://www.asipto.com/index.php/kamailio-advanced-training/">http://www.asipto.com/index.php/kamailio-advanced-training/</a></pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Hugh Waite
Senior Design Engineer
Crocodile RCS Ltd.</pre>
</body>
</html>