# RTSP conntrack problem

## gentoome

Hi All,

I have a rtsp device (a freebox, which is the modem of a French ISP), which is outside my local network. After doing some googling, I discovered that the transaction between my computer and the device can be summarized as follows :

1) The computer behind the firewall requests an rtsp flux using port 80, which is OK, since it's, of course open,

2) The device responds on a pair of random ports, which is not OK, since it's blocked by the firewall.

I figured I'd need something like conntrack to have the firewall recognize the response as related to the request and open the ports accordingly.

After some more googling I found the following information :

1) A patch exists for kernel 2.4, but is not maintained anymore,

2) Kernel 2.6, as I understand it has support for rtps connection tracking.

The thing is, I cannot find rtsp connetrack anywhere in the netfilter configuration options of my kernel 2.6.15, nor in kernel 2.6.17

Did I miss something ? Is there a patch for kernel 2.6 as well ?

Thanks in advance,

Jonathan

----------

## Lloeki

I'm french, and have a freebox (v5). I bet you would have a better chance in the french section of the forum.

 *Quote:*   

> 2) The device responds on a pair of random ports, which is not OK, since it's blocked by the firewall. 

 

I suspect you want to use the 'multiposte' feature, not the freeplayer (which I never managed to make work, and I don't care with the new PVR+ftp feature of the v5).

if you use vlc-0.8.5 (or 0.8.4 with a patch), you can choose the client port, from which is calculated a second port (odd-even rule), so in fact, no need for conntracking, just open both ports. even then, it's udp, and you could open udp ports 10000-65535 without major security risks. after all you're behind the box, which has a firewall (in router mode at least).

and just for information, the box is not really outside. vlc will connect to the freebox, which acts as a relay for the stream. ping mafreebox.freebox.fr (or hd1.freebox.fr/hd2.freebox.fr) will show you an external ip, but it's just a trick, the round trip time is clearly in ranges of a LAN one, so it's contacting the freebox directly.

I have other problems myself with rtsp, and the livedotcom protocol, and maybe codecs. I'm currently gathering information about it.

 it spits me out either one of (from memory)

- not enough bandwitdh (which is a blatant lie, I have room for at least 4 streams on both the dsl line and wifi)

- something along the lines of no demuxer/no codec for this stream (which is just too weird because it used to work)

- another one I can't remember now

I prevouisly had problems because I have a dd-wrt wrt54g-v5 as a router+ap behind the freebox (itself in router mode, for the hd box), but it seems fixed as of now, as even directly connected to the freebox it spits me the same messages out.

back to info gathering.

----------

## gentoome

Thank you for your answer;

I am at work, so I cannot try anything right now.

However, we might have something here.

First, I do not want to use VLC, as I am trying to setup a MythTV box, which uses mplayer to view digital medias. I should add right now that mplayer has an option to specify the rtsp-port. However, I have not yet found how to embed this option into MythTv.

Second, I do not wish to use the Freebox as a router, since I would forward all the ports to my router/firewall. About this, something strikes me in what you said : as I understand it, you had to setup the freebox as a router for the HD box. I don't see the necessity here sicne I use my HD box w/o having the freebox setup as a router (the HD box is connected to the yellow port and my router/firewall is connected to one of the switch ports). Did I miss something ? 

I agree with you : the response time of the freebox is way to high for it to be outside my network. What I do not understand is how it can forward its external IP address to my router/firewall (when I ifconfig eth0 on the firewall, it shows my external IP address) and still retain a local IP address.

If the freebox does so, it would explain why conntrack does not work : the connection would be established with a 212.x address and the answer would come from a 192.x address.

I will run ethereal tonight in order to sort this out. I will keep you posted.

As for the messages you get : The second message is familiar : mplayer  says the same thing when my firewall blocks one of the rtsp streams. I am investigating it. I'll keep you posted as well.

Thanks for your answer again,

John

----------

## Lloeki

 *Quote:*   

> I don't see the necessity here sicne I use my HD box w/o having the freebox setup as a router (the HD box is connected to the yellow port and my router/firewall is connected to one of the switch ports). Did I miss something ? 

 

interesting, I tried the same, but it failed: only the first connected device (router or HD) would receive data. I only tried it in the first revs, so it may have changed now, thanks to some update. I'll retry now, mimicing your setup.

sometimes, there seems to be some nasty tricks in use in the routing tables of the freebox, certain configurations cause suspicious and unexpected results... if only we had some map of its routing internals... now awaiting your ethereal results (sh*tty eth0, I can't go in monitor mode).

offtopic: what do you think about the new pvr? ftp access is just plain easy and excellent. I feared another freeplayer failure, but we escaped from it! oh, and did you notice that the freebox HD has a Hard Drive? was that pun intended?

----------

## gentoome

Hello,

I ran wireshark yesterday, in the following conditions :

 The Freebox was not in router mode, 212.x

 The test computer (grosbill) was behind a firewall, its address was 192.168.x

 The firewall (paranoia), was configured as such :

 All outbound connections were allowed

 All inbound connections were denied except on ports 10000 to 65534

 Ports 10000 to 65534 were forwarded to the test computer I used mplayer with the following command mplayer rtsp://mafreebox.freebox.fr/freeboxtv/201

mplayer managed to read the stream. The negotiation took place as follows :

Grosbill makes a DNS request to paranoia to determine the IP address of the freebox

Paranoia answers that it's 212.27.x (Remark : I checked the RFC 3330, this address has no special meaning, it is routable, it is not private. Just a standard IP address)

Grosbill contacts the Freebox through port 49055 with destination port 554, the rtsp port and asks it to setup the stream.

The Freebox answers saying ports, for this session, will be 39790 and 39791

Mplayer tunes in, and starts playing the stream

This means two things :

 First, DNAT is actually needed. I tried simply opening the ports on paranoia, instead of forwarding them. Mplayer receives nothing. And wireshark shows that the first part of the negociation gets done, but the stream does not get to grosbill.

The freebox actually has its own little network, even when not in router mode, constituted of 212.x addresses. (I pinged hd1.freebox.fr, and it answered with a 212.27.x address too, but different from that of mafreebox.freebox.fr). Plus, when not in router mode, it forwards its would-be external IP address to any computer connected to the switch ports.

Do you agree with my interpretation of the results ?

The thing is, with the Freebox acting both as a bridge to the internet and its own little network, I do not see how I can tell paranoia to include consider the 212.27.x network as local, so as not to have to DNAT the ports to a particular computer (In effect, DNATing those ports to one of the computers in my network prevents any aother computer to access the streams).

BTW: I activated the harddrive of the freebox HD yesterday, and you were right, it rocks ! I do not think I'll be needing my MythTV box after all... Now I have a useless computer sitting in the appartment !

As for what you said, I was not able to reproduce the experiment to get one of the messages you get. I thnik maybe it has to do with the fact that you have to private netwroks on top of each other. Could you send more details ? (this is of you need any help on this, of course ;-) )

John.

----------

## Lloeki

I agree with your analysis.

I tried non-router mode and it worked. both my router and the hd box receive data. there must have been an upgrade.

I then, on the router, forwarded ports 10000-65534 to my computer (and zapped off my firewall on it, just to be sure). I can now receive the stream with vlc.

Sadly, I can't receive more than one stream, incl. the one used by the hd box. "Not Enough Bandwidth". I can watch the same though. damn, I have 8Mbits, and a stream is maximum 600kbits (mean 300).... so something's wrong. all the more wrong that it worked some time ago (when I didn't have the router).

The root of needing port forwarding is that in rtsp, once the request of the stream is sent to the server, client and server 'switch roles', much like in ftp file transfers. thus the need to forward a port, as the client is now a server with a socket waiting. ftp works around this with PASV mode.

the solution might be twofold:

- ability to specify client port (the port it listens to like a server), one different on each computer

- forward each port to each computer

another one would be to use port triggering.

----------

## Lloeki

I selected port 30000 as a client port in ~/.vlc/vlcrc (for some reason, modiifying it through the gui didn't work)

```
[livedotcom]

rtp-client-port=30000
```

rstp uses two udp ports, so now, forwarding ports 30000 & 30001 UDP to my computer make things work without the Big Forward.

the bandwidth issue remains.

----------

## animemint

There is a patch for RTSP conntrack. I used to apply it on my gentoo-sources without problem. Last kernel I tried was 2.6.16 , but I suppose it might work on later ones. Otherwise check recent patch-o-matic, I read there was an update.

This is useful because you won't have to forward ports anymore. Then you will be able to watch/record TV channels as far as your bandwitdh will allow or watch different channels on different PCs.

----------

## Lloeki

Good to know. I wonder why it's not included mainstream.

My b/w issue has been resolved once I switched to adsl2+ 'potato' (PATATE, no max noise cap, few lowlevel error corrections, if any) mode, which surprisingly works far better than adsl2+ stantard mode (lots of video freezes), and has more throughput than adsl1 mode (but was playing video nicely). best of both worlds.

I still have to tackle a few issues, but they're most probably slight configuration mishaps.

----------

## ultraViolet

 *gentoome wrote:*   

> 
> 
> The thing is, with the Freebox acting both as a bridge to the internet and its own little network, I do not see how I can tell paranoia to include consider the 212.27.x network as local, so as not to have to DNAT the ports to a particular computer (In effect, DNATing those ports to one of the computers in my network prevents any aother computer to access the streams).
> 
> 

 

Hi,

What about trying using 212.27.x addresses for your local network ? They could be included on the freebox subnetwork and adressed directly ?

Or perhaps with the 802.1d Ethernet Bridging kernel module ? a vlan ?

----------

## ultraViolet

Here is a post in french which explain a way to way to share the television between users :

http://forum.macadsl.com/viewtopic.php?t=21424&f=9

The principle is to set vlc to use a specific port for rtsp communication between the freebox and the vlc client.

Then you can use iptable to dnat.

example :

iptables -t nat -A prerouting -p udp --dport {port} -j DNAT --to-destination {ip of the client using vlc}:{port} 

then you have to change the parameter in vlc :

settings>codecs>demuxers>rtsp and you put the port used in iptables. It is possible you have to dnat the next port too.

then you can use the "multiposte" feature (even if each of your computers behind the routeur has to get vlc configured)

----------

