[Live-devel] RTSP proxy not noticing server restart

Jonathan Brady jonathan.brady+live555 at denbridgemarine.com
Mon Sep 22 08:17:40 PDT 2014


On 22/09/14 15:42, Ross Finlayson wrote:
>> It is possible to restart an origin server quickly enough that a live 
>> 555 proxy server does not notice.
>>
>> As a test this can be done by modifying one of the live 555 test 
>> programs (I was using testH264VideoStreamer) to enable 
>> SO_REUSEADDR/SO_REUSEPORT, then the process could be quickly killed 
>> and restarted without waiting for the socket to timeout. 
>
> And that's precisely why you shouldn't make such a change to the 
> server's code :-)
Its not that I'm making a change to the server code. It was actually a 
third party embedded server that is capable of restarting fast enough 
that the proxy server never notices.  The change to the server code 
suggested is just a quick way of reproducing the problem on the same 
machine.
>
> But anyway, the proxy server sends periodic RTSP "OPTIONS" commands to 
> the 'back-end' server, to test whether its still alive.  If any of 
> these "OPTIONS" commands fails (or if the RTSP (TCP) connection to the 
> back-end server fails), then the proxy server will notice this, and 
> establish a new connection (with a new "DESCRIBE" command) to the 
> back-end server.
>
> You should be able to see this by running the proxy server with the -V 
> (uppercase "V") option.
>
> But (getting back to the first point) if your server is able to 
> restart in such a way that a previously-set-up TCP connection can get 
> misinterpreted as still being valid, then that's a serious security 
> flaw in your server OS; that's the real bug that you should be fixing.
>
I can indeed see this running the proxy server with -V.  It is not the 
case of a TCP connection being misinterpreted as valid. It is the case 
of when the proxy server retries an OPTIONS command, it sees the TCP 
connection has gone away, reconnects and receives a valid response, it 
doesn't realise this is because the server has restarted.  Perhaps 
rather than using OPTIONS something that sends a session id should be 
sent and error responses checked for?

Sending request: PLAY rtsp://127.0.0.1:8554/testStream/ RTSP/1.0
CSeq: 4
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2014.09.11)
Session: 29A64580


Received 186 new bytes of response data.
Received a complete PLAY response:
RTSP/1.0 200 OK
CSeq: 4
Date: Mon, Sep 22 2014 15:07:50 GMT
Range: npt=29.767-
Session: 29A64580
RTP-Info: 
url=rtsp://127.0.0.1:8554/testStream/track1;seq=24127;rtptime=32393928

==================
I restart the origin server here
==================


Opening connection to 127.0.0.1, port 8554...
...remote connection opened
Sending request: OPTIONS rtsp://127.0.0.1:8554/testStream/ RTSP/1.0
CSeq: 6
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2014.09.11)
Session: 29A64580


Received 152 new bytes of response data.
Received a complete OPTIONS response:
RTSP/1.0 200 OK
CSeq: 6
Date: Mon, Sep 22 2014 15:08:47 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, 
SET_PARAMETER

=============
I close my client here
=============

ProxyServerMediaSubsession["H264"]::closeStreamSource()
Sending request: PAUSE rtsp://127.0.0.1:8554/testStream/ RTSP/1.0
CSeq: 7
User-Agent: ProxyRTSPClient (LIVE555 Streaming Media v2014.09.11)
Session: 29A64580


Received 80 new bytes of response data.
Received a complete PAUSE response:
RTSP/1.0 454 Session Not Found
CSeq: 7
Date: Mon, Sep 22 2014 15:08:54 GMT


Regards,
Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20140922/bf48335b/attachment.html>


More information about the live-devel mailing list