[streaming] Possible bugs in live555?
tomas at tuxteam.de
tomas at tuxteam.de
Mon Mar 22 18:19:01 CET 2010
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello, videolan gurus
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)
iD8DBQFLp6aFBcgs9XrR2kYRAl14AJ918dtX4By6uOU7YnW8CzwMuaAukgCfTjf2
32geSp2g2TR0Iob6h1h4G9o=
=09Fu
-----END PGP SIGNATURE-----
More information about the streaming
mailing list