In article <20050301204333.9DABB1FF6@fnord.ir.bbn.com>,
Greg Troxel  <gdt@ir.bbn.com> wrote:
>I have some systems running current from 20050202.
>
>Two systems run pppd(8), and once a day one end brings down the link
>and reestablishes it (to work around a buggy PBX that drops long calls
>at inconvenient times).  The system runs quagga, with ospfd and
>ripngd.  The system has frequently paniced around the link down/up
>time.
>
>One crash occurred when apparently trying to leave a group that had
>been joined on the ppp interface.  The ifp had if_softc and others set
>to 0xdeadbeef, indicating it had been freed, and on a similar crash
>the other end had pppioctl as if_ioctl.  But, the struct in_multi
>still had an ifp reference.
>
>Other crashes have occured in in6_selecthlim.  I didn't manage to get
>dumps from those, but I suspect that ifp->af_data[AF_INET6] has been
>freed and therefore this code:
>
>	else if (ifp)
>		return (ND_IFINFO(ifp)->chlim);
>
>dereferences a NULL pointer.  The DDB backtrace looked like the ripng
>transmit path.
>
>The machine that receives the ppp calls also crashes, due to the stray
>ifp in multicast memberships.
>

So the problems are limited to igmp and in6? For the igmp case, I looked
at the code and it seems that it is doing the right thing to me. If we
can come up with a simple test case then it should be easy to debug it.

christos