[rtmpdump] [PATCH] Publisher authentication

[Howard Chu]

Steve McFarlin wrote:
>
> On Feb 2, 2011, at 12:03 PM, Steve McFarlin wrote:
>
>> The attached adobe auth patch has an infinite recursion in it. I believe it is the one from Sergiy.
>>
>> Stack Trace:
>> ..
>> ...
>> #743	0x0047a818 in RTMP_ConnectStream at rtmp.c:1047
>> #744	0x0047c2c6 in HandleInvoke at rtmp.c:2765
>> #745	0x0047ae92 in RTMP_ClientPacket at rtmp.c:1248
>> #746	0x0047a818 in RTMP_ConnectStream at rtmp.c:1047
>> #747	0x0047c2c6 in HandleInvoke at rtmp.c:2765
>> #748	0x0047ae92 in RTMP_ClientPacket at rtmp.c:1248
>> #749	0x0047a818 in RTMP_ConnectStream at rtmp.c:1047
>> #750	0x0047c2c6 in HandleInvoke at rtmp.c:2765
>> #751	0x0047ae92 in RTMP_ClientPacket at rtmp.c:1248
>> #752	0x0047a818 in RTMP_ConnectStream at rtmp.c:1047
>>
>> The above file offsets may be different then a auto patched librtmp. I had to manually patch.
>>
>> This occurs when connecting to a Wowza Media Server using an invalid application for publishing. The server rejects the connection and then the following block in HandleInvoke initiates the infinite recursion. Specifically the call to RTMP_ConnectStream. I have not had a chance to fix this. If I patch the patch I will post it.
>>
>> else if (AVMATCH(&method,&av_close))
>>      {
>>         RTMP_Log(RTMP_LOGERROR, "rtmp server requested close");
>>         RTMP_Close(r);
>> #ifdef CRYPTO
>>         if ((r->Link.protocol&  RTMP_FEATURE_WRITE)&&
>>             !(r->Link.pFlags&  RTMP_PUB_CLEAN)&&
>>             (  !(r->Link.pFlags&  RTMP_PUB_NAME) ||
>>              !(r->Link.pFlags&  RTMP_PUB_RESP) ||
>>              (r->Link.pFlags&  RTMP_PUB_CLATE) ) )
>>          {
>>             /* clean later */
>>             if(r->Link.pFlags&  RTMP_PUB_CLATE)
>>                 r->Link.pFlags |= RTMP_PUB_CLEAN;
>>             RTMP_Log(RTMP_LOGERROR, "authenticating publisher");
>>
>>             if (!RTMP_Connect(r, NULL) || !RTMP_ConnectStream(r, 0))
>>                 goto leave;
>>          }
>> #endif
>>      }
>>
>
> The quick and easy fix without understanding the implications is to just 'goto leave;' after the RTMP_Close(r) call. You could optionally remove the CRYPTO code all together. The issue is RTMP_Connect will return true as long as a connection can be made. And as mentioned above RTMP_ConnectStream will end up calling back into HandleInvoke.
>
> Again, I did not mentally trace this code. I don't know the implications of my suggestion. All I know is that it works in the few tests I preformed.

This piece of your patch was almost certainly applied wrong. There's no way 
you should be trying to connect after receiving a close request.