Rick Jones wrote:

Steve Chen wrote:

quoted

Multicast packet reassembly can fail

When multicast connections with multiple fragments are received by the 
same
node from more than one Ethernet ports, race condition between fragments
from each Ethernet port can cause fragment reassembly to fail leading to
packet drop.  This is because packets from each Ethernet port appears 
identical
to the the code that reassembles the Ethernet packet.

The solution is evaluate the Ethernet interface number in addition to 
all other
parameters so that every packet can be uniquely identified.  The existing
iif field in struct ipq is now used to generate the hash key, and iif 
is also
used for comparison in case of hash collision.

Please note that q->saddr ^ (q->iif << 5) is now being passed into
ipqhashfn to generate the hash key.  This is borrowed from the routing
code.

Signed-off-by: Steve Chen <redacted>
Signed-off-by: Mark Huth <redacted>

It has been hours since my last good Emily Litella moment so I'll ask - 
isn't the combination of source and dest addr, protocol, IP ID and 
fragment offset supposed to take care of this?  How does the ingress 
interface have anything to do with it?

rick jones

The problem we've seen arises only when there are multiple interfaces 
each receiving the same multicast packets.  In that case there are 
multiple packets with the same key.  Steve was able to track down a 
packet loss due to re-assembly failure under certain arrival order 
conditions.

The proposed fix eliminated the packet loss in this case.  There might 
be a different problem in the re-assembly code that we have masked by 
separating the packets into streams from each interface.  Now that you 
mention it, the re-assembly code should be robust in the face of some 
duplicated and mis-ordered packets.  We can look more closely at that code.

Mark Huth