From owner-freebsd-net@FreeBSD.ORG Thu Sep 10 03:09:32 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C6581065672 for ; Thu, 10 Sep 2009 03:09:32 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6FEB48FC08 for ; Thu, 10 Sep 2009 03:09:32 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Bruce Simpson References: <4AA83230.4070405@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Thu, 10 Sep 2009 03:09:32 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: Multicast SSM bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 10 Sep 2009 03:09:32 -0000 X-List-Received-Date: Thu, 10 Sep 2009 03:09:32 -0000 Stef Walter wrote: > The packets from 172.27.2.2 are not being delivered to the ospfd process > socket (verified via userland debugging and logging). Even though, as > you can see above the em0 interface is part of the group. I've done more research on this. Each time a packet is not delivered, I can see this counter being incremented: > # netstat -s -p ip | grep multicast > 885 packets received for unknown multicast group That counter originates from this block of code in raw_ip.c: > 354 blocked = imo_multi_filter(inp->inp_moptions, ifp, > 355 (struct sockaddr *)&group, > 356 (struct sockaddr *)&ripsrc); > 357 if (blocked != MCAST_PASS) { > 358 IPSTAT_INC(ips_notmember); > 359 continue; > 360 } After instrumenting it with this printf: > printf("not member: group = %s, ", inet_ntoa (group.sin_addr)); > printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked); Then wait, then up down some interfaces, etc.... quagga adds/drops memberships, eventually I see the following output: > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 > not member: group = 224.0.0.5, src = 172.28.1.66, why = 2 The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending OSPF multicast packets. Somehow imo_multi_filter is limiting via packet source for this membership. However, this is what the interface looks like via ifmcstat (ie: no SSM memberships): > portillo1: > inet 172.28.1.65 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > group 224.0.0.1 mode exclude Any of the above ring a bell? If not, I'll keep poking around and see what I find. Cheers, Stef