From owner-freebsd-net Thu Jul 8 13:48:18 1999 Delivered-To: freebsd-net@freebsd.org Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (Postfix) with SMTP id 7E9F514FF9 for ; Thu, 8 Jul 1999 13:48:07 -0700 (PDT) (envelope-from luigi@labinfo.iet.unipi.it) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id UAA29438; Thu, 8 Jul 1999 20:18:25 +0200 From: Luigi Rizzo Message-Id: <199907081818.UAA29438@labinfo.iet.unipi.it> Subject: interesting connect(2) side effect... To: net@freebsd.org Date: Thu, 8 Jul 1999 20:18:25 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2061 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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!). 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 ? cheers luigi -----------------------------------+------------------------------------- Luigi RIZZO, luigi@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ ==== First International Workshop on Networked Group Communication ==== -----------------------------------+------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message