public inbox for developer@lists.illumos.org (since 2011-08)
 help / color / mirror / Atom feed
From: "Bill Sommerfeld via illumos-developer" <developer@lists.illumos.org>
To: developer@lists.illumos.org
Subject: [developer] [REVIEW] 16620 MLD/IGMP can drop or misroute listener reports
Date: Sat, 2 Nov 2024 11:20:49 -0700	[thread overview]
Message-ID: <c5ea0c75-871c-4805-866e-c461350c4b2f@hamachi.org> (raw)

Issue: https://www.illumos.org/issues/16620
CR: https://code.illumos.org/c/illumos-gate/+/3556
Diff: 
https://code.illumos.org/~diff/e3c8a5d530f94d86271a1f0312df090406ff953d

When attempting to enable IGMP and MLD snooping on a couple switches
of mine I discovered a few bugs in how our stack responds to IGMP and
MLD queries; the common thread is mishandling of the second and
subsequent multicast groups on an interface.

IGMP (for IPv4) and MLD (for IPv6) are closely related protocols.
Hosts participating in multicast (which includes everything running
IPv6) must listen for and respond to multicast group membership
queries, typically sent by a router or switch on the network.  Layer-2
switches can "snoop" these messages to determine which ports need to
receive packets sent to each multicast group.

The bugs I fixed:

  1) ill_mcast_send_queued() sends one or more queued IGMP/MLD
responses using a single ip_xmit_attr_t.  It initializes several
fields in the ip_xmit_attr_t before walking the queue, but after every
transmit, it calls ixa_cleanup().  And ixa_cleanup() clears several of
the fields set before the loop - most notably ixa_ifindex, which sets
the output interface.  As a result, all but the first packet in a
burst are sent out the primary interface.

  2) When responding to a MLD v1 query, mld_query_in() loops over all
multicast groups on the interface, but breaks out of the loop after
queueing the first reply even if the query was a general wildcard
query.

  3) All IPv6 hosts are implicitly members of the link-local all-nodes
multicast group, ff02::1.  The MLD spec says that no MLD messages
should ever be sent regarding that group, but our MLDv1 implementation
could respond to a specific query for that group.









------------------------------------------
illumos: illumos-developer
Permalink: https://illumos.topicbox.com/groups/developer/T74ff5d23ef4771c3-Me50c84c2e42e7ad1a5b17609
Delivery options: https://illumos.topicbox.com/groups/developer/subscription

                 reply	other threads:[~2024-11-02 18:22 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c5ea0c75-871c-4805-866e-c461350c4b2f@hamachi.org \
    --to=developer@lists.illumos.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).