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

Linus Lüssing <linus.luessing@c0d3.blue> Mon, 15 April 2019 20:50 UTC

Return-Path: <linus.luessing@c0d3.blue>
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 DEF821200FB for <pim@ietfa.amsl.com>; Mon, 15 Apr 2019 13:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4
X-Spam-Level:
X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=c0d3.blue
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 iVQeydPojuuq for <pim@ietfa.amsl.com>; Mon, 15 Apr 2019 13:50:43 -0700 (PDT)
Received: from mail.aperture-lab.de (mail.aperture-lab.de [138.201.29.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA421201D7 for <pim@ietf.org>; Mon, 15 Apr 2019 13:50:42 -0700 (PDT)
Date: Mon, 15 Apr 2019 22:50:36 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1555361440; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aCIENjrMu2CblCBTxN2kxLFseOD1yMUNpv4XWPk/zQY=; b=ULYYxNSgT2fBrXVz1hgRmCqWLxRIm2SUwRa06V1Yz+G6v/JvQbSZbbWz+X4ryAKrDlphUt DZcqZhLr26ph2njBgzZ4BcL1YSh4/NX+wqEyjem1asIzBx3hT69Gew/70Cs5uGIWdOdzTx +JWRbsRaFyrn6nAgyHB3Sq8KHyHlDt0UdPwsROmfUMKjZiyBvRyAkvalJWUY+73u2gxi0i FQ0b6y7rs4lX5Jqgs0LlFua44tdDE2tl64O5mK8GXa7L5zGsfxK+flLPXIsSCVRFsRJTkP u3V0riQg8BcFN4nvmGsfokrHj9XUb98BREVkNVKtKab7s2hwcr9gjBfR8k5wPg==
From: Linus =?utf-8?Q?L=C3=BCssing?= <linus.luessing@c0d3.blue>
To: mal.hubert@bt.com
Cc: pim@ietf.org
Message-ID: <20190415205036.GE2085@otheros>
References: <40be04cccedb47b78e62771e4aeaabda@rew09926dag07b.domain1.systemhost.net> <20190413102000.GA2085@otheros> <65170f1824bb44cab5dde88bc16f7fc5@rew09926dag07b.domain1.systemhost.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <65170f1824bb44cab5dde88bc16f7fc5@rew09926dag07b.domain1.systemhost.net>
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=c0d3.blue; s=2018; t=1555361440; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aCIENjrMu2CblCBTxN2kxLFseOD1yMUNpv4XWPk/zQY=; b=GxA3SIwDIW3HH4qAXEWEs3HG2gz3/KPvQN36rkHQjhbIthuqhvcMUmVUKOxZRmGrh1gy5o 7dNQiVemURFrGoPC5HH84HsMwp/2ylrHgdf9+BE7wDNZsD92HroA9oMnU4jhZIVFqaRIJV CFhvQTIUjXo3lN2WJHxIadGbnFnFCA3+vxwWPJIz8jvPkM3sb5yflCF6lhD1mb+zPP6qhL q4DYpg1oMIqFlhGOZmBwdTeyEvfoSdQA0iBKHgmJcff7kxN0QV0K412eQbEX1eY52GpMse gWmOptICqgXb19LLNCQSLe6Obl84thljAKKZKGwFyBZoZY2h7T61ncR/ds0TSQ==
ARC-Seal: i=1; s=2018; d=c0d3.blue; t=1555361440; a=rsa-sha256; cv=none; b=gBOFu1AC66Lm8zn8+LZtblrZgcFilSL5cG5svpHeONv/aUKMy+qMWNokHOG6mcChqitKMK QXSWbBv7YSubqPHTZcElhGFDrVo4axbBMqo+yBzWsasQ9ME2uaOtRSSxlx8cFFrloHBSTP 0OCu7ookgMsRSzgTdaVkrzQ2BhAMeHTSFxRyE0K0iP2i4PmDIEjUbwCggIUQJsAUqq8yU/ Y60nGe0KbqoSwBB3jxqqlo7Cxji1NBGUiagNm99Xm0ZOWbWFlDOtTzkibe4iVYnLGY2UqT RPsN0waa48B5YfYufdh5xrCG401seizuXS8/SD7QO0dsUENsYAAGszcbC8lvtQ==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Authentication-Results: ORIGINATING; auth=pass smtp.auth=linus.luessing@c0d3.blue smtp.mailfrom=linus.luessing@c0d3.blue
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/82UoQocXQ9BTYAGH_BLBRY8H02c>
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 20:50:46 -0000

Hi Mal,

Thanks for the capture. That looks good indeed, tcpdump or
wireshark do not complain about the format of the query either.

I tested this with a veth pair and isolated network namespace on
Linux and used tcpreplay to replay your IGMP query:

Setup:
$ ip netns add testnet
$ ip link add veth0 type veth peer name veth1
$ ip link set netns testnet dev veth1
$ ip link set up dev veth0
$ ip netns exec testnet ip link set up dev veth1
$ ip netns exec testnet ip a a 192.168.47.2/24 dev veth1

socat, to have a multicast listener for 234.81.130:
$ ip netns exec testnet socat UDP4-RECVFROM:6666,ip-add-membership=234.81.130.133:192.168.47.2 -

tcpreplay:
A) $ tcpreplay-edit --srcipmap=0.0.0.0/0:192.168.47.1 --fixcsum -i veth0 ./mal-h-query.pcap
B) $ tcpreplay-edit --srcipmap=0.0.0.0/0:0.0.0.0 --fixcsum -i veth0 ./mal-h-query.pcap


On my laptop, running a 4.19.16 kernel provided by Debian variant
A), which rewrites the source address to 192.168.47.1, works, I
get a report back. While variant B), which keeps the 0.0.0.0
source address, does not and reproduces the issue you described.


Then I built a 5.1-rc5 kernel with some extra debug output - and
there both variants A) and B) worked...

---
$ ip netns exec testnet tcpdump -e -v -l -n -i veth1 igmp
tcpdump: listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes
22:47:02.395743 00:16:fa:db:99:65 > 01:00:5e:51:82:85, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 36, options (RA))
    0.0.0.0 > 234.81.130.133: igmp query v3 [max resp time 0.1s] [gaddr 234.81.130.133]
22:47:02.480801 9a:81:3e:46:f6:ef > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 234.81.130.133 is_ex, 0 source(s)]
22:47:09.740288 00:16:fa:db:99:65 > 01:00:5e:51:82:85, ethertype IPv4 (0x0800), length 60: (tos 0xc0, ttl 1, id 0, offset 0, flags [none], proto IGMP (2), length 36, options (RA))
    192.168.47.1 > 234.81.130.133: igmp query v3 [max resp time 0.1s] [gaddr 234.81.130.133]
22:47:09.809405 9a:81:3e:46:f6:ef > 01:00:5e:00:00:16, ethertype IPv4 (0x0800), length 54: (tos 0xc0, ttl 1, id 0, offset 0, flags [DF], proto IGMP (2), length 40, options (RA))
    192.168.47.2 > 224.0.0.22: igmp v3 report, 1 group record(s) [gaddr 234.81.130.133 is_ex, 0 source(s)]
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
---

Could you maybe check whether a 5.1-rc5 kernel makes a difference for
you, too? This is a bit strange because 4.19.16 and 5.1-rc5 are not
that far apart. I did not expect that.

Regards, Linus


On Mon, Apr 15, 2019 at 08:12:28AM +0000, mal.hubert@bt.com wrote:
> 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