Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jul 1999 13:47:10 +0200 (MET DST)
From:      Luigi Rizzo <luigi@labinfo.iet.unipi.it>
To:        kbracey@e-14.com (Kevin Bracey)
Cc:        freebsd-net@FreeBSD.ORG
Subject:   Re: interesting connect(2) side effect...
Message-ID:  <199907091147.NAA01166@labinfo.iet.unipi.it>
In-Reply-To: <c099ed1e49%kbracey@kbracey.acorn.co.uk> from "Kevin Bracey" at Jul 9, 99 02:16:25 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.

> > 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.

well, my case was for implementing Cisco's PGM, and specifically the
problem arises because the sender needs to get unicast NAKs from
receivers/routers. I can't use sendto because PGM is
connection-oriented (kind-of), and i cannot use a second socket because
the state machine on the sender is associated with the first one.

Now it turns out that for PGM there is an easier solution since the
multicast demux code already does what i need and thus it is easy to
use it for unicast as well. But i was thinking if the current way of
implementing socket-matching for multicast UDP isn't just the result
of quick adaptation of existing code without thinking too much at
the side effects.

	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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907091147.NAA01166>