Many existing packet filters are not well suited for handling applications with dynamic ports. Such applications use control channels with well-known port numbers, while data transfer takes place over ports that are negotiated dynamically. Examples are found in peer-to-peer networks and multimedia streams that employ control protocols like RTSP, SIP and H.323 [,]to negotiate port numbers for data transfer protocols such as RTP [].
These flows are complex to monitor and the problem was considered
important enough to develop a special-purpose tool (mmdump, not
unlike tcpdump) to tackle it [32]. Like
xPF [19], mmdump adds statefulness to the
pcap/BPF architecture and in addition allows filters to be
self-modifying. A filter may capture and inspect all control packets
and if they contain the port number to be used for data, modify itself
to also capture these packets.
While the same behaviour is supported in FFPF which allows an external
function to extend the FPL-1 expression from which it was called
(subject to authorization constraints), this may not be best way of
handling the problem: self-modifying code is difficult to trace and
debug. Moreover, there is a simpler way to monitor dynamic ports. For
example, given that RTSP packets are sent on port 554, the filter in
Figure 7 filters out all such packets and passes them to
an external function GetDynTCPDPortFromRTSP. When called, the
function scans all RTSP session packets for the occurrence of
`Transport', `client_port' and `server_port' to
find the port numbers that will be used for data transfer (e.g., audio
and video). These ports are stored in
(lines 4-5). If the packet
is not RTSP, we check if the destination port of the packets is in the
array of port numbers and if so, return the value TRUE
(lines 7-9), so that the packet is sent to userspace. In other words,
only data packets of streams that are set up using RTSP are sent
to userland. Note that the example is for illustration purposes
only. It is a simplified version of what real applications would
use. For instance, we only deal with transfers that use TCP (also for
the data) and extract just a single destination port (while the
traffic is likely to be bi-directional).
![\begin{figure}\begin{center}
\begin{scriptsize}\begin{verbatim}1. // R[0] ini...
...d{verbatim}\end{scriptsize}\vspace{-2mm}\vspace{-7mm}
\end{center}\end{figure}](img26.png)