[vlc-devel] [streaming] Possible bugs in live555?

tomas at tuxteam.de tomas at tuxteam.de
Mon Mar 22 18:44:03 CET 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello, videolan gurus

[reposting here since it has been suggested that it's more appropriate
than streaming at . Sorry if I annoy someone twice: I owe you a beer]

a while ago[1] I posted here about my plans to do some (database-based)
authentication for the vlc rtsp server.

While I've made some progress (a proof of concept is "working"; if there
is any interest I could share a smallish patch against 1.0.4, about 500
lines), I stumbled over two nags which might be client-side bugs.

Since my knowledge of the code isn't very firm, I'd like to hear some
opinions before taking it to some live555 list.

* snag 1:
  Server sends some explaining text on error, client doesn't expect it

  When the server responds with an error code, it sends a small body of
  XML, with some human-readable[1] explanation of the error. This is
  nice, but in the case of authentication (where the first  "401
  Unauthorized" is just part of the standard dance, things get out of
  control. Here is an annotated snippet extracted from a wireshark dump
  of the conversation (apologies for extra-long lines) ("->" goes from
  client to server, "<-" from server to client, both are vlc-1.0.4,
  well, more or less):

   | (0)
   | -> OPTIONS rtsp://127.0.0.1:5554/channel0 RTSP/1.0
   | -> CSeq: 10
   | -> User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10)
   | (1)
   | <- RTSP/1.0 200 OK
   | <- Server: vlc 1.0.4
   | <- Content-Length: 0
   | <- Cseq: 10
   | <- Public: DESCRIBE,SETUP,TEARDOWN,PLAY,PAUSE,GET_PARAMETER
   | (2)
   | -> DESCRIBE rtsp://127.0.0.1:5554/channel0 RTSP/1.0
   | -> CSeq: 11
   | -> Accept: application/sdp
   | -> User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10)
   | (3)
   | <- RTSP/1.0 401 Unauthorized
   | <- WWW-Authenticate: Basic realm="VLC stream"
   | <- Content-Length: 326
   | <- Content-Type: text/html
   | (4)
   | -> DESCRIBE rtsp://127.0.0.1:5554/channel0 RTSP/1.0
   | -> CSeq: 12
   | -> Accept: application/sdp
   | -> Authorization: Basic Zm9vOmJhcg==
   | -> User-Agent: VLC media player (LIVE555 Streaming Media v2010.02.10)
   | (5)
   | <- <?xml version="1.0" encoding="ascii" ?>
   | <- <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml10/DTD/xhtml10strict.dtd">
   | <- <html lang="en">
   | <- <head>
   | <- <title>Unauthorized</title>
   | <- </head>
   | <- <body>
   | <- <h1>401 Unauthorized (/channel0)</h1>
   | <- <hr />
   | <- <a href="http://www.videolan.org">VideoLAN</a>
   | <- </body>
   | <- </html>
   | <- RTSP/1.0 200 OK
   | <- Content-type: application/sdp
   | <- Server: VLC Server
   | <- Content-Length: 107
   | <- CSeq: 12
   | <- Cache-Control: no-cache
   | <- 
   | <- v=0
   | <- o=- 12508155347 1 IN IP4 127.0.0.1
   | <- c=IN IP4 0.0.0.0
   | <- t=0 0
   | <- a=tool:vlc 1.0.4
   | <- a=range:npt=0-356.342

   At point (3) above it seems the client thinks it's seen enough (in
   spite of the "Content-Length: 326"). It correctly sends an
   "Authorization" cookie, but the next round (5) it is confronted with
   very strange HTTP headers: no wonder, it's the XML leftovers from
   last session. The error message from the client suggests that much:

   | Failed to get a SDP description from URL "rtsp://foo:bar@127.0.0.1:5554/channel0": no response code in line: "<?xml version="1.0" encoding="ascii" ?>"

   In my opinion the client is at fault: it should gobble
   <content-length> bytes of stuff and then do anything meaningful with
   them (throwing them away, for example ;-)

   For now, since I was deep in the server code, I "fixed" the problem
   by preventing the server from sending this "verbose" error message.
   One might argue that there be a use for an option controlling that,
   since there might be quite a few broken clients out there.

   Opinions?

* snag 2:
  Rtp gets the host part of the URL including the "user:password@"

  The standard way to tell the client to use authentication on rtsp is
  to embed the credentials in the URL, like so:

    rtsp://user:password@host.domain:port/path

  Authentication goes through (as described above) and then (watch the
  client logs):

   | [0x8ce5c78] live555 demux debug: setup start: 0.000000 stop:356.342000
   | [0x8ce5c78] live555 demux error: Nothing to play for rtsp://foo:bar@127.0.0.1:5554/channel0
   | [0x8ce5c78] main demux warning: no access_demux module matching "rtsp" could be loaded
   | [0x8ce5c78] main demux debug: TIMER module_need() : 144.071 ms - Total 144.071 ms / 1 intvls (Avg 144.071 ms)
   | [0x8ce9210] main input debug: creating access 'rtsp' path='foo:bar at 127.0.0.1:5554/channel0'
   | [0x8d68288] main access debug: looking for access module: 1 candidate
   | [0x8d68288] main access debug: net: connecting to foo port 0 : [0x8d68288] main access error: cannot resolve foo port 0 : Name or service not known

   Whoopie! it is trying to do host `foo' (that is the thing before the
   colon, heh) and port 0 (I'd guess that's atoi("bar at 127.0.0.1:5554")
   or something like that :-)

   Snipping of the part before the @ in src/input/access.c like so:

   | /*****************************************************************************
   |  * access_New:
   |  *****************************************************************************/
   | access_t *__access_New( vlc_object_t *p_obj, const char *psz_access,
   |                         const char *psz_demux, const char *psz_path )
   | {
   |     access_t *p_access = vlc_custom_create( p_obj, sizeof (*p_access),
   |                                             VLC_OBJECT_GENERIC, "access" );
   |     char *p;
   | 
   |     if( p_access == NULL )
   |         return NULL;
   | 
   |     /* FIXME: this is a monkey-patch. Try to cope with foo:bar at host.org:5554 */
   |     if( (p = strchr(psz_path, '@')) != NULL ) psz_path = p+1;
   | 
   |     /* */
   |     msg_Dbg( p_obj, "creating access '%s' path='%s'",
   |              psz_access, psz_path );
   ...
   | }

   does "fix" the problem. It's a very ugly fix -- at some other point
   of the program the credential parts are separated from the host part.
   A "real" fix should rather hook into there, right?

   I'm still trying to find a workaround which would work server-side,
   for the same reasons as above: the clients "out there" Just Do It
   This Way (maybe the server can pass on some other URL for the rtp
   stream? Will have to try).

OK. Sorry for having strained your patience with this overly long post!

[1] <http://mailman.videolan.org/pipermail/streaming/2010-February/004539.html>

Regards
- -- tomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFLp6xiBcgs9XrR2kYRAsbKAJ0ajkT96e5zHi6qqN+enldLBZGFCACfUskj
UhMF27+evSlb9yr7P10FrAE=
=ZZOn
-----END PGP SIGNATURE-----



More information about the vlc-devel mailing list