Date: Fri, 09 Jul 1999 14:16:44 +0100 From: Kevin Bracey <kbracey@e-14.com> To: freebsd-net@freebsd.org Subject: Re: interesting connect(2) side effect... Message-ID: <c099ed1e49%kbracey@kbracey.acorn.co.uk> In-Reply-To: <199907081818.UAA29438@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <199907081818.UAA29438@labinfo.iet.unipi.it>
Luigi Rizzo <luigi@labinfo.iet.unipi.it> wrote:
> Hi,
>
> an interest side effect of connect(2) on BSD-derived systems (checked
> on the bible aka Stevens vol.2). It came out when implementing the
> sender side of PGM.
>
> As we all know, when doing a connect() on a socket, the faddr field
> of the pcb is set with the destination address -- a multicast one
> in the case of PGM, or for many uses of multicast UDP sockets.
>
> As a side effect,when demuxing input packets, faddr is also compared
> with the _source_ address of the incoming packets, unless it is
> INADDR_ANY. This happens in in_pcblookup() or variations.
>
> This is fine with TCP because a socket is only supposed to receive
> from its peer. Kind of works (because of the INADDR_ANY hack) with
> non-connected datagram sockets where transmission is done using
> sendto().
>
> It is in my opinion totally broken with connected datagram sockets,
> where the connect has the side effect of in-kernel packet filtering
> based on source address (who said that you cannot do that!).
It's not a side effect - it's a basic required feature! My TFTP client
relies on it to filter incoming multicast TFTP channels, which are keyed
by server address+port.
>
> Even if the above is a reasonable model of operation for some
> unicast UDP-based service, it is totally problematic with multicast
> where one might want to use the same socket to send multicast and
> collect feedback from the receivers -- in this case there is no way the
> source IP can match the multicast address.
> I suppose this problem came out when developing RTP/RTCP apps and
> is the reason why two different sockets are used for sending and
> receiving stuff!
>
> Would there be strong objections in making a slight modification to
> in_pcblookup() and friends to skip the check against faddr if this is a
> multicast address ?
>
Hmmm. Any user code that relied on this wouldn't be very portable.
Surely easier to just not connect the socket in the first place, and use
sendto? I've been involved in writing a TFTP Multicast server where this sort
of came up - although you need to unicast as well as multicast from the
socket, so you still can't connect.
If you really want to connect, could you not open two sockets with
SO_REUSEPORT/ADDR (whichever is necessary):
Local address Remote address
machine.5555 239.192.4.0.tftp-mcast
machine.5555 *.*
Then the kernel would filter incoming packets to the second port.
--
Kevin Bracey, Senior Software Engineer
Pace Micro Technology plc Tel: +44 (0) 1223 725228
645 Newmarket Road Fax: +44 (0) 1223 725328
Cambridge, CB5 8PB, United Kingdom WWW: http://www.acorn.co.uk/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c099ed1e49%kbracey>