[BUG] net: ipvlan: ambiguous external multicast frame is dropped

[Cheng Yongkang <teel4res@gmail.com>]

Hi all,

ipvlan_external_frame() classifies an ingress multicast frame as local
when its Ethernet source equals the shared ipvlan parent/slave MAC and
its L3 source is present in the port-wide address hash.  An external
sender can produce the same tuple.  The frame is then returned with
RX_HANDLER_PASS and is not queued to any L2 ipvlan slave.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1, with two ipvlan L2 slaves
and a veth peer acting as the external sender:

  external ARP broadcast, source MAC == ipvlan MAC,
  sender address configured on a slave:

    parent RX +1
    slave 0 RX +0
    slave 1 RX +0

  identical frame with a different sender MAC:

    parent RX +1
    slave 0 RX +1
    slave 1 RX +1

Packet-socket marker captures agreed with the RX counters.  The frame
is lost only when the ambiguous source tuple is used.

The macvlan sibling documents that source-MAC ambiguity cannot be
resolved and prefers delivery, accepting possible duplicates.  ipvlan
currently chooses the opposite behavior and can cause packet loss.
The same classifier also explains the duplicate direction in candidate
BR-015 when a reflected local frame has an address that is not in the
port hash.

The classifier should use an unambiguous local-origin indication or
make the ambiguity policy consistent with macvlan.  Candidate BR-016 is
canonical because packet loss is the more important symptom.

The self-checking reproducer and complete console log are available on
request.

This was found with a multi-agent workflow; the packet
delivery differential was reproduced in QEMU.

Thanks,
Cheng Yongkang