/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting!
/* ALSO: Don't quote this header. It makes you look lame :-) */
It is a complete rewrite of the module. The major functional difference is
that my module does not support PNA (an old pre-G2 binary protocol) but
attempts to do RTSP as correctly as possible. By correct, I mean that the
module replaces the client_port in both directions. All previous modules
"leak" the masq box's allocated port back to the client like this:
C->S: Transport: RTP/AVP/UDP;client_port=6970-6971
(masq module replaces client_port with something like 60246-60247)
S->C: Transport: RTP/AVP/UDP;client_port=60246-60247;server_port=10026-10027
My module will replace the client_port with the original values before
sending the reply back to the client. Others don't.
Some comments from the top of the module source:
* - This is a complete rewrite of the code. Emphasis has been placed
* on correctness. It has been written and tested on the 2.2.18 kernel
* but should work with any recent 2.2.x kernel. I have heard rumor that
* the masq code changed slightly somewhere around 2.2.5 so you will
* probably want 2.2.6 or later. If you know exactly what changed and
* when, I would be interested in knowing.
*
* - This module doesn't keep any state between packets, so there is a
* (extremely remote) possibility that we will misinterpret the data.
*
* - In order to be "seen", an RTSP message must be contained within a
* single packet, or at least begin on a packet boundary and include the
* transport and cseq headers. It is conceivable that messages could
* span packets (suppose the headers are written one line at a time).
* I am not aware of any apps that do such a silly thing.
*
* - Multiple RTSP messages in a single packet are handled, including
* entities (note: this is mostly untested). TCP interleaved data is
* not handled, but support could/should be added.
*
* - Multicast transports are ignored (we should probably strip them).
*
* - Encoding/recording (eg. RealProducer, SLTA) is fully supported,
* provided that the server's encoder port is in the list. SLTA worked
* fine in my tests, but RealProducer seemed to be a bit shaky (lots of
* rebuffering on the clients). I don't think that was related to this
* module, but I can't say for sure.
*
* - client_port mapping uses the cseq to track request/response pairs
* because we cannot rely on the client_port values in the server's
* response (ie, if another firewall running a broken masq module is
* between us and the server). In an ideal world, we would just lookup
* the returned client_port value in a mapping table and replace it.
*
* - We don't track teardowns to release the mports. There are two reasons
* for this: (1) the masq code relies on timeouts, there is no mport
* delete function, and (2) the RTSP protocol makes it prohibitive. We
* would have to track sessions, which are tokens of arbitrary size. It
* would be nice if the client_port was sent in the teardown request.
*
* - RTP port allocation sucks. It's an irritant on the client side, it's
* a pain on the server side, and it's downright hostile in between.
* There is no reason that RTP couldn't have been designed to use two
* unrelated UDP ports, or even a single UDP port. Whoever designs
* standard internet protocols should be required to either have done
* proxy/firewall coding or consult with someone who was.
On Sun, Sep 09, 2001 at 10:08:38AM -0700, David Ranch wrote:
>
> >My RTSP masquerading module should work for this. Make sure that you are
> >using the standard encoding port or use the ports option when loading the
> >module.
>
> Hey Tom,
>
> Hows does your RTSP module compare to the one that Eddie modified
> a while ago to support both RealAudio and RTSP-based QuickTime?
>
> http://www.e-infomax.com/ipmasq/files22/ip_masq_raudio.c.tgz
>
> --David
>
> .----------------------------------------------------------------------------.
> | David A. Ranch - Linux/Networking/PC hardware [EMAIL PROTECTED]
> |
> !----
> ----!
> `----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch
> -----'
_______________________________________________
Masq maillist - [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ --
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]
PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.
