On Fri, Jul 10, 2026 at 02:40:39PM +0530, Ujjal Roy wrote:
> 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.
Thanks for correcting my maths.
> > 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.
It does not force the users to use a value < 128. You would need to
return EINVAL for that, which i'm not proposing. Returning an error
could break user space.
By clamping to 127, we don't break user space, but we do avoid the
kernel bug, and at least to my superficial reading of the RFC, we are
"language lawyer" compliant with the RFC.
Andrew
