none
How to detect if network interface is part of ethernet bridge ? RRS feed

  • Question

  • Hello,

    in previous Win version I used user-mode detection of bridged network interfaces with enumerating network components of class GUID_DEVCLASS_NETTRANS and comparing InfId with string "ms_bridge". Thus I retrieved GUID of bridged network interface.

    Due to changes in last Win versions this way of detection is not possible now.

    How to detect if network interface is part of ethernet bridge in user-mode and in kernel-mode ndis lightweight filter 6.1 ?

    In kernel mode I looked on struct NDIS_FILTER_ATTACH_PARAMETERS but cannot not find any flag saying that below interface is bridged. In user-mode I looked on IP helper API functions enumerating adapters but also no info about ethernet bridge.

    Wednesday, March 6, 2019 9:33 AM

Answers

  • There's not a platform feature that detects bridging in general.  A 3rd party can write a driver that bridges network interfaces, and Windows wouldn't even know that that's what's going on; Windows would just see some IM driver doing something opaque.  IM drivers don't have to explain to Windows that they're doing bridging, switching, fault-tolerance, or whatever other thing.  So in the most general sense, you can't detect all sorts of bridging.

    Some versions of Windows include a built-in driver that can be used to create bridges.  You can detect specifically that built-in driver.  But actually, there are two major versions of that driver, and so you'll likely have to detect both.  (Future versions of Windows may implement bridging using different drivers; we don't guarantee that the built-in Bridge driver will never change.)

    Prior to Windows 8, the built-in bridge was an IM driver, whose protocol edge was named ms_bridge.  As of Windows 8 through current versions of Windows 10, the built-in bridge is a LWF driver, also named ms_bridge, collaborating with a generic utility IM driver named ms_implat.

    To detect the older protocol driver, you enumerate bindings over a physical NIC, and look for an enabled binding where the top component is named "ms_bridge."  That looks roughly like:

    bool IsBridged_Win7(INetCfgComponent *comp)
    {
        INetCfgComponent *bridge = netcfg->FindComponent("ms_bridge");
        INetCfgComponentBindings *bindings = comp->QI<INetCfgComponentBindings>();
        return bindings->IsBoundTo(bridge);
    }

    To detect the newer LWF driver, it's trickier, since the binding over the NIC would be to the generic IM platform.  Knowing that a NIC is bound to the generic IM platform tells you that it's being used for some fancy thing, but it doesn't tell you whether it's a bridge or an LBFO team or something more exotic.  The way to distinguish exactly which flavor of ms_implat you have is to look at which LWF driver is bound to the *virtual miniport* above the IM driver.

    This is two steps then.

    1. Given a physical NIC, you first want to determine which virtual NIC is layered over it.

    2. Given a virtual NIC, you want to determine whether ms_bridge is bound to it.

    To get the first part, look through the interface stack table (GetIfStackTable).  Search the stack table for any entry where the lower is the IfIndex of the physical NIC.  For any such entry (there will probably be a few), check if that entry's upper IfIndex is the IfIndex for a virtual miniport with component ID "COMPOSITEBUS\MS_IMPLAT_MP".  If you find such a thing, that means the physical NIC is a member of a bridge/LBFO/something-else-fancy.  If you don't find it, then you know the NIC isn't part of the bridge that comes with Windows 8 / Windows 10.

    To get the second part, just use the same INetCfg code above on the *virtual* NIC's component.  If the ms_bridge component is bound to the virtual NIC, then that virtual NIC is doing bridging.  Otherwise, it's doing something else (like LBFO).

    I realize that this isn't the easiest set of instructions to work with -- we don't currently have APIs for managing the built-in Bridge.  Adding such an API has been an occasional feature request, but we haven't heard it often enough to warrant the expense of doing the feature.  If you have a business relationship with Microsoft, let your Microsoft contact know that you'd like a Bridge API, and we'll adjust the priority of our backlog item accordingly.

    Thursday, March 7, 2019 12:41 AM