> > > 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
