/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting!
/* ALSO: Don't quote this header. It makes you look lame :-) */
Hey Tom,
Any plans to submit this to be included in the next version
of the 2.2.x kernels? Any plans to port it to 2.4.x kernels
as this is sorely missing today.
--David
>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
>> -----'
>>
.----------------------------------------------------------------------------.
| 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.
