> From: Andrew Brown <atatat@atatdot.net>
> Date: 2000-01-19 13:27:14 -0800
> To: Matthias Drochner <M.Drochner@fz-juelich.de>
> Subject: Re: a remote user can check promiscuous mode
> Cc: Ignatios Souvatzis <is@jocelyn.rhein.de>,der Mouse
> <mouse@Rodents.Montreal.QC.CA>, tech-net@netbsd.org
> In-reply-to: <200001192039.VAA0000016530@zel459.zel.kfa-juelich.de>; 
> fromM.Drochner@fz-juelich.de on Wed, Jan 19, 2000 at 09:39:37PM +0100 
> X-Hi-To-All-My-Friends-In-Domestic-Surveillance: hi there, sports  
fans  :)
> X-Mailer: Mutt 1.0.1i
> Delivered-to: tech-net@netbsd.org
>
> >> 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

A question for clarification: Is the above a correct statement?   
Seems like what's discussed below doesn't relate to what's described  
above.  The above deals with a broadcast IP packet, which should  
properly be handled by the IP stack.  That it's delivered in a  
unicast ethernet frame is weird, but at least promiscuous mode in  
this case lets things happen correctly.  Or am I missing something?

> >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.

Thanks.

Regards,

Justin


--
Justin C. Walker, Curmudgeon-At-Large *
Institute for General Semantics       |
Manager, CoreOS Networking            | When crypto is outlawed,
Apple Computer, Inc.                  | Only outlaws will have crypto.
2 Infinite Loop                       |
Cupertino, CA 95014                   |
*-------------------------------------*-------------------------------*