Experimental RTSP modules

Experimental RTSP modules

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Please note this is an experimental module.  It works for me.  It may work
for you, it may panic your kernel, or it may just sit there using ram.

Features:

 * Detects STUN and stays out of the way.
 * Understands proposed client_port=M/N syntax.
 * There is a configurable policy for the destination parameter.

TODO:

 * Handle multiple SETUP messages in a single packet.
 * Un-mangle client_port on return trip.
 * IPv6 modules
 * Much more...

This should work with 2.4.20 and all of 2.4.21-pre# series up to and
including pre7, at least.  It should not work with 2.4.19 or prior.  I am
making _no_ attempt to do p-o-m or non-kernel iptables support.  Others may
feel free if they wish (hey, it's GPL).

The diff was prepared against 2.4.21-pre6.  Please use the "-p1" option to
patch(1) for proper application:

        # cd linux-2.4.21-pre7
        # cat ../nf-rtsp.diff | patch -p1

Comments (especially bug reports and success reports) welcome.

Hints about IPv6 conntrack and nat modules very appreciated (why is there no
IRC or FTP modules for IPv6?)

	http://home.tig-grr.com/nf-rtsp.diff

-- 
To use violence is to already be defeated.
        -- Chinese proverb

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Experimental RTSP modules

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]

Please note this is an experimental module.  It works for me.  It may work
for you, it may panic your kernel, or it may just sit there using ram.

Features:

 * Detects STUN and stays out of the way.
 * Understands proposed client_port=M/N syntax.
 * There is a configurable policy for the destination parameter.

TODO:

 * Handle multiple SETUP messages in a single packet.
 * Un-mangle client_port on return trip.
 * IPv6 modules
 * Much more...

This should work with 2.4.20 and all of 2.4.21-pre# series up to and
including pre7, at least.  It should not work with 2.4.19 or prior.  Please
note that I am making _no_ attempt to support p-o-m or iptables versions not
included in the kernel.  Others may do so if they wish (hey, it's GPL).

The diff was prepared against 2.4.21-pre6.  Please use the "-p1" option to
patch(1) for proper application:
                                
        # cd linux-2.4.21-pre7  
        # cat ../nf-rtsp.diff | patch -p1

Comments (especially bug reports and success reports) welcome.

	http://home.tig-grr.com/nf-rtsp.diff

Hints for implementing IPv6 conntrack and nat modules especially appreciated
(why are there no IRC or FTP modules for IPv6?)

-- 
To use violence is to already be defeated.
        -- Chinese proverb

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Experimental RTSP modules

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

On Sat, Apr 05, 2003 at 07:35:32PM -0800, Tom Marshall wrote:
> Please note this is an experimental module.  It works for me.  It may work
> for you, it may panic your kernel, or it may just sit there using ram.

great news. If you could convert it to patch-o-matic format, I'm happy
to include it!

>  * Handle multiple SETUP messages in a single packet.
>  * Un-mangle client_port on return trip.

Any progress so far?

>  * IPv6 modules

ipv6 is not supported by conntrack or NAT, so I guess that's going to be
hard to support :)  This is has been discussed quite a number of times
on the devel list.

> Hints for implementing IPv6 conntrack and nat modules especially appreciated
> (why are there no IRC or FTP modules for IPv6?)

see above...

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Experimental RTSP modules

[Tom Marshall]

[-- Attachment #1: Type: text/plain, Size: 1185 bytes --]

On Fri, May 23, 2003 at 09:58:43PM +0200, Harald Welte wrote:
> On Sat, Apr 05, 2003 at 07:35:32PM -0800, Tom Marshall wrote:
> > Please note this is an experimental module.  It works for me.  It may work
> > for you, it may panic your kernel, or it may just sit there using ram.
> 
> great news. If you could convert it to patch-o-matic format, I'm happy
> to include it!

Thank you.

I am interested in getting the module into the mainline kernel.  I believe
this is where the majority of users are.  I have not and will not use p-o-m. 
I will convert the patch to use kernel coding standards if someone would
sponsor the change to the 2.4 kernel, but any changes necessary to use p-o-m
will need to be done by someone else because I have zero interest.

> >  * Handle multiple SETUP messages in a single packet.
> >  * Un-mangle client_port on return trip.
> 
> Any progress so far?

Well, no feedback so far at all so I have left the code alone for the
moment.  I'm sure you are familiar with the phenomenon.  ;-)

-- 
Football combines the two worst features of American life.
It is violence punctuated by committee meetings.
        -- George F. Will

[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Experimental RTSP modules

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]

On Sat, May 24, 2003 at 07:30:23AM -0700, Tom Marshall wrote:

> Thank you.
> 
> I am interested in getting the module into the mainline kernel.  I believe
> this is where the majority of users are.  I have not and will not use p-o-m. 
> I will convert the patch to use kernel coding standards if someone would
> sponsor the change to the 2.4 kernel, but any changes necessary to use p-o-m
> will need to be done by someone else because I have zero interest.

It is not a change of the actual code, it's just a different formatting
for the patch.  And as you want to get it into the mainline kernel, you
will have to submit it to the netfilter maintainer(s), which is the
netfilter coreteam (us).

And we prefer patch-o-matic format, since this is the opportunity to
have the code being tested for some time, until we conclude that it is
safe to submit it to the mainline kernel.

Of course you are free to submit in any form, it would just make our
work easier if it was p-o-m.  I think we already receive 95% of the
contributions in this format.

> Well, no feedback so far at all so I have left the code alone for the
> moment.  I'm sure you are familiar with the phenomenon.  ;-)

yes, indeed :)

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]