mainflvstreamer - Support: sr #106939, Ping type 31 not handled

 
 

sr #106939: Ping type 31 not handled

Submitter:  None
Submitted:  Sun 19 Jul 2009 10:42:55 PM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Need Info
Privacy:  Public Assigned to:  fsck
Originator Email:  -email is unavailable- Open/Closed:  Open
Operating System:  Mac OS
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 22 Nov 2009 12:03:43 PM UTC, comment #27: 

Try new v1.9. This may well fix this problem.

fsck <fsck>
Group administrator
Sun 04 Oct 2009 12:34:27 PM UTC, comment #26: 

I cannot see any differences in how ping type 31 might be handled by both sources. The only difference is handling SWFverification requests but they use ping type 26 and respond with a ping type 28. In your rtmpdump text can you see 'SWFVerification ping received' or type 26/27 (1A/1B) ping anywhere in the debug output?

fsck <fsck>
Group administrator
Sun 04 Oct 2009 06:46:57 AM UTC, comment #25: 

On a side note, rtmpdump handles these streams properly. Maybe a look at it's source could reveal the answer :)

Anonymous
Mon 31 Aug 2009 11:28:16 PM UTC, comment #24: 

capture2.log was taken from the proper iView flash player - I have no idea if there is a ping type 31 in that file - although flvstreamer only seems to die on longer streaming files - like The Bill - hence me using it to test.

$ host cp53909.edgefcs.net
cp53909.edgefcs.net is an alias for a139.v539099.c53909.mm.vi5.akamaistream.net.
a139.v539099.c53909.mm.vi5.akamaistream.net is an alias for a139.ui5g0.akafms.net.
a139.ui5g0.akafms.net has address 203.206.129.37

Maybe it is GeoIP'ed - I wonder if it works via IP address?

I know I can use the token generated on a different IP - but not sure how it actually works.

I'll tinker around some more and see if I can get a proper dump of The Bill - but like I said - it's about 2 hours to take the dump properly due to caching inside the flash player meaning the entire clip doesn't load in one hit.

--
CRC

Anonymous
Mon 31 Aug 2009 10:02:26 AM UTC, comment #23: 

Hi CRC, I got that capture2.log and it looks intact. Is that from flash or flvstreamer? Also does the ping type 31 occur in that trace?

I tried your token generator but I get 'Your ISP does not offer iView unmetered' and then when I use the token I get an RTMP 'Access Denied' - so maybe akamai use GeoIP or hash the token with the IP.

fsck <fsck>
Group administrator
Mon 31 Aug 2009 05:22:32 AM UTC, comment #22: 

Any news on this as yet?

--
CRC

Anonymous
Wed 26 Aug 2009 02:54:46 PM UTC, comment #21: 

I don't know if this will work, but try getting the following:

Get a token from:
http://www.crc.id.au/downloads/auth.pl

Then try the command:
./flvstreamer-1.8j_fedora-x86-32bit -x -r rtmp://cp53909.edgefcs.net////flash/playback/_definst_/catch_up/thebill_09_24_2309-10 -t "rtmp://cp53909.edgefcs.net/ondemand?auth=$token" -o "thebill_09_24_2309-10.flv" -m 1200

Obviously, replace $token with the token value from the first URL...

I'm not sure if it will let you, but it's worth a try for nothing :)

Anonymous
Wed 26 Aug 2009 01:47:00 PM UTC, comment #20: 

After running into a few issues, I've grabbed a dump of a smaller file to see if that gives you any new info - as the dump I've been trying in the past was always over 400Mb and take ~1.6 hours to capture!

This one is a little smaller at 75Mb and (hopefully) useful - at least to see if we have the entire stream to decode!

http://www.crc.id.au/files/capture2.log

--
CRC

Anonymous
Wed 26 Aug 2009 10:30:25 AM UTC, comment #19: 

I've downlaoded Wireshark onto my mac and I'll have a sticky at what I can find here... Give me another couple of hours and I'll hours and I'll hopefully have something for you...

Running a capture now and we'll see how things go...

--
CRC

Anonymous
Wed 26 Aug 2009 09:23:50 AM UTC, comment #18: 

CRC, they are both missing data however yours is nearer getting it right so far in that there are a few initial rtmp commands in there. maybe the initial rtmp handshake is done before you click play - i.e. maybe it happens just when the flash app is loaded anf then it is paused until you press play? Can you try a capture before the player page is loaded then press play after? To save b/w maybe just do a few seconds capture for now.

fsck <fsck>
Group administrator
Wed 26 Aug 2009 12:12:43 AM UTC, comment #17: 

Out of interest, does my dump show the same issues as the Fremans?

--
CRC

Anonymous
Tue 25 Aug 2009 04:12:58 PM UTC, comment #16: 

I've downloaded that file but it still seems to be somewhat invalid - there is no initial rtmp handshake in it and wireshark therefore cannot decode it... Finding an unknown piece of data in that is going to be very difficult without a trace starting from the beginning.

fsck <fsck>
Group administrator
Tue 25 Aug 2009 12:46:08 PM UTC, comment #15: 

Ok - the full capture is now available at:
http://www.crc.id.au/files/capture.log

It should be ok - let me know if it isn't....

Anonymous
Tue 25 Aug 2009 07:55:48 AM UTC, comment #14: 

Ok - give me a few hours and I'll get some dumps done...

--
CRC (just too lazy to setup a login :))

Anonymous
Mon 24 Aug 2009 03:45:05 PM UTC, comment #13: 

Running, as root:

tcpdump -vne -i eth0 -s 1522 -w capture.log tcp port 1935

will write a wireshark compatible dump to 'capture.log' file (assuming eth0 is your ethernet interface as per ifconfig).

fsck <fsck>
Group administrator
Mon 24 Aug 2009 02:29:42 PM UTC, comment #12: 

Can you want to paste the wireshark command line you used? I'll see what I can do and do a capture on my router... I'll have to get an NFS share happening as the router is a linux box using a CF card as a HDD and doesn't have enough space for a packet capture.

Anonymous
Mon 24 Aug 2009 01:06:44 PM UTC, comment #11: 

Yes, I started long before - I think the problem is my connection is currently fried - as soon as I start streaming iView it starts dropping packets - I'll look at getting this data an alternate way.

Shannon Wynter <freman>
Mon 24 Aug 2009 10:55:51 AM UTC, comment #10: 

Those are valid wireshark traces but unfortunately neither of those two traces contain any RTMP handshake so I cannot determine what is going on. Did you start the capture before starting the player?

fsck <fsck>
Group administrator
Sun 23 Aug 2009 01:49:54 PM UTC, comment #9: 

Sorry, hosted on godaddy's "Free" hosting that corrupts file types it doesn't know.

http://media.fremnet.net/capture.zip

Shannon Wynter <freman>
Sun 23 Aug 2009 09:40:23 AM UTC, comment #8: 

Hi, the link you sent appears to be an empty rar file.

fsck <fsck>
Group administrator
Fri 21 Aug 2009 04:04:46 PM UTC, comment #7: 

You can cut out the data between '|RtmpSampleAccess' and when the ping type 31 request comes, then just cut off the rest after the client response to the ping type 31 has completed if you can find it. Just put it on a upload site somewhere and I'll download it. Worst case just upload the whole file and I'll figure it out.

fsck <fsck>
Group administrator
Fri 21 Aug 2009 03:41:59 PM UTC, comment #6: 

Well, as soon as I can convince iview to play a whole episode of the bill all the way through, I will have a wireshark dump, unfortunately it'll exceed 400mb.

Anonymous
Fri 21 Aug 2009 11:58:34 AM UTC, comment #5: 

Just need the binary dump of the response from the flash client to the server when a ping type 31 is sent to the client. Then I can try to figure out how to implement a handler. A full rtmp trace up until that point would also be useful in case there is any strteam or state-related info in there.

fsck <fsck>
Group administrator
Fri 21 Aug 2009 11:45:11 AM UTC, comment #4: 

Hi there, if you can tell me roughly what to look for in the stream for a ping type 31?

Anonymous
Thu 20 Aug 2009 12:49:40 PM UTC, comment #3: 

I don't have an Australian IP address so I'll have difficulty testing. If someone could upload (or provide a link to) a flashplayer wireshark trace showing the ping type 31 and it's correct response I'll see if I can reproduce this behavior in flvstreamer. I cannot find any documentation on this ping type anywhere (it's probably in the adobe rtmp spec but I'm not prepared to read that).

fsck <fsck>
Group administrator
Wed 19 Aug 2009 01:56:23 PM UTC, comment #2: 

I also see this...

Reference:
http://forums.whirlpool.net.au/forum-replies.cfm?t=1212283&p=33#r660

a ping type of 31 equals a quick death for the download.

I have verified this on 1.8i for linux. 1.8f just stops downloading without displaying that it received a ping of type 31.

Sadly I don't have a URL that I can give you that will work - as this is with the ABCs iView system and limited to Australia only.
  - http://www.abc.net.au/iview

Anonymous
Mon 20 Jul 2009 01:14:46 PM UTC, comment #1: 

Do you have an example command that I can use to reproduce this? Also, is this for PPC or Intel Mac?

fsck <fsck>
Group administrator
Sun 19 Jul 2009 10:42:55 PM UTC, original submission:  

flvstreamer does not seem to handle this kind of ping, so the download stops.

Ctrl-C then enters a never ending "cleaning-up second". Which only can be terminated by another ctrl-c, which again results in the file being corrupt and resume not being possible. not good.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by freman (Posted a comment)
  • -email is unavailable- added by fsck (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-08-23 fsck Originator Email -email is unavailable-
    2009-07-20 fsck StatusNone Need Info
        Assigned toNone fsck

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code