locked
Promiscuous mode and other questions RRS feed

  • Question

  • I'm trying to figure out the best way to "act like Wireshark" on a multi-NIC system.  By that I mean, I need to selectively monitor multiple NICs on a single system and see every packet, whether destined for the NIC or not, sent on the wire.  What I am not sure about is if WFP is the appropriate method for this or if I will need to do a NDIS LWF (or protocol?).  My environment is Win7.

    So a few questions just for my own understanding.  What is the difference between setting a filter condition to FWPM_CONDITION_ALE_PROMISCUOUS_MODE and just setting 0 (NULL) conditions?  Does FWPM_CONDITION_ALE_PROMISCUOUS_MODE actually put the NIC into promiscuous mode so nothing is discarded where as 0 conditions just applies to packets addressed to the system?

    Would the code below be what is required to set the conditions to monitor 2 interfaces and receive everything those two interfaces receive?

    FWPM_FILTER_CONDITION0 filterConditions[3] = {0};
    NET_LUID nid1;
    NET_LUID nid2;

    ...
    nid1 = GetLUID(interface1);
    nid2 = GetLUID(interface2);
    ...

    filterConditions[0].fieldKey = FWPM_CONDITION_IP_LOCAL_INTERFACE;
    filterConditions[0].matchType = FWP_MATCH_EQUAL;
    filterConditions[0].conditionValue.type = FWP_UINT64;
    filterConditions[0].conditionValue.uint64 = &nid1.Value;

    filterConditions[1].fieldKey = FWPM_CONDITION_IP_LOCAL_INTERFACE;
    filterConditions[1].matchType = FWP_MATCH_EQUAL;
    filterConditions[1].conditionValue.type = FWP_UINT64;
    filterConditions[1].conditionValue.uint64 = &nid2.Value;

    filterConditions[2].fieldKey              = FWPM_CONDITION_ALE_PROMISCUOUS_MODE;
    filterConditions[2].conditionValue.type   = FWP_UINT32;
    filterConditions[2].conditionValue.uint32 = SIO_RCVALL;

    Another questions I have is why MSFT removed the MAC filtering capabilities from Win7?  There's a PPT floating out on the net that talks about WFP and the ability to do MAC filter (circa 2009-ish) but I guess that is before MSFT removed that functionality.  So I realize that it is not officially supported, but it appears that on inbound paths, NdisRetreatNetBufferDataStart by 14 bytes puts you at the Ethernet frame header.  Can someone explain why that will not always be the case?  Has that bit of memory been released by the time the ClassifyFn is called and I've just been lucky that it still contains valid data?  If it is not valid anymore, wouldn't NdisRetreatNetBufferDataStart simply fail?  Thanks in advance.

    Thursday, April 10, 2014 5:36 AM

Answers

  • In Windows Vista & Windows 7 you would need to use an NDIS LWF in order to see frames not destined for the local TCP/IP stack. In Windows 8+, you can use the FWPM_LAYER_{IN | OUT}BOUND_MAC_FRAME_NATIVE to achieve the same using WFP.

    WFP's MAC filtering was removed from Win7 late in the release due to some security and operational concerns.  The layers got properly added in Windows 8.

    The Ethernet header may or may not be there for inbound packets.  If the packet came off the wire, then the header is likely there (no guarantee).  Loopback traffic for example will not have the header.  Additionally packets that went through any of the stack's injection won't have it (I.e. IPsec secured packets) or injection done by anyone else (as the clones will not have the Ethernet header).  Besides the MAC frame isn't really relevant anymore once it's entered TCP/IP.  It's most relevant down in NDIS (which is where the MAC_FRAME layers sit).

    Setting no conditions means you would see all traffic, regardless of the incoming values for that traffic.  If you specify a condition, you are essentially filtering out only the traffic which matches those conditions.  Setting the above filter will let you see traffic @ the ALE layers on the interfaces you defined that have Raw sockets which are enabled for SIO_RCVALL.  Having a filter with the ALE_PROMISCUOUS_MODE condition, does nothing to the socket.  It's only a filtering mechanism.

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Thursday, April 10, 2014 10:57 PM
    Moderator