panic: igmp_v3_dispatch_general_query: called when version 2

deeptech71 at deeptech71 at
Sat May 30 00:05:52 UTC 2009

Bruce Simpson wrote:
> I may not get free time to fix this right away, are you able to test a
> patch when I can make one available?


> It would be helpful if you could confirm, with a tcpdump capture forked
> from single user mode, if your FreeBSD host is receiving an IGMPv2 query
> when this problem is triggered.

How do I do that?
But it's not "when" it is triggered, but rather "if... ever".

> It sounds like your university LAN may well have an IGMPv2 capable
> multicast router present on the network. If you could double confirm
> this, via packet capture, that would be great.

Does this dump(snip) tell?

18:21:19.837291 IP > UDP, 
length 40
18:21:23.450396 IP > 
UDP, length 23
18:21:42.411459 IP > UDP, 
length 25
18:21:42.512624 IP > UDP, 
length 25
18:21:45.171807 IP > UDP, 
length 25
18:21:59.632491 IP > ALL-SYSTEMS.MCAST.NET: igmp query v2
18:22:01.336805 IP > igmp v2 
18:22:06.356016 IP > ALL-SYSTEMS.MCAST.NET: igmp query v2
18:22:06.364706 IP > ALL-SYSTEMS.MCAST.NET: igmp query v2
18:22:08.851672 IP > 0 PTR 
(QM)? (44)
18:22:08.873333 IP > igmp v2 
18:22:10.010465 IP > igmp v2 
18:22:10.649814 IP > UDP, 
length 21
18:22:10.750069 IP > UDP, 
length 21
18:25:07.368543 IP > igmp query v2 [max resp 
time 10] [gaddr]

> [I]f there is anything unusual about the format of the IGMPv2 queries from
> your university's vendor equipment, that would be good to know too.

Heh. How does that relate to the kernel code assigning a v3 handler to a 
v2 packet? (Looks something like that to me.) What if I say yes, and 
what if I say no? :)

Anyways, I'll try to contact the admin about that.

More information about the freebsd-current mailing list