[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