Problem receiving UDP broadcast packets.

[Heiko Wundram]

Am 21.04.2011 03:35, schrieb Dan Stromberg:
> I think tcpdump and tshark (was tethereal) will put the interface into
> promiscuous mode so it can see more traffic; on OSF/1 (Tru64), we had
> to do this manually for said programs to see all that was possible
> (barring the presence of a switch not repeating packets the way
> routers and hubs would).

It actually depends on the network adapter/card that's in use: many
modern cards (especially those in the lower price segment, i.e. Realtek)
don't (properly) implement "MAC"-filtering at the hardware level, and in
this case, there's no difference for the operating system between
promiscuous mode and non-promiscuous mode (because the card will forward
all packets that it sees coming in over the ethernet bus to the
operating system, which will then discard those at the ethernet level it
doesn't deem necessary to process at a higher level, for example because
the destination MAC is unicast, but not the cards own, so the
destination wasn't the system itself).

For pricier cards/chips, this filtering (which also includes restricting
the multicast-destinations that are forwarded to the operating system,
think IPv6-multicast which uses quite a range of multicast MAC addresses
for its neighbour discovery) is implemented at the hardware level, and
the ethernet adapter throws away uninteresting packets and doesn't
signal the operating system (think of the cost of interrupts you save;
on high throughput links, this makes perfect sense). Putting the card
into promiscuous mode basically disables this filtering, so that the
card will again forward all packets to the operating system.

This is why tcpdump for example puts the network adapter into
promiscuous mode, but normally (see above, depending on the network
adapter), that's not required because the operating system "sees all"
ethernet packets anyway.

-- 
--- Heiko.