From owner-freebsd-hackers Fri Mar 3 07:19:32 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id HAA19776 for hackers-outgoing; Fri, 3 Mar 1995 07:19:32 -0800 Received: from plains.NoDak.edu (tinguely@plains.NoDak.edu [134.129.111.64]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id HAA19769 for ; Fri, 3 Mar 1995 07:19:27 -0800 Received: by plains.NoDak.edu; Fri, 3 Mar 1995 09:19:02 -0600 Date: Fri, 3 Mar 1995 09:19:02 -0600 From: Mark Tinguely Message-Id: <199503031519.AA16567@plains.NoDak.edu> To: ajit@louie.udel.edu Subject: Re: multicast pruning Cc: atn-group@mitre.org, freebsd-hackers@FreeBSD.org, slr@mitre.org, wollman@halloran-eldar.lcs.mit.edu Sender: hackers-owner@FreeBSD.org Precedence: bulk > In message <199503030019.AA29879@plains.NoDak.edu>you wrote: > >can you automatically pick up new groups from the tunnel? I don't > >know if there is still a bug or if my regional net is having a > >problem. > > If I understand your question properly, you want to detect the appearance > of groups at the end of a tunnel. The mrouted at the other end of the > tunnel should detect the presence of groups, i.e. a router can only > detect groups on any attached interface. NWNet mbone mrouter <====> FreeBSD mrouted <---> machine running sd == tunnel -- LAN the local sd is not detecting new groups from the "outside world" I had traces in the function X_ip_mforward() in the kernel file /sys/netinet/ip_mroute.c, and I don't recieve tunnel packets, because I do not belong to a remote multicast groups, but I can't join until I get a list of groups...MWnet insists we have a "32" ttl and it is possible that there is nothing to see and that is why I asked the question. (yes, I believe in the power of run-on sentences) I would appreciate if someone could check if they can detect remote groups or see if you can see a multicast group called "ndsu wb", or if someone is willing to set up a mini-mbone to test the tunnelling, I would apprecaite it. > > I don't see why the path of the dump files should be changed to > /var/tmp and /var/run. A number of systems do not have a directory > called /var/run. FreeBSD 2.x (more accurate 4.4 based OSes) don't have /usr/tmp, and also /var/run is the location for process ID of running programs. I was proposing a change in /usr/src/usr.sbin/mrouted/main.c for 4.4 based OSes, I should have included a #ifdef for 4.4 systems. thanks again for all the help/interest. --mark.