Re: MAC bridging and sniffing packets with specific Ethertype

From: Jeff Kelley [MS] (jeffkel_at_online.microsoft.com)
Date: 10/13/04 

Date: Wed, 13 Oct 2004 10:52:58 -0700

It sounds like you are on the right track. The bindings of the networking
drivers would look something like this (my apologies for ASCII art that may
not look pretty depending upon font):

                                   (your custom bridge management
application)
                                       |
              (TCPIP) NDISUIO
                     | |
                   MBRIDGE1 (miniport driver)
       ------- MBRIDGE (protocol driver)
       | | |
Adapter1 Adapter2 ... AdapterN

That is, the Ethernet adapters are bound to the Mbridge driver (which, since
Mbridge is a layered intermediate driver, consists of an NDIS protocol
driver at its lower edge and an NDIS miniport driver at its upper edge).
Mbridge handles the bridging of packets between the adapters. For packets
that are to be received locally (e.g. broadcast packets or those whose
destination MAC address is that of one of the Ethernet adapters), Mbridge
passes them up to the protocol drivers that are bound ot Mbridge's miniport
driver instance, MBRIDGE1. It passes all of them up, regardless of EthType
(except for one special EthType that MBRIDGE itself uses).

In this case, we have TCPIP and NDISUIO bound to MBRIDGE1 so they both
receive these packets. TCPIP will look at the EthType and process IP and
ARP. NDISUIO will look at the EthType and ignore any packets that do not
match its configured EthType. So, as you note you would configure this value
using IOCTL_NDISUIO_SET_ETHER_TYPE to your special EthType so that your
application would receive the special packets that it is interested in.

Your application can send whatever packets it wants via NDISUIO, they get
passed down as is to MBRIDGE and then to an Ethernet adapter. Note that the
application using NDISUIO is responsible for entire packet including the
Ethernet header, so it must fill in the destination and source MAC addresses
and the EthType.

Some sample code for receiving packets and filtering on EthType can be found
in the NDISUIO driver source code. In the Platform Builder tree you can look
at public\common\oak\drivers\ndisuio\recv.c. See the function
NdisuioReceivePacket. 

-- 
Jeff Kelley
Microsoft / Windows CE Networking
This posting is provided AS IS with no warranties, and confers no rights.
"Kamila" <camol@gazeta.pl> wrote in message
news:8077d64.0410130839.353cdbd6@posting.google.com...
> We are considering development of a simple bridge base on the Windows
> CE 4.2 or 5.0.
> We plan to use Mbridge.dll for this purpose. On one of the interfaces
> (802.3) additionally to the IP traffic, which will be bridged, there
> will traffic destined to the bridge interface card. The bridge will
> use this traffic to exchange with the device, directly connected to
> this interface, some configuration information. The proprietary
> protocol will be used for this purpose. This protocol is defined
> directly above Ethernet header (no IP header). We want to filter this
> traffic based on the Ethertype or SNAP header.
>
> It looks like that it is possible to write an application to receive
> and send Ethernet packet using NDISUIO protocol driver (ReadFile,
> WriteFile operations). There is an IOCTL_NDISUIO_SET_ETHER_TYPE
> operation allowing to set type of Ethernet packet to be filtered (by
> default it is 0x8001).
> If we change it, does it mean that application will receive only this
> type of Ethernet packets or the NDIS driver will filter these packets
> and won't allow receiving any other packets on this interface?
> Would it take any effect on the Mbridge? Will the Mbridge module
> receive packets with other Ethertypes from this interface?
> What about packets filtered by our application? Would they be sent to
> the Mbridge module as well? I found info in the msdn that for the
> simultaneous access for multiple application operations requiring
> packets replication within NDIS are not supported.  However in this
> case the Mbridge is not typical application acting in the user mode,
> it operates in the kernel mode. Does it matter in this case?
>
> If you could provide me with some example code to filter Ethernet
> packets with specific Ethertype field, it would be great!
>
> Maybe I am wrong approaching the problem in this way. Any advises?
>
> Thanks in advance for any help!
>
> Kamila Piechota

Relevant Pages

  • Re: [PATCH] EtherIP tunnel driver (RFC 3378)
    ... But this is the way the ipip driver does it. ... But my driver registers its devices as Ethernet (it has to, ... all EtherIP tunnel devices from the driver. ... beyond the scope of tunnel which transmits layer 2 packets. ...
    (Linux-Kernel)
  • Re: making ppp interface on motfcc END
    ... the FCC device of a MPC8260 and supports 100Mbps ethernet. ... make this a M2_ifType_ppp type interface. ... The driver is a generic END ... 2189 unicast packets received ...
    (comp.os.vxworks)
  • Re: Filter Hook
    ... the callback routine is been invoked at DISPATCH_LEVEL. ... If you really have to keep such a queue for the packets, then the IP filter driver is not suitable for your needs since you have to process all the packets in the callback routine without any wait actionand return it to the tcpip driver immediately when the callback routine returns. ... What IRQL are you running at when you crash, ...
    (microsoft.public.development.device.drivers)
  • Re: Degradation of TCP connection
    ... and running ifconfigon the target does indeed show ... the huge number of dropped Rx packets, ... RX stall (possibly due to mishandled RX overrun in the driver) ... RX interrupts have stopped firing ...
    (comp.os.vxworks)
  • Re: Degradation of TCP connection
    ... "Each of our boards will have an ethernet driver specific ... once you get a target into a failed state, ... when the VxWorks box stops ACKing packets sent from the Windows box. ...
    (comp.os.vxworks)