Allen,
It is not at all surprising that you are seeing all multicast packets on
your network despite the fact that your interface is not running
promiscuously nor enabled for multicast. The reason is that the least
significant bit of the most significant byte of the destination MAC
address indicates that the packet is a multicast or broadcast packet.
Most NICs probably use this as the only test for "broadcast" and forward
packets with this bit set to the host regardless of the remaining bits
in the destination MAC address.
In fact, ethernet switches broadcast the packet based on this single bit
and will only build a tree pruning multicast forwarding table if they
are running IGMP snooping.
A large network without IGMP snooping can see a lot of unnecessary
multicast traffic at each host.
I suspect that you could use a BPF socket to select packets for the
destination multcast mac address that you are interested in. See the man
pages and source code for tcpdump and pcap for more information. While
this won't keep the packets from entering the kernel, it will prevent
them from going to your user land process.
Thanks,
Jim
Allen Curtis wrote:
I am trying to understand the relationship of the netdevice ioctl()
commands and raw packet sockets.
Does "Promiscuous" do anything when reading from a raw packet
socket?
When I monitor for unique MAC addresses, I do not see any difference.
Does "Multicast" do anything when reading from a raw packet socket?
If I have not joined a multicast group, why am I getting the packets?
My original understanding was that the network traffic received by a
NIC would be filtered at the link level based on a source/Dest MAC
match and any registered link layer multicast address. UNLESS, the
interface is put into promiscuous mode. This is obviously not
the case.
The goal:
I have a video player on a network which has many multicast streams.
The video player needs to monitor the network traffic for multicast
packets with custom MAC destinations BUT I do not want to see all
network multicast traffic due to CPU load considerations.
If raw packets are not filtered at the link level, how can
this be done?
Thanks,
Allen
--
To unsubscribe from this list: send the line "unsubscribe
linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
For what its worth, most modern ethernet MAC hardware has some sort of
capability to do filtering of received multicast packets. Usually
there's a table of bits in the hardware someplace that you can set via
software. When the hardware receives a multicast packet, it does a hash
on the destination MAC address and generates from that an index into the
table of bits. If the indexed bit is set, the packet gets DMA'ed into a
receive descriptor so that the software can see it, otherwise it gets
dropped and is invisible to software.
The software has to further qualify that the destination MAC address is
one of the one's its interested in since there is going to be a
many-to-one mapping between MAC addresses and the indexes they hash to,
but doing this you can exclude the singlecast and most of the multicast
traffic that you aren't interested in in the hardware and not consume
CPU cycles doing so. That is likely going to be a better solution than
putting the interface into promiscuous mode where the hardware will
attempt to do a DMA receive operation on every packet that goes by on
the wire.
Jeff Haran
Hello Jeff,
I guess my original message was not clear. I have NOT enabled
promiscuous mode and I an getting all of the packets. Further if neither
promiscuous or multicast is enabled, I still get multicast packets. Is
this correct? When you are using a PACKET, SOCK_RAW the packets are
delivered prior to the firewall or netfiltering. However I thought there
was filtering at the hardware level which I am not seeing.
Is my original understanding of operation correct or is the
implementation? When are the various ioctl flags mentioned needed? Are
they only needed for SOCK_DGRAM?
TIA
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
