Re: xennet input processing and mac filtering

[Greg Troxel <gdt%lexort.com@localhost>]

mlelstv%serpens.de@localhost (Michael van Elst) writes:

> ether_input did (and still does) check if the packet is neither
> multi-/broadcast nor for its own address and then marks the packets
> as M_PROMISC.
>
>                 if ((m->m_flags & (M_BCAST|M_MCAST)) == 0 &&
>                     (ifp->if_flags & IFF_PROMISC) != 0 &&
>                     memcmp(LLADDR(ifp->if_sadl), eh->ether_dhost,
>                            ETHER_ADDR_LEN) != 0) {
>                         m->m_flags |= M_PROMISC;
>                 }
>
> If M_PROMISC is set, the packet filter is skipped (?) and if it isn't
> consumed by agr(4), vlan(4), carp(4) or pppoe(4), then the packet
> is dropped later.
>
> But the check above only takes place when the interface is
> in promiscous mode. Without promiscous mode, the code assumes
> that all packets are actually for the machine.

That makes sense: there's a (not really well documented, perhaps) rule
that interfaces must not inject non-matching unicast packets unless
IFF_PROMISC.  Most drivers ensure this by hardware filtering, but xennet
does not.

I see two possible fixes:

  in xennet, set IFF_PROMISC because the required mac filtering does not
  happen

  in xennet, implement the filter that would been done in hardware,
  basically in the receive path

    if ( not IFF_PROMISC and not (dst-ether matches ours) )
      drop packet


To see if this would fix the issue, someone could run tcpdump on the
machine that responds when it shouldn't (after clearing the bridge
cache).