Ethereal-dev: Re: [ethereal-dev] non-standard UDP ports for standard protocolls ???
> tftp 69-100
Does TFTP ever use a port that's neither
1) the standard TFTP port
nor
2) the source port of the reply to the initial TFTP request?
If not, there's no need to use a rule such as that for TFTP; one merely
has to ensure that one doesn't decode packet N of a TFTP series without
having decoded packet N-1 (which might be done with the scheme I'd
thought of, where the *entire* packet list gets decoded, in strictly
sequential order, before any displaying is done, with the decoding
attaching a "property list" to each packet).
However, such a mechanism *would* be useful in general. The Network
General Sniffer has a mechanism for "protocol forcing", which let you,
among other things, say that if either the source or destination port is
N, decode the payload as being protocol XXX.
There's no reason to limit this to UDP; it would be useful here, for
example, to be able to specify "decode port 3128 as HTTP" (assuming we
did anything special with HTTP; I might add support to show the contents
of HTTP requests and replies as multi-line text, at least when it *is*
text), because that's the default port for our NetCache proxy caching
software and appliances.
> Question: how many protocols
> a) dont have a standard udp port ?
NIS
NIS+
NLM (the NFS lock manager protocol)
NSM (the "Network Status Monitor" protocol that goes with NLM)
"mount" (the protocol used for NFS mounts)
every other ONC RPC protocol other than the portmapper/rpcbind
(which needs a well-known port, and uses 111) and NFS (which, by
a fairly hard convention, is 2049)
However, I think the right way to handle *that* is to detect ONC RPC
requests and replies by looking for the RPC version number "2" (i.e.,
version 2 of the ONC RPC protocol) and a known RPC program/version
number at the appropriate locations (which will find RPC calls), or
looking for a transaction ID for an RPC call we've seen at the
appropriate location (which will find RPC replies - you need the call in
any case, as the reply does *not* say what program, version, or
procedure the reply is for). "snoop" apparently uses a heuristic of
some sort to identifiy ONC RPC requests and replies.
There may be others; note that "tcpdump" has a mechanism that allows you
to force protocols that match a particular expression to be forced to be
decoded as ONC RPC, RTP, RTCP, VAT, and WB packets, so presumably some
of them (in addition to ONC RPC) may not always use standard ports.
