[rtmpdump] What to look for to solve a "handshake failed"?
rtmpdump at pepak.net
rtmpdump at pepak.net
Sun Dec 18 08:01:47 CET 2011
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
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
> 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:
> -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"
> -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 :
> DEBUG: pageUrl :
> 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:
> (the interesting packets, at least interesting to my eyes, are 1062
> and 1078)
> Thanks for any tips as to where to look.
> rtmpdump mailing list
> rtmpdump at mplayerhq.hu
More information about the rtmpdump