smurf@noris.de said:
} Found another one... this fixes an inability to bind to multicast
} ports in the masq range. The problem prevents me from listening to the
} IETF mbone video broadcast (channel 1).
alan@lxorguk.ukuu.org.uk said:
} Not a nice fix. Just move the Masquerade port range (or maybe make it
} a sysctl set range so you can shuffle it about if needed).
smurf@noris.de said:
} This is about multicasting. I have NO control at all to which port
} somebody out there in the Internet binds their video or audio feed. If
} I reserve a random 1024-port range for masquerading, the chance is
} 1:32 (if you exclude the ports <32768) that it conflicts with
} _something_ out there; there already are more than 32 existing
} sessions on the mbone, and the Mbone won't shrink either. The range
} cannot be made changeable by Joe User either, so would require at
} least CAP_NET_ADMIN. :-( Currently it cannot be changed dynamically
} without breaking existing masqueraded connections, which is another
} problem that I won't be able to fix even if I saw the need to do that.
A shortish term fix, which I don't like much since it puts some policy
into the kernel, would be to make the demasquerade conditional on the
stuff not being multicast. Multicast has a well defined address range set
so detecting if the source/dest are multicast sets should be easy enough
to do.
Outgoing stuff can be handled by firewall rules (different problem to that
described above anyhow). You would normally use a router of some sort
rather than trying to shove it down the masq tunnel anyhow.
This still doesn't fix what happens if someone wants to bind a unicast
port into the masq range. More thought it needed here - putting sockets
in costs in memory and gets all the layering mixed up. I think I need my
paradigms shifting.
Nigel.
-- [ Nigel.Metheringham@theplanet.net - Systems Software Engineer ] [ Tel : +44 113 207 6112 Fax : +44 113 234 6065 ] [ Real life is but a pale imitation of a Dilbert strip ] [ We're recruiting http://www.theplanet.net/profile/recruit.htm ]
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/