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

i think so, yeah.

>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 original question was whether or not a remote user could detect a
netbsd system with a nic in promiscuous mode.

the method of detection involves sending (from another machine on the
same segment, of course) a packet that has a unicast destination
hardware address (eg 0:0:0:c0:ff:ee) but has a broadcast destination
ip address (or a unicast ip address) of the machine you wish to check.

clearly with a unicast destination addres of no machine on a segment,
no machine should see it, but a machine in promiscuous mode will.

please...correct me if i'm wrong here, but as i understand things, it
goes like this:

 (1) the card (in promiscuous mode) receives the packet and the driver
     pulls it off the card

 (2) the driver (maybe) checks the unicast address to see if it
     matches the receiving interface and passes the packet up to
     ether_input() (and also to bpf_mtap())

 (3) ether_input() looks over the packet, sets the mcast or bcast
     flags, and passes it to the appropriate upper layer (eg, ip,
     appletalk, arp, etc)

 (4) ip_input() looks at the destination ip address, and decides
     whether to drop the packet, forward it, respond to it, or pass it
     up to tcp or udp (or icmp...etc)

what i'm suggesting is that at step 3 in the above process, the
generic ether_input() routine should verify that the destination
hardware address indeed matches the received interface's hardware
address, if the packet is not multicast or broadcast (or anycast).  in
this manner, *all* ethernet drivers can benefit from the security that
it provides.  not just those that need the check because they have
bugs (like the 3c589d, which i simply can't get to non-promiscuous
mode, so leaving forwarding turned on is a *big* mistake if i don't
actually need it (as i do at home)).

i presume, also that at step 4, the ip_input() routine checks that the
mcast or bcast flags actually agree with the destination ip address,
but i haven't read the code very much lately, so i can't say for sure.

so...

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

i think we are on the same track.  i'm just a new evangelist.  :)

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