Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Wowza nDVR and 3.6.2 patch 10

  1. #1

    Default Wowza nDVR and 3.6.2 patch 10

    Hi,

    We've started evaluating Wowza 3.6.2 patch 10 with our setup and have run into an issue that wasn't present in 3.5.2 patch 8. We use multi-level feed paths separated by slashes for our live feeds (for example, /foo/bar/blah). In the case of nDVR, the chunks are stored in a directory with the slashes replaced with underscores. (foo_bar_blah.0). To get around this issue, we were using tildes in place of slashes as a separator. So /foo/bar/blah became /foo~bar~blah. Our customer would still request the feed /far/bar/blah, but we would translate the feed path internally between the live repeater origin and live repeater edge by replacing the underscores with tildes. This worked great up until we upgraded to 3.6.2 patch 10.

    Now we see this:

    2013-09-10 18:40:34 WARN server comment - VHost.validateHTTPStreamerRequest: HTTP streamer request is not valid. Contains ".." or "~"
    Any reason why tildes are no longer valid? This obviously breaks our nDVR setup and prevents us from upgrading to 3.6.2.

    Thanks

  2. #2

    Default

    Hi,

    The .. and ~ are security risks. ../ means the parent directory and ~ means the users home directory.

    Roger.

  3. #3
    Join Date
    Sep 2011
    Posts
    12

    Default

    Neat!

    Roger,

    Do you have a list of characters that are valid? Perhaps there's a way to turn this off to allow us to move forward with our current implementation? I can certainly see where any string preceded by a ~ could be interpreted as the home dir by the shell but in this particular scenario the value presented starts with "/" rather than "~". Plus it's an internal translation, so it's probably unlikely that an exploit would be able to push through internally.

    <...finds chunk of wood to knock on quickly> ;

    Michael

  4. #4
    Join Date
    Sep 2011
    Posts
    12

    Default

    Roger et al.,

    Hi! Can we get some input on my last inquiry about a list of valid characters please?

    Vijay has so far tried '@', '.', '^', ':', '|' and '#' without success.

    3.6.2.10 live repeater origin when using tildes:
    2013-09-10 18:40:34 WARN server comment - VHost.validateHTTPStreamerRequest: HTTP streamer request is not valid. Contains ".." or "~"

    3.6.2.10 live repeater edge when using carets:
    java.net.URISyntaxException: Illegal character in path at index 76: rtmp://server/application/_definst_/multilevel^customer^feedpath

    3.6.2.10 live repeater edge when using @:
    2013-09-11 16:04:22 WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/9579 url:server/application/multilevel@customer@feedpath.0/ChunkTypes(8)/ChunkIndexes(64).dvr

    3.6.2.10 live repeater origin when using ':':
    strips out first string and replaces : with _

    3.6.2.10 live repeater edge when using #:
    java.net.URISyntaxException: Illegal character in fragment at index 84: rtmp://server/application/_definst_/multilevel#customer#feedpath

    3.6.2.10 live repeater edge when using .:
    2013-09-11 16:25:50 WARN server comment - .getDvrSanJoseFragments: null audio chunk chunkIndex=40
    2013-09-11 16:25:50 WARN server comment - HTTPStreamerAdapterSanJoseStreamer.onMediaFile: Chunk:40 not found [application/_definst_/multilevel/customer/feedpath/DVR_b125000_w934184396_qRFZS.abst/Seg1-Frag41]: multilevel.customer.feedpath.

  5. #5

    Default

    bump

  6. #6

    Default

    Hi,

    Sorry I missed this before.

    I will pass it onto our engineering dept to see if anything can be done.

    Roger.

  7. #7

    Default

    Hi,

    What about if you urlEncode or base64Encode the stream path?
    multilevel/customer/feedpath => multilevel%2Fcustomer%2Ffeedpath
    or
    multilevel/customer/feedpath => bXVsdGlsZXZlbC9jdXN0b21lci9mZWVkcGF0aA==
    Both should work. urlEncode would be easier to understand but may get decoded internally. I couldn't be 100% certain as I do not know your full use case.

    Roger.

  8. #8

    Default

    As you suspected, urlEncode does get decoded internally so that's not going to work.

    INFO server comment - HTTPStreamerAdapterSanJoseStreamer.service: dvr-edge/_definst_foo%2Fbar%2Fblah/manifest.f4m?DVR
    DEBUG server comment - MediaStreamMediaCasterUtils.mapMediaCasterName: streamName:foo/bar/blah originURL:rtmp://xxx.xxx.com:1935/dvr-origin/ result:rtmp://xxx.xxx.com:1935/dvr-origin/_definst_/foo/bar/blah
    WARN server comment - HTTPStreamerAdapterSanJoseStreamer.service: Request timeout: 8000
    base64encoding makes the feed path unreadable, so I don't see us using that approach.

    So the reason we had to go with a separator (tilde in our case) in place of a slash is because the edge fails to play a dvr feed from the origin when the feed contains slashes. I'm guessing this is because the dvr store directory for the feed on the origin is stored as foo_bar_blah.0 for the feed /foo/bar/blah.

    If the edge can be fixed so it knows how to read the dvr store directory from the origin for feeds containing slashes, we should be good to go. We wouldn't need to replace slash with tilde, or any other character.

  9. #9

    Default

    Hi,

    I have spoken to the engineering team and there is an interface that you can implement that will replace the default validation code. The default implementation checks for .., ~ and \u0000 after doing a urlDecode on the path.

    You can implement your own validation routine using the IVHostHTTPStreamerRequestValidator interface. it has a single method,
    public boolean validateHTTPStreamerRequest(RtmpRequestMessage request, HostPort hostPort, String path);
    which will be called for every http request. If the request path is valid, true is returned.

    To enable the validator, you need to attach it to the vhost using
    IVHost.setHTTPStreamerRequestValidator(IVHostHTTPStreamerRequestValidator httpRequestValidator);
    You should do this as early as possible, before any connections are made. The best place is in a VHostListener in onVHostInit.

    The .. string and it's url encoded form is checked in other places on the server so even if you remove it from your validator, it will still get caught in other places.

    There is also a similar validator interface for rtsp urls called IVHostRTSPRequestValidator.

    I hope this helps.

    Roger.

  10. #10

    Default

    Thanks Roger! That worked as advertised. However, I noticed something else with DVR that's unrelated to this issue. When using 3.6.2 patch 10 (both the live repeater origin and edge) the MediaCache AddOn on the edge spits out tons of read failures. This is what I see on the edge when requesting a feed 'dvrtest' from the live repeater origin:
    INFO sanjose connect 508868022 -
    INFO stream create rtmp://xxx.xxx.com:1935/wowza-origin-dvr/_definst_/dvrtest -
    WARN server comment - MediaCacheHTTPByteReader.sendRequest[http://xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(120).dvr]: Invalid HTTP byte range request Content-Length: 61194 > 30597
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/30597 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(120).dvr
    WARN server comment - DvrStreamStoreBase.retrieveChunkFromMediaCache[cdn-live-dvr-l2lab1/_definst_/dvrtest/dvrtest.0] : Unable to get DVR chunks from any of the origin urls:
    WARN server comment - DvrStreamStoreBase.retrieveChunkFromMediaCache[cdn-live-dvr-l2lab1/_definst_/dvrtest/dvrtest.0] :   url: http://xxx.xxx.com:1935/wowza-origin-dvr/_definst_/dvrtest.0
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/7484 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(120).dvr
    INFO stream play rtmp://xxx.xxx.com:1935/wowza-origin-dvr/_definst_/dvrtest -
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/34920 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(121).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/6778 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(121).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/34441 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(122).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/6996 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(122).dvr
    WARN server comment - MediaCacheHTTPByteReader.sendRequest[http://xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(123).dvr]: Invalid HTTP byte range request Content-Length: 65350 > 32675
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/32675 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(123).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/6825 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(123).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/34432 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(124).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/7724 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(124).dvr
    ERROR server comment - MediaCacheHTTPByteReader.sendRequest[http://xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(125).dvr]: java.net.SocketTimeoutException: Read timed out
    WARN server comment - MediaCacheHTTPByteReader.sendRequest[http://xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(125).dvr]: Invalid HTTP byte range request Content-Length: 94120 > 47060
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/47060 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(125).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/6766 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(125).dvr
    WARN server comment - MediaCacheHTTPByteReader.sendRequest[http://xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(126).dvr]: Invalid HTTP byte range request Content-Length: 127892 > 63946
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/63946 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(126).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/10467 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(126).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/37196 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(127).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/6322 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(127).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/20396 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(9)/ChunkIndexes(128).dvr
    WARN server comment - MediaCacheItemHTTPImpl.read[dvrorigin]: Read failure: req:0/7610 url:xxx.xxx.com:1935/wowza-origin-dvr/dvrtest.0/ChunkTypes(8)/ChunkIndexes(128).dvr
    The dvr feed itself plays fine but I'm guessing the MediaCache is not really caching the chunks. Has there been an update to the addon that fixes this issue? We're running Wowza MediaCache AddOn 2.0.0 build2654. (EDIT: Tried running Wowza MediaCache AddOn 2.0.0 build5900 but we're still seeing the error). We didn't see this problem with 3.5.2 patch 8.
    Last edited by vjagannathan; 09-19-2013 at 06:36 PM. Reason: Additional info

Page 1 of 2 12 LastLast

Similar Threads

  1. How to apply wowza patch (LINUX) EASY!
    By capostrike93 in forum Tutorials Discussion
    Replies: 2
    Last Post: 10-16-2011, 02:31 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •