From b4e63e2d15e9aea3da2537e2060041fd21a1e4cb Mon Sep 17 00:00:00 2001 From: "Andrey V. Elsukov" Date: Tue, 1 Dec 2015 11:24:30 +0000 Subject: [PATCH] In the same way fix the problem described in r291578 for IGMPv3. In case when router has a lot of multicast groups, the reply can take several packets due to MTU limitation. Also we have a limit IGMP_MAX_RESPONSE_BURST == 4, that limits the number of packets we send in one shot. Then we recalculate the timer value and schedule the remaining packets for sending. The problem is that when we call igmp_v3_dispatch_general_query() to send remaining packets, we queue new reply in the same mbuf queue. And when number of packets is bigger than IGMP_MAX_RESPONSE_BURST, we get endless reply of IGMPv3 reports. To fix this, add the check for remaining packets in the queue. MFC after: 1 week Sponsored by: Yandex LLC --- sys/netinet/igmp.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/sys/netinet/igmp.c b/sys/netinet/igmp.c index 185f5c2b5a04..d83348c758ed 100644 --- a/sys/netinet/igmp.c +++ b/sys/netinet/igmp.c @@ -3334,6 +3334,15 @@ igmp_v3_dispatch_general_query(struct igmp_ifsoftc *igi) KASSERT(igi->igi_version == IGMP_VERSION_3, ("%s: called when version %d", __func__, igi->igi_version)); + /* + * Check that there are some packets queued. If so, send them first. + * For large number of groups the reply to general query can take + * many packets, we should finish sending them before starting of + * queuing the new reply. + */ + if (mbufq_len(&igi->igi_gq) != 0) + goto send; + ifp = igi->igi_ifp; IF_ADDR_RLOCK(ifp); @@ -3369,6 +3378,7 @@ igmp_v3_dispatch_general_query(struct igmp_ifsoftc *igi) } IF_ADDR_RUNLOCK(ifp); +send: loop = (igi->igi_flags & IGIF_LOOPBACK) ? 1 : 0; igmp_dispatch_queue(&igi->igi_gq, IGMP_MAX_RESPONSE_BURST, loop);