[reSIProcate] Issue with getRandomHex()

[Yannick Guay]

Hi Scott,

I made more testing recently, trying to isolating the problem a little
more. The first thing I tried was to execute the same set of tests on a
different platform (Debian 6.0.6 64bit) and I'm seeing the exact same
problem.

I will conduct more testing next week and, as well, I will try the patch I
suggested last week on Debian. In the interim please let me know if you
have any comments.

FWIW: our system will be deployed on ESXI so all tests are conducted on
VMWare, not bare metal.

best regards,
-Yannick Guay



2014-05-01 10:45 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:

> Hi again,
>
> A colleague here pointed me at another API which I tried (srand48 and
> lrand48, also part of standard library) and that seems to work better for
> me. The replacements exist on all modern Unix platforms (Solaris, Mac OS X,
> FreeBSD, Linux).
>
> Although Evan Jones describes this as not being thread safe (read this
> post here <http://www.evanjones.ca/random-thread-safe.html>), this could
> be a good starting point to work around the issue. I have only tested my
> scenario where the DUM is generating new transaction id and I've had
> success with it. I believe that's because all request for random numbers is
> coming from a single thread.
>
> I'm aware that not everybody is suffering of this but I'm confident it's
> solving a real issue so I'm posting the patch for review. Perhaps we should
> confirm whether it is safe to use by running a wider range of tests?
>
> thanks,
> -Yannick
>
>
> 2014-05-01 8:48 GMT-04:00 Yannick Guay <yannick.guay at gmail.com>:
>
> Hi Scott,
>>
>> We've started using 1.9 as of  last week on Centos 6.3. I've tested the
>> Random class separately and made it issue 20 8 byte long values without a
>> problem, I can hardly identify what could cause this? I will keep
>> investigating on my side and would be very thankful if anybody can give any
>> sort of recommendation on how to get that fixed.
>>
>> thanks,
>> -Yannick
>>
>>
>> 2014-04-30 17:02 GMT-04:00 Scott Godin <sgodin at sipspectrum.com>:
>>
>> Hi Yannick,
>>>
>>> What resip release are you using?  There was quite a bit of work put
>>> into the Random.cxx class a couple years ago to ensure random number
>>> generator is seeded automatically for each thread (see
>>> Random::initialize()).  If you are on an older release you may want to
>>> compare your version Random.cxx with the latest one from SVN.  Note also -
>>> there is a lot of platform depend code branches in this init logic, so your
>>> platform may be playing a role here.  What platform are you using?
>>>
>>> Scott
>>>
>>>
>>> On Wed, Apr 30, 2014 at 3:50 PM, Yannick Guay <yannick.guay at gmail.com>wrote:
>>>
>>>> Hi,
>>>>
>>>> I ran into an issue with DUM generating same transaction id several
>>>> times when my b2bua is handling multiple simultaneous calls.
>>>>
>>>> I'm using DialogUsageManager::makeInviteSession() which generates a
>>>> proper branch parameter for the outgoing call but when it's time to send
>>>> them down to the stack the branch parameter is set again
>>>> by DialogUsageManager::send() (line 1036 or so), but same value gets reused
>>>> for all calls. As a result, only the first call gets out of my gateway, all
>>>> other subsequent calls are considered bad and eventually get dropped by
>>>> TransactionState.
>>>>
>>>> Here is the line that I'm finding in log files.
>>>> 2014-04-30T15:12:27.854-04:00 Warning - B2BUA TU sent us a duplicate
>>>> INVITE: fix this!
>>>>
>>>> My knowledge of srandom and random is rather limited but I trust after
>>>> giving it a seed, then it should always hand off unique values?
>>>>
>>>> Any Ideas what I'm doing wrong?
>>>>
>>>> Best Regards,
>>>> -Yannick Guay
>>>>
>>>> _______________________________________________
>>>> resiprocate-devel mailing list
>>>> resiprocate-devel at resiprocate.org
>>>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20140509/73c7381d/attachment.htm>