From owner-freebsd-net Fri Jul 9 6:16:58 1999 Delivered-To: freebsd-net@freebsd.org Received: from mh.acorn.co.uk (mh.acorn.co.uk [136.170.131.2]) by hub.freebsd.org (Postfix) with ESMTP id 34F04155B7 for ; Fri, 9 Jul 1999 06:16:39 -0700 (PDT) (envelope-from kbracey@e-14.com) Received: from kbracey.acorn.co.uk (kbracey [136.170.129.213]) by mh.acorn.co.uk (8.8.6/8.8.6) with SMTP id OAA18394 for ; Fri, 9 Jul 1999 14:16:36 +0100 (BST) Date: Fri, 09 Jul 1999 14:16:44 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: interesting connect(2) side effect... Message-ID: In-Reply-To: <199907081818.UAA29438@labinfo.iet.unipi.it> X-Organization: Acorn Computers Ltd, Cambridge, United Kingdom X-Mailer: Messenger v1.40f for RISC OS MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Posting-Agent: RISC OS Newsbase 0.61b Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <199907081818.UAA29438@labinfo.iet.unipi.it> Luigi Rizzo 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