From owner-freebsd-hackers  Mon Aug 21 11:30:58 1995
Return-Path: hackers-owner
Received: (from majordom@localhost)
          by freefall.FreeBSD.org (8.6.11/8.6.6) id LAA04704
          for hackers-outgoing; Mon, 21 Aug 1995 11:30:58 -0700
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by freefall.FreeBSD.org (8.6.11/8.6.6) with SMTP id LAA04698
          for <hackers@freebsd.org>; Mon, 21 Aug 1995 11:30:56 -0700
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <16700(3)>; Mon, 21 Aug 1995 11:30:13 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177475>; Mon, 21 Aug 1995 11:30:05 -0700
X-Mailer: exmh version 1.6.1 5/23/95
To: davidg@root.com
cc: hackers@freebsd.org
Subject: Re: Multicast on PPP devices 
In-reply-to: Your message of "Mon, 21 Aug 95 11:18:54 PDT."
             <199508211818.LAA00148@corbin.Root.COM> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 21 Aug 1995 11:29:51 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <95Aug21.113005pdt.177475@crevenia.parc.xerox.com>
Sender: hackers-owner@freebsd.org
Precedence: bulk

In message <199508211818.LAA00148@corbin.Root.COM> you write:
>   It was changed to allow the local IPaddr of a point-to-point interface to
>be shared, thus routing has to be based on the destination. Do you have a
>suggestion on how to keep this functionality and not break multicasts over
>point-to-point links?

The problem is that multicasts are forwarded based on source address.  There 
is a table mapping (Source, Group) -> (iif, oiflist) where iif is the expected 
incoming interface, and the oiflist is the list of outgoing interfaces.  If 
this is changed to (S, G, iif) -> (oiflist), with the current architecture of 
the code, you can easily create forwarding loops.

The key to the problem is that the multicast forwarding code treats input 
packets and output packets the same; in fact, if you are a member of a group 
on an interface, and you output a packet on that interface, that packet is 
looped around to the IP input queue, and forwarded from the ip_input() side.

In any case, this problem is fermenting in the back of my mind, but I 
certainly don't have an immediate solution.  I'm afraid that the solution is 
changing the architecture, which I'm certainly not up to at the moment.

  Bill