I'd like to thank everyone who replied. For the sake of brevity I'm replying with one message instead of several individual replies. > [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/