>> the problem as i understood it was that a packet with a unicast
>> hardware address (not of my machine) but a broadcast ip address (no,
>> not normal, but certainly manufacturable, and certainly matching me)
>> will (a) be picked up by the card, (b) passed up to the upper layers
>> and (c) responded to
>
>The driver must do the appropriate checks that (b) doesn't
>happen. By checking some bit of the receive status if the
>card is a more intelligent one, or by bcmp()ing the ethernet
>header itself with conventional chips.
>I'm not voting for removing this check (which is done correctly
>in most drivers afais) - I'm just telling that the check
>is not driver independant and therefore shouldn't be done
>in ether_input().

if the card can do it, that's fine.  i just didn't expect the card to
have knowledge of ip addressing.  i just think that if some drivers do
it and some don't, that's not a good thing.  it means that your
network behavior is network card/driver dependant.  oxymoronic,
perhaps.

basically it comes down to promiscuous mode, and the fact that it
shouldn't alter a machine's behavior, except perhaps as a result of
the additional packet processing.

-- 
|-----< "CODE WARRIOR" >-----|
codewarrior@daemon.org             * "ah!  i see you have the internet
twofsonet@graffiti.com (Andrew Brown)                that goes *ping*!"
andrew@crossbar.com       * "information is power -- share the wealth."