]> CyberLeo.Net >> Repos - FreeBSD/stable/10.git/commit
MFC r291579:
authorae <ae@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Tue, 8 Dec 2015 07:43:12 +0000 (07:43 +0000)
committerae <ae@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Tue, 8 Dec 2015 07:43:12 +0000 (07:43 +0000)
commitf9ee45c4273805d814edbbac23fb997db94d7338
tree8912ec092feb2d8abc81c3f05302717e8c144512
parentac64983c352cecd3cf5228964f9b3c276af60f45
MFC r291579:
  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.

git-svn-id: svn://svn.freebsd.org/base/stable/10@291990 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/netinet/igmp.c