Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
164 Views

NIC in promiscuous mode isn't receiving unicast packets destined to another machine

Using 825xx END on an embedded system, after setting IFF_PROMISC within endM2Init and setting the correct bit within the receive control for UPE (verifying by logging the entire 32 bit register), I still cannot debug/log unicast packets destined for another machine. I'm using a netgear switch, and have port mirroring on. I have verified that this port mirroring is working because using a snooping application on a separate laptop connected to the mirrored port, I can sniff out the this arbitrary unicast packet.

Is there another step I need to take for my NIC to see unicast packets in promiscuous mode (where the destination MAC is not that machine)? From my understanding (relatively new to working with drivers), packets on the receiving handle are pulled into message blocks, and I'm debugging these received packets by simply iterating through the message block and logging the destination MAC and the source MAC as a preliminary check (bytes 0-5 for dest and 6-11 for source). My handler logs broadcast packets, multicast packets and unicast packets that are intended for it as the destination, but I haven't been able to sniff out unicast packets that are not destined for that machine. Can someone point out where my logic is flawed?

Thank you for your time! 

1 Reply
Highlighted
Beginner
87 Views

After changing the configuration and using NIC 0 instead of NIC 1, I was able to successfully sniff out arbitrary unicast packets destined for a third party. However, the question still remains as to why NIC 1 (gei1) stops receiving the third party unicast packets after the first message. Is this the expected behavior from the Intel side?

0 Kudos