From owner-freebsd-questions Tue Aug 21 6:37:34 2001 Delivered-To: freebsd-questions@freebsd.org Received: from grant.org (grant.org [206.190.164.98]) by hub.freebsd.org (Postfix) with ESMTP id EED9337B40C for ; Tue, 21 Aug 2001 06:37:30 -0700 (PDT) (envelope-from mgrant@splat.grant.org) Received: from splat.grant.org (mgrant@host213-122-9-169.btconnect.com [213.122.9.169]) by grant.org (8.11.3/8.11.3) with ESMTP id f7LDbT408880 for ; Tue, 21 Aug 2001 09:37:29 -0400 (EDT) (envelope-from mgrant@splat.grant.org) Received: (from mgrant@localhost) by splat.grant.org (8.9.3+Sun/8.9.1) id OAA22808; Tue, 21 Aug 2001 14:37:25 +0100 (BST) Date: Tue, 21 Aug 2001 14:37:25 +0100 (BST) Message-Id: <200108211337.OAA22808@splat.grant.org> From: Michael Grant To: freebsd-questions@FreeBSD.ORG Subject: Re: mtrace Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG You're a genius, thanks. It was the firewall. I added the following rule to my ipf.conf and now it works fine. pass out quick proto 2 all "No route to host" is a really strange error to me. I guess the packet is somehow stopped before it gets sent out and EHOSTUNREACH is returned. I personally think the packet should be sent down and blocked by the firewall such that the firewall would put something into it's logs. This doesn't seem to be happening though. -Mike mark tinguely wrote: > Do you have a packet filter enabled, what I hear you saying sounds a lot > like a packet filter rule discarding the multicast packets. > > If you are really sure that there is no packet filtering going on, then: > > If you stop the multicast daemon, start tcpdumps (-n -net 224) on xl0 and lo0, > start a multicast application such as vic 224.2.2.4/2224 (transmit using the > X window as your source). If you see no multicast traffic, then the packets > are not making it to the stack or out the driver. > > A check in the network stack (ip_output in sys/netinet/ip_output.c) or > in the xl driver sys/pci/if_xl.c may indicate the problem. tcpdump > should be just as good as the last test, so I would look what is going > on in the ip_output() code. > > There was a recent (after 4.3-RELEASE) patch to sys/netinet/ip_output.c > to better handle multicast routes, but by having a static multicast > route like you have would be the same affect. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message