Re: [pim] Group-Specific Queries dropped by kernel

<> Mon, 15 April 2019 08:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A131212009C for <>; Mon, 15 Apr 2019 01:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YqktpcstXDA4 for <>; Mon, 15 Apr 2019 01:12:33 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE26C120104 for <>; Mon, 15 Apr 2019 01:12:32 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1531.3; Mon, 15 Apr 2019 09:12:07 +0100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 09:12:29 +0100
Received: from ([fe80::3597:bc94:cdb8:9d49]) by ([fe80::3597:bc94:cdb8:9d49%12]) with mapi id 15.00.1395.000; Mon, 15 Apr 2019 09:12:29 +0100
Thread-Topic: [pim] Group-Specific Queries dropped by kernel
Thread-Index: AdTxLB/StBdCEYp1RDa29yj4Bqm5LAArfG0AAGIIUFA=
Date: Mon, 15 Apr 2019 08:12:28 +0000
Message-ID: <>
References: <> <20190413102000.GA2085@otheros>
In-Reply-To: <20190413102000.GA2085@otheros>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_002_65170f1824bb44cab5dde88bc16f7fc5rew09926dag07bdomain1sy_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [pim] Group-Specific Queries dropped by kernel
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2019 08:12:37 -0000


Thanks for looking at this. Capture attached.


-----Original Message-----
From: Linus Lüssing [] 
Sent: 13 April 2019 11:20
To: Hubert,MT,Mal,TLV2 R
Subject: Re: [pim] Group-Specific Queries dropped by kernel

Hi Hubert,

On Fri, Apr 12, 2019 at 12:34:52PM +0000, wrote:
> Hey
> Hopefully someone on here can answer this basic query for me. It would appear
> that the Linux kernel by default will allow IGMPv3 "General Query" if it has a
> source IP of but will drop any "Group-Specific Queries" if the source
> IP is 0..0.0.0. This doesn't appear to be specific to my implementation and
> seems to be the implementation in the Linux Kernel.
> Some questions about this, if someone would be so kind as to help.
> 1)    Is this by design in the rfc3367 standard and would someone point out to
> me where it is and enlighten me as to why this is the case.

I couldn't find anything like this in RFC3367. I searched for and "zero" in this document, but these only seem to be
mentioned for the IGMPv3 report source address and the group
address for IGMP queries.

There is a "4.2.13. IP Source Addresses for Reports" but no
equivalent in 4.1 for IGMP queries.

> 2)    Is this by design in the Kernel and would enlighten me as to why this is
> the case.

Hm, for the Linux bridge IGMP snooping code at least I think we do not
have such a restriction (or I keep missing it while rereading the code). Both
an IGMPv3 "General Query" and "Group-Specific Queries" with a source addres should be accepted here.

In the Linux IPv4 stack code I wasn't able to find such a restriction either.
igmp_rcv() or igmp_heard_query() do not seem to have such a
check? But I'm not that familiar with the IP stack code - do you
know where this check should be?

I do see a comment "Stop IGMP from being accepted." (which
seems wrong) in the changelog here:

But as it came with the big git import in 2005 I'm unable to track
with "git blame" etc. what Alan had actually changed in the code.

Could you share a tcpdump capture of the IGMP queries your
application is sending? Maybe "by coincidence" the IGMP or IP
checksums are messed up only for the Group-Specific IGMP queries
in your application or something like that?

Does Wireshark remark anything suspicious for your IGMP queries?

Regards, Linus