[rtmpdump] What to look for to solve a "handshake failed"?

Sun Dec 18 08:21:39 CET 2011

Hi again,

got it: RTMPSockBuf_Fill doesn't correctly handle server responses if
they are split into multiple packets. E.g. the server I am working on
at the moment sends the HTTP response headers in one packet and
response body in additional packets. But RTMPSockBuf_Fill doesn't wait
for these extra packets - it stops after the first one and of course
fails to find the "connection handle" there (because it is yet to come
in future packets). E.g. I added:

RTMP_Log(RTMP_LOGDEBUG, "%s, received %u bytes",
  __FUNCTION__, r->m_sb.sb_size);
RTMP_LogHexString(RTMP_LOGDEBUG, r->m_sb.sb_start, r->m_sb.sb_size);

into HTTP_Read right after return -2 and got this in my log:

Connecting ...
DEBUG: HTTP_read, received 145 bytes
DEBUG:   0000:  48 54 54 50 2f 31 2e 31  20 32 30 30 20 4f 4b 0d   HTTP/1.1 200 OK.  
DEBUG:   0010:  0a 43 6f 6e 74 65 6e 74  2d 54 79 70 65 3a 20 61   .Content-Type: a  
DEBUG:   0020:  70 70 6c 69 63 61 74 69  6f 6e 2f 78 2d 66 63 73   pplication/x-fcs  
DEBUG:   0030:  0d 0a 43 6f 6e 6e 65 63  74 69 6f 6e 3a 20 4b 65   ..Connection: Ke  
DEBUG:   0040:  65 70 2d 41 6c 69 76 65  0d 0a 53 65 72 76 65 72   ep-Alive..Server  
DEBUG:   0050:  3a 20 46 6c 61 73 68 43  6f 6d 2f 33 2e 35 2e 34   : FlashCom/3.5.4  
DEBUG:   0060:  0d 0a 43 61 63 68 65 2d  43 6f 6e 74 72 6f 6c 3a   ..Cache-Control:  
DEBUG:   0070:  20 6e 6f 2d 63 61 63 68  65 0d 0a 43 6f 6e 74 65    no-cache..Conte  
DEBUG:   0080:  6e 74 2d 4c 65 6e 67 74  68 3a 20 31 30 0d 0a 0d   nt-Length: 10...  
DEBUG:   0090:  0a                                                 .                 
DEBUG: RTMP_Connect1, ... connected, handshaking

I expect after I fix RTMPSockBuf_Fill to wait for all packets in the
stream the connection will work fine. That is, assuming I will be able
to write the fix - C is not exactly my first language...

Pepak

> Hi!

> I have been comparing the handshakes of RTMPDUMP and native player
> side-by-side and noticed several things:

> 1. Some of RTMPDUMP's HTTP headers are ending with \n and not \r\n as
> per HTTP specification. See HTTP_Post(), headers "User-Agent" and
> "Connection".

> 2. For some reason, RTMPDUMP seems to be a bit impatient. The native
> player's sequence is:

> - POST /open/1
> - receive an answer "638525327" - I assume that's a "RTMP connection handle"
> - POST /send/638525327/0
> - receive an answer ...

> On the other hand, RTMPDUMP's sequence is:

> - POST /open/1
> - POST /send//0
> - receive an answer to "open"
> - after two seconds of no answer to "send", POST /close/1

> I will need to look into rtmp.c to see why it doesn't wait for the
> answer and instead immediately sends a new request, but I think this
> might very well account for my handshake failures - the server expects
> a connection handle in "send" and since it doesn't get any, it ignores
> the request.

> Pepak

>> Hi!

>> I am trying to download a stream from a provider which recently
>> switched to a new Flash player (the older version worked just fine
>> with RTMPDUMP). Using WireShark I managed to find all? required
>> parameters, and debugging the player I managed to find the secure
>> token. But I am still getting a "handshake failed". Could it mean an
>> unsupported (I am using the latest GIT version of RTMPDUMP)
>> authentication scheme or is there some other expected reason? And if
>> it *is* an unsupported authentication scheme, does it make sense for
>> me to try to decipher it from the player's code? (The player is
>> apparently a version of JWPlayer, but either stripped to the bones or
>> very old, because the SWF is very short and it seems to contain very
>> few scripts, so I think I stand a good chance of finding the scheme,
>> if it can be done from client-side; the only problem is that I have no
>> idea how to add it to RTMPDUMP even if I find it.)

>> If anyone wants to give it a try, the command-line I am using is:

>> rtmpdump
>>   -z
>>   -v
>>   -r "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video"
>>   -y "mp4:vypravej/history/139.mp4"
>>   -f "WIN 10,3,183,11"
>>   -s "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf"
>>   -W "http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf"
>>   -t "rtmpt://ctv-flv1.content.mediastream.cz/CTv-video"
>>   -p
>> "http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/1975/v-moste-byl-kvuli-dolovani-presunut-dekansky-kostel-nanebevzeti-panny-marie/"
>>   -T "5%qp-xvbt+_oi"
>>   -o "x.mp4"

>> And I get the following result:

>> RTMPDump v2.4
>> (c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL
>> DEBUG: Parsing...
>> DEBUG: Parsed protocol: 1
>> DEBUG: Parsed host    : ctv-flv1.content.mediastream.cz
>> DEBUG: Parsed app     : CTv-video
>> DEBUG: Protocol : RTMPT
>> DEBUG: Hostname : ctv-flv1.content.mediastream.cz
>> DEBUG: Port     : 80
>> DEBUG: Playpath : mp4:vypravej/history/139.mp4
>> DEBUG: tcUrl    : rtmpt://ctv-flv1.content.mediastream.cz/CTv-video
>> DEBUG: swfUrl   :
>> http://img8.ceskatelevize.cz/libraries/JWPlayer/player.swf
>> DEBUG: pageUrl  :
>> http://www.ceskatelevize.cz/porady/10266819072-vypravej/ve-stopach-doby/1975/v-moste-byl-kvuli-dolovani-presunut-dekansky-kostel-nanebevzeti-panny-marie/
>> DEBUG: app      : CTv-video
>> DEBUG: flashVer : WIN 10,3,183,11
>> DEBUG: live     : no
>> DEBUG: timeout  : 30 sec
>> DEBUG: SWFSHA256:
>> DEBUG: 00 b9 3c 04 ba dd 2f 40 05 74 be 1b cb 7f c5 cd
>> DEBUG: 1b ed 8c f9 1c ae 54 be f4 bd 07 a3 48 29 6c f4
>> DEBUG: SWFSize  : 105686
>> DEBUG: Setting buffer time to: 36000000ms
>> Connecting ...
>> DEBUG: RTMP_Connect1, ... connected, handshaking
>> DEBUG: HandShake: Client type: 03
>> DEBUG: HandShake: Client digest offset: 53
>> DEBUG: HandShake: Initial client digest: 
>> DEBUG: 5f 45 64 8c f0 16 f8 a6 23 99 f0 e9 d8 6e 8d 61
>> DEBUG: 10 d7 bf 45 0a 70 60 f1 f3 20 b4 46 de e2 44 e1
>> ERROR: RTMP_Connect1, handshake failed.
>> DEBUG: Closing connection.

>> I am not certain whether this means the handshake failed after the
>> application of the secure token or before it.

>> The packet capture of the webbrowser playing the beginning of the
>> movie is here:
>> http://tmp.pepak.net/ct.zip
>> (the interesting packets, at least interesting to my eyes, are 1062
>> and 1078)

>> Thanks for any tips as to where to look.

>> Pepak

>> _______________________________________________
>> rtmpdump mailing list
>> rtmpdump at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump

> _______________________________________________
> rtmpdump mailing list
> rtmpdump at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump