Re: xennet input processing and mac filtering

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello Greg.  I think the input checks work like this:

1.  If the ethernet card is configured for hardware filtering, then it's assumed the hardware
blocks any packets with destination MAC addresses which don't match the card's filters.
otherwise,  all input packets are passed to ether_input() for processing, since there are a
number of cases where it's perfectly reasonable for packets with destination MAC addresses to
enter the system and make it passed the ethernet driver itself.  CARP, vlans, bridge
configurations, MPLS, just to name a few.
Most drivers don't worry about these special cases, but just put the chips into promiscuous
mode and let the higher level processes take care of the floods.
In the case of xennent(4), I think the filtering is done at the backend, i.e. on the dom0 side,
but I'm not entirely certain of that.
A quick check with tcpdump on a domu machine running with xennet(4), while sending data to
another domu machine on the same bridge, shows the domu doesn't receive packets for the MAC
addresses it doesn't own.  That could either be because the bridge code blocks output to the
watching domu's virtual port or because the backend sender on the specific domu is blocking
such traffic.  I didn't look, but perhaps there is code in the xennet(4) driver  to tell the
backend which MAC addresses it should listen for.

-thanks
-Brian

On Aug 28,  8:34am, Greg Troxel wrote:
} Subject: xennet input processing and mac filtering
} Brian reported an odd problem on netbsd-users.  My take on the root
} cause is that a packet for domU A arrives on domU B's xennet, because
} dom0 P's bridge0 doesn't know where A's mac is yet.  That's normal and
} what would happen if these were physical computers with wires to a real
} switch.
} 
} Looking at (current, netbsd-10 same):
} 
}   src/sys/arch/xen/xen/if_xennet_xenbus.c
} 
} I can tell that it was written long ago and has had a bunch of
} structural changes applied over time.
} 
} I see that packets that arrive from the "ethernet chip" are injected
} directly:
} 
}   if_percpuq_enqueue(ifp->if_percpuq, m); # line 1056
} 
} I would expect this to lead to ether_input checking that the dst mac in
} the packet is our interface's mac, and dropping it if not.  I'd sort of
} expect this in the driver, not ether_input.  Looking at if_wm.c, I'm not
} seeing such a check.
} 
} So:
} 
}   Am I looking at the right xen driver?
} 
}   Where is the "dst mac is our mac" check?
} 
}   Is it missing for xennet?
} 
}   What else am I missing?
}   
>-- End of excerpt from Greg Troxel