From owner-freebsd-net Fri Jul 9 8:25:11 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 4AD9114DF4 for ; Fri, 9 Jul 1999 08:25:00 -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 QAA22728 for ; Fri, 9 Jul 1999 16:24:58 +0100 (BST) Date: Fri, 09 Jul 1999 16:24:50 +0100 From: Kevin Bracey To: freebsd-net@freebsd.org Subject: Re: interesting connect(2) side effect... Message-ID: <154f91e49%kbracey@kbracey.acorn.co.uk> In-Reply-To: <199907091147.NAA01166@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 <199907091147.NAA01166@labinfo.iet.unipi.it> Luigi Rizzo wrote: > > > 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. > > i was considering this a side effect because i can't find documentation > mentioning this as a feature -- certainly not the connect(2) manpage. > Not to mention that nothing prevents a second, unprivileged app on > your server send packets on the same UDP port -- if you want to do > a safe filtering you do need a better mechanism. It's not "safe filtering" - it's just the way the protocol works :) It reduces client size/overhead if the kernel filters out the unwanted multicasts for you. Connecting a UDP socket does exactly what I'd expect. It restricts you to sending to particular addr/port pair, and limits you to receiving from that addr/port pair. Further, it also starts picking up ICMP messages related to that addr/port to allow you to detect Destination Unreachable conditions. If it didn't actually filter on source addr/port, then that's half the of the meaning of connect() lost. Now, there might be an argument for saying that connect to a multicast address means you can receive from anything, but I'm sure an equally strong argument for connecting to a multicast address meaning you can receive nothing. -- 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