]> CyberLeo.Net >> Repos - FreeBSD/FreeBSD.git/commit
In the same way fix the problem described in r291578 for IGMPv3.
authorAndrey V. Elsukov <ae@FreeBSD.org>
Tue, 1 Dec 2015 11:24:30 +0000 (11:24 +0000)
committerAndrey V. Elsukov <ae@FreeBSD.org>
Tue, 1 Dec 2015 11:24:30 +0000 (11:24 +0000)
commitb4e63e2d15e9aea3da2537e2060041fd21a1e4cb
tree4dee3bc4950d219da7cf0e75d916c9efbfa632e5
parent9f8b8e793bfa387a7104be00c7ff1462a72aa6d6
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