Basic question on OID_GEN_CURRENT_PACKET_FILTER andOID_802_3_MULTI

Based on my current understanding, more than one protocol driver can bind to
a given miniport driver. However the packet filter is a "global" attribute of
the miniport driver, "global" in the sense that it is not a per protocol
attribute. The miniport driver has no notion of a protocol driver. Please
correct me if any of this is wrong.

1. Assuming this is all correct, what happens when protocol driver A sends
down a set on OID_GEN_CURRENT_PACKET_FILTER with a value of 0 (in effect
disabling all receives up from the miniport driver). Will this not impact say
another protocol driver B also bound to the same miniport but which
previously did set a non-zero packet filter i.e. B could suddenly and
unexpectedly stop receiving packet indications?

2. Another possibly related question is regarding OID_802_3_MULTICAST_LIST.
Different protocol drivers can set different multicast lists. Is the correct
behavior for the miniport to create a union out of all these various lists?
If so, isn't it possible for protocol A to receive a multicast packet even
though the multicast address in that packet is one A never set but B did?

3. When a packet is indicated up from the miniport, who decides which of the
bound protocols get the packet (I am guessing only one would get it because
that protocol has to return the packet back using the ReturnPacket entry
point)?

I think I am missing something basic here :(

4. Lastly, what does a protocol driver which has set a 0 packet filter in a
miniport driver do when it wrongly gets a receive packet indication from the
miniport OR to be more general gets a packet indication inconsistent with the
packet filter and the multicast address list it (protocol) previously set in
the miniport? If this happened when say the protocol was closing the adapter
(ProtocolUnbindAdapter), could it cause the Unbind to stall and/or have other
undesired consequences?

Thanks.
.

Relevant Pages

  • Packet Origin?
    ... I need to determine, in my protocol driver, if I have received a packet ... from the Win Stack or from my Miniport driver. ...
    (microsoft.public.development.device.drivers)
  • Re: Problem with the NDIS MUX IM driver (decapsulation not working)
    ... If the higher-level protocol and the lower-level miniport have enabled some TCP task offload contract, then the decapsulated packet you are indicating may not provide the necessary task offload information. ... then temporarily disabling the NDIS task offload features of the adapter using the adapter's NCPA advanced property tab should make the behavior "better". ... I slap on my own ethernet header infront of the real ...
    (microsoft.public.development.device.drivers)
  • Re: Serial port read latency (SERIOUS - NEED HELP FAST!)
    ... In regular Windows XP, expecting a 5ms interval would normally encounter geers and cat-calls from the news group. ... Is the 5ms "window" the only termination, or are you using a protocol that defines end of text or message? ... ReadFile will complete when there is 5 ms interval between received bytes. ... > The protocol requires our embedded device to respond to a packet> within ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Sniffer Cant see cluster traffic
    ... > protocol and cluster specific multicast MAC address, ... > node specific source MAC address. ... > is a multi-cast packet or a directed packet. ... Yep and that is solely at the ethernet packet level. ...
    (comp.os.vms)
  • Re: Help Interpreting data from Wireshark
    ... What concerns me is that the packet seemed to have a source address of 192.168.1.1 but later in the packet you see the dest as 84.160.95.226 ... Protocol Info ... DENVER.local ICMP Destination unreachable (Port unreachable) ... Fragment offset: 0 ...
    (comp.os.linux.security)