NDIS 6.x ethernet bridge driver

Question

I was wondering what would be the best choice and way to build an ethernet bridge using NDIS 6.x. Where should I start and which one should I use for this, Miniport, IM, protocol or filter driver?

Tried to customize the protocol driver sample available in WDK and successfully got attached to the ethernet adapters. What next?

Any help is much appreciated.

Using Windows 7x64

Answer 1

Let's look at the NDIS driver types that are available: miniports, lightweight filters, and protocols.

An NDIS miniport alone cannot solve this problem, since miniports receive packets from the host OS. You want something that receives packets from the network.

An NDIS lightweight filter could solve this problem, but the solution would be a little klunky. You'd have to manually synchronize between two unrelated miniport stacks. This is harder than it seems; others who have tried this before have gotten this wrong on the first few attempts.

An NDIS protocol driver is the best way to solve this problem. A protocol driver is designed to attach to multiple miniports, and the protocol driver has the ability to route packets from one miniport stack to the other.

But protocol drivers are missing one feature. If you just write a protocol driver, then this is how the drivers line up:

[TCPIP]  [YourProtocol]
    | \  / |
    |  \/  |
    |  /\  |
    | /  \ |
 [NIC0] [NIC1]

That is, the host's TCPIP stack sees both NICs as separate NICs. (@Aczire, you indicated in a previous question that this is ok for you. But for expository purposes, here's the rest of the story.)

NDIS allows you to solve this sort of problem with a MUX-IM driver. An IM driver is basically just a protocol glued onto another miniport. This allows you to control exactly what the host OS sees:

    [TCPIP]
       |
       |
       |
       |
 [YourMiniport]
 [YourProtocol]
    |      |
    |      |
    |      |
    |      |
 [NIC0] [NIC1]

With this architecture, you can trick the host OS into thinking that these two networks are the same. (For example, user-facing GUIs will show a single network adapter, instead of two.) However, IM drivers come at a substantial complexity cost: they're hard to write, and even harder to get right. I do not recommend that you tackle an IM driver unless you have substantial experience and time.

Answer 2

Now that you've got a protocol driver: what next?

1. Make sure that your protocol binds to both adapters that you care about.
2. Set a promiscuous packet filter on both adapters (you want to receive ALL traffic, even traffic not destined for localhost)
3. When packets are received on one interface, clone the NBL and send the clone on the other interface. Make sure you read up on cloning rules.

You should detect cabling cycles, so you don't flood the network.

You should read (ok, skim) through the IEEE standards for 802, 802.1, and 802.3, since they have some specific rules on what bridges should do. For example, you may want to special-case the destination MAC address 01-80-C2-00-00-00.