Date: Wed, 09 Sep 2009 23:42:17 -0000 From: Stef Walter <stef-list@memberwebs.com> To: Bruce Simpson <bms@incunabulum.net> Cc: "freebsd-net@FreeBSD.org" <freebsd-net@freebsd.org> Subject: Re: [patch] Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP Resent-Message-ID: <none> References: <4AA83230.4070405@incunabulum.net>
| previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?>