From owner-freebsd-net@FreeBSD.ORG Wed Sep 9 23:42:17 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 56FCD106566C for ; Wed, 9 Sep 2009 23:42:17 +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 48ECE8FC17 for ; Wed, 9 Sep 2009 23:42:17 +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: Wed, 9 Sep 2009 23:42:17 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 09 Sep 2009 23:42:17 -0000 X-List-Received-Date: Wed, 09 Sep 2009 23:42:17 -0000 Bruce Simpson wrote: > I think this can probably go right in as-is. I'm supposed to be looking > at other stuff now, so hopefully syrinx@ can check this in if I don't > get around to it. Great news. Should I just make a PR for this? Or is there somewhere I should put it for the 8.0 BETA? After these various (posted) multicast patches OSPF (with quagga) is now far more stable on 8.0-BETA4. However I'm still seeing intermittent problems. I need help in knowing how to debug the following. Once it's figured out, I'd like to make a patch. Specifically: Quagga has a sockets open on em0, portillo1, and northstar1 below on the 224.0.0.5 group. ifmcstat output: > em0: > inet 172.27.2.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.5 mode exclude > mcast-macaddr 01:00:5e:00:00:05 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > em1: > inet 189.162.25.187 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > lo0: > inet 127.0.0.1 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > inet6 fe80::1%lo0 > mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3 > group ff01::1%lo0 mode exclude > group ff02::2:10c2:bd48%lo0 mode exclude > group ff02::1%lo0 mode exclude > group ff02::1:ff00:1%lo0 mode exclude > leaseweb0: > inet 10.94.75.3 > igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3 > group 224.0.0.1 mode exclude > mcast-macaddr 01:00:5e:00:00:01 > 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 > eaglecrest1: > inet 172.28.1.70 > 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 After a while and a few interface ups and downs, quagga stops getting OSPF packets on one of the interfaces. I can verify with tcpdump that these packets are seen by the machine. For example, on em0: > # tcpdump -pnti em0 proto ospf > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 > IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44 > IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48 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. Where and how could I see what's preventing these packets from being delivered to the ospfd process socket? Which code is involved in the dispatch? Thanks for your help and time. Much appreciated. Cheers, Stef