possible bug in ZRTP implementation - SRTP replay check failed!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I just realised my previous logcat logs are pretty sparse.
Here's a better capture from another ZRTP call that quickly dropped/crashed
CSip with the relevant info from right before the crash.
Notice that PJSIP's log was cutoff in mid logging activity. The relevant
Android log (full debug this time) is here <http://pastebin.com/0C5LpzKX>.
Notice the "D/SIP SRV (1694): Stop sip stack" message. Something is
definitely wrong here.

Also, I had a SDES/SRTP call running with the exact same endpoints and
network last night, with no problems whatsoever for over 15 minutes.
This, to me, seems to strongly indicate there is some bug or integration
issue between PJSIP/CSipSimple and Werner's ZRTP implementation.
I'm pretty certain by now there is a real issue here. I hope others can
test and replicate this. You need to let the ZRTP call run for some time to
observe this behaviour, because it doesn't always crash immediately. Just
yesterday I managed to hold a successful ZRTP call for almost 6 minutes
before it inevitably crashed.


22:12:24.114 zrtp_android.c !ZRTP warning message: Dropping packet because
SRTP replay check failed!
22:12:24.683 zrtp_android.c  ZRTP warning message: Dropping packet because
SRTP replay check failed!
22:12:25.144 zrtp_android.c !ZRTP warning message: Dropping packet because
SRTP replay check failed!
22:12:27.844 zrtp_android.c !ZRTP warning message: Dropping packet because
SRTP replay check failed!
22:12:28.876   ec0x738859f0 !Underflow, buf_cnt=197, will generate 1 frame
22:12:35.045 zrtp_android.c !ZRTP warning message: Dropping packet because
SRTP replay check failed!
22


On Fri, Jun 7, 2013 at 9:48 PM, Privus 007 <privus007 at gmail.com> wrote:

> Hi Werner,
>
> I've done some more testing, and the strange behaviour continues. This
> time I tried from a Jitsi client calling to an Android 4.2.2 running on 3G
> Indeed it seems like CSip crashes, although it may just be dropping the
> registration and re-registering. It all happens very fast.
> As you can see, the logging stops suddenly when the call drops/csip
> crashes.
>
> I've uploaded the PJSIP logs here <http://pastebin.com/0xfVN2QN>and also
> the corresponding logcat logs here <http://pastebin.com/WRzrF1sg>.
> Earlier today (not in the logs I'm posting) I managed to have a 6 minute
> conversation before the inevitable happened (and the logs do show the SRTP
> replay error messages). But usually the conversation never even reaches 1
> minute.
>
> I hope you can make some sense of this.
>
> Thanks
>
>
> On Fri, Jun 7, 2013 at 6:54 AM, Werner Dittmann <
> Werner.Dittmann at t-online.de> wrote:
>
>> Hmmm - this looks suspicious :-) . An automatic re-registration could mean
>> that CSipSimple automatically restarts. I know of another VoIP client that
>> performs an auto-restart in case it crashes. Such a restart happens quite
>> fast and is often barely noticeable.
>>
>> I cannot reproduce the problem here, thus can you check/see if CSipSimple
>> just crashes and performs a automatic restart? If this is the case than we
>> can try to get the Android logfies from the devices and analyse them.
>>
>> Werner
>>
>> Am 06.06.2013 19:43, schrieb Privus 007:
>> > *The available log does not show the "call drop", the log suddenly
>> stops in
>> > the midst
>> > of another warning message. Any info about this? What does it mean
>> "drops
>> > the connection?"
>> > RTP/SRTP does not have a connection per se, it's UDP thus CS cannot
>> "drop
>> > it".
>> > Does it drop the SIP connection (you use TLS and this CS must hold a TCP
>> > connection)? A re-registration is only necessary if either the register
>> > timer triggers or if the SIP TLS(TCP) connection is lost.
>> >
>> > *
>> > Correct, I use TLS (TCP) for the SIP signalling and RTP/SRTP for the
>> media.
>> > What I mean by the "connection drops" is that the call suddenly ends in
>> mid
>> > call and I then see CSip immediately re-registering on the server.
>> > Since I don't see any TLS errors in the logs, and only the SRTP replay
>> > error, I think the issue lies with ZRTP. Plus, as I said, SDES SRTP
>> calls
>> > (also using TLS) never suddenly "drop" nor does CSip suddenly
>> re-register,
>> > which I think tends to rule out TLS as the problem.
>> > Still, I'm going to make a few more calls with the fullOpenSSL build and
>> > I'll upload the logs to pastebin.*
>> > *
>> >
>> >
>> > On Thu, Jun 6, 2013 at 4:33 PM, Werner Dittmann <
>> Werner.Dittmann at t-online.de
>> >> wrote:
>> >
>> >> Am 06.06.2013 16:46, schrieb Privus 007:
>> >>> *So some questions:
>> >>> - is the audio completely disturbed during the call? Or what's the
>>
>> <SNIP ---- SNAP>
>>
>> --
>> ----------------------------------------------
>> Werner Dittmann    Werner.Dittmann at t-online.de
>> Tel +49 173 44 37 659
>> PGP key: 82EF5E8B
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20130608/873ae340/attachment-0001.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux