I'd like to thank everyone who replied. For the sake of brevity I'm
replying with one message instead of several individual replies.
> ak@suse.de asked "Sounds like a bug in the protocols. Why this
restriction?"
The complete port assignment specification is:
from to application priority
-------------------------------
0 16383 unclassified lowest
16384 32767 audio highest
32768 49151 whiteboard medium
49152 65535 video low
The idea is to allow routers to be able to prioritize multicast traffic
based on the port number that is used for the session (e.g., audio is given
priority over video). This prioritization is actually implemented in some
routers, although there is nothing to prevent a particular media type from
using any particular port. SDR conforms to this port-assignment
methodology, and thus affects the port selection choice for most global
multicast traffic sessions.
> The workaround is to not enable CONFIG_IP_MASQUERADE in the kernel
configuration.
That's what I was afraid of (Red Hat apparently enables CONFIG_IP_MASQUERADE
by default), but I do like the code diff for the kernel. I look forward to
it being incorporated in 2.2.18. Since I do development work, on occasion,
for UC Berkeley's versions of vic and vat I was concerned about having to
include a "recompile your kernel" step into the readme file for Linux--the
typical user for these types of apps is used to multi-megabit (if not
gigabit) network connections, but cowers at the thought of even performing a
simple kernel update via an RPM.
Meelis Roos reply goes a step further to question the manner in which the
port assignments were hard-coded into the kernel with only a single
purpose/application in mind. This question crossed my mind several times,
but I didn't want to appear overly assertive in my first post.
Thanks again,
MD
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:25 EST