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

<mal.hubert@bt.com> Mon, 15 April 2019 08:12 UTC

Return-Path: <mal.hubert@bt.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A131212009C for <pim@ietfa.amsl.com>; Mon, 15 Apr 2019 01:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqktpcstXDA4 for <pim@ietfa.amsl.com>; Mon, 15 Apr 2019 01:12:33 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [213.121.32.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE26C120104 for <pim@ietf.org>; Mon, 15 Apr 2019 01:12:32 -0700 (PDT)
Received: from rew09926dag07c.domain1.systemhost.net (10.55.202.42) by BWP09926067.bt.com (10.50.151.90) 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 rew09926dag07b.domain1.systemhost.net (10.55.202.38) by rew09926dag07c.domain1.systemhost.net (10.55.202.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 09:12:29 +0100
Received: from rew09926dag07b.domain1.systemhost.net ([fe80::3597:bc94:cdb8:9d49]) by rew09926dag07b.domain1.systemhost.net ([fe80::3597:bc94:cdb8:9d49%12]) with mapi id 15.00.1395.000; Mon, 15 Apr 2019 09:12:29 +0100
From: mal.hubert@bt.com
To: linus.luessing@c0d3.blue
CC: pim@ietf.org
Thread-Topic: [pim] Group-Specific Queries dropped by kernel
Thread-Index: AdTxLB/StBdCEYp1RDa29yj4Bqm5LAArfG0AAGIIUFA=
Date: Mon, 15 Apr 2019 08:12:28 +0000
Message-ID: <65170f1824bb44cab5dde88bc16f7fc5@rew09926dag07b.domain1.systemhost.net>
References: <40be04cccedb47b78e62771e4aeaabda@rew09926dag07b.domain1.systemhost.net> <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-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.55.202.233]
Content-Type: multipart/mixed; boundary="_002_65170f1824bb44cab5dde88bc16f7fc5rew09926dag07bdomain1sy_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/9lmY4_aFf4CO7apZN2uKsLPNT7A>
Subject: Re: [pim] Group-Specific Queries dropped by kernel
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Apr 2019 08:12:37 -0000

Linus,

Thanks for looking at this. Capture attached.

Mal

-----Original Message-----
From: Linus Lüssing [mailto:linus.luessing@c0d3.blue] 
Sent: 13 April 2019 11:20
To: Hubert,MT,Mal,TLV2 R
Cc: pim@ietf.org
Subject: Re: [pim] Group-Specific Queries dropped by kernel

Hi Hubert,

On Fri, Apr 12, 2019 at 12:34:52PM +0000, mal.hubert@bt.com 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 0.0.0.0 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
0.0.0.0 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
0.0.0.0 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 0.0.0.0 being accepted." (which
seems wrong) in the changelog here:

https://elixir.bootlin.com/linux/v5.0/source/net/ipv4/igmp.c#L47

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