On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <[email protected]> wrote: > > > > > History: The multicast stack currently supports decoding of IGMPv3 and > > > > MLDv2 exponential timer field encodings, but lacks the corresponding > > > > encoding logic when generating multicast query packets. > > RFC 3376 says: > > 4.1.1. Max Resp Code > > The Max Resp Code field specifies the maximum time allowed before > sending a responding report. The actual time allowed, called the Max > Resp Time, is represented in units of 1/10 second and is derived from > the Max Resp Code as follows: Here I can give you some input. Default value is 10 seconds for which the protocol value sent on the wire will be 100. This means 100 * (1/10 second) = 10s. Similarly, setting just 14 seconds will cause issues. The protocol value transmitted on the wire is 140, which, when decoded as a linear value, results in 224. Similarly, values greater than 25.5 seconds cannot be represented directly in the 8-bit field.
> > Let me check i understand the issue. If the user configures a value > > 127, linux continues to use the linear encoding, but a peer decodes it > as a floating value. Yes, you are right and that is what it does till now. And the Kernel applies same to the QQIC field as well. > > 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the > reports earlier than required? No, it is not 64. This becomes (0x10 << 3) = 0x80 = 128 again. > > 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the > peer can send the reports much later than the 255 1/10 of a second > than userspace expected. Yes, you are right. But the calculation is incorrect; it becomes 0x7C00, which is 31744. > > What is useful here is, 'maximum time allowed'. The RFC does not > appear to say how to pick a value between 0 and the maximum time > allowed. Which gives us some flexibility. Yes. However, this can lead to excessively slow membership convergence, increased leave latency, and in some scenarios may cause multicast membership state to expire before reports are received. > > I think a much simpler fix for stable is to clamp the user space > request for setting the max response time to 127. That seems like a > one line patch. In mainline I encoded the value according to the RFC. We can clamp to 127 in stables, if we are not willing to take the entire series. This will force user to use value < 128. Also, please consider QQIC; a similar encoding issue persists. > > Andrew > On Fri, Jul 10, 2026 at 1:31 AM Andrew Lunn <[email protected]> wrote: > > > > > History: The multicast stack currently supports decoding of IGMPv3 and > > > > MLDv2 exponential timer field encodings, but lacks the corresponding > > > > encoding logic when generating multicast query packets. > > RFC 3376 says: > > 4.1.1. Max Resp Code > > The Max Resp Code field specifies the maximum time allowed before > sending a responding report. The actual time allowed, called the Max > Resp Time, is represented in units of 1/10 second and is derived from > the Max Resp Code as follows: > > If Max Resp Code < 128, Max Resp Time = Max Resp Code > > If Max Resp Code >= 128, Max Resp Code represents a floating-point > value as follows: > > 0 1 2 3 4 5 6 7 > +-+-+-+-+-+-+-+-+ > |1| exp | mant | > +-+-+-+-+-+-+-+-+ > > Max Resp Time = (mant | 0x10) << (exp + 3) > > Small values of Max Resp Time allow IGMPv3 routers to tune the "leave > latency" (the time between the moment the last host leaves a group > and the moment the routing protocol is notified that there are no > more members). Larger values, especially in the exponential range, > allow tuning of the burstiness of IGMP traffic on a network. > > Let me check i understand the issue. If the user configures a value > > 127, linux continues to use the linear encoding, but a peer decodes it > as a floating value. > > 128 linear is 0 | 0x10) << (0 + 3) = 0x40 = 64. So the peer sends the > reports earlier than required? > > 255 linear is (0xf | 0x10) << (7 + 3) = 0x1F0000 = 2031616. So the > peer can send the reports much later than the 255 1/10 of a second > than userspace expected. > > What is useful here is, 'maximum time allowed'. The RFC does not > appear to say how to pick a value between 0 and the maximum time > allowed. Which gives us some flexibility. > > I think a much simpler fix for stable is to clamp the user space > request for setting the max response time to 127. That seems like a > one line patch. > > Andrew >
