Hi Devs,
If no PACKET_FILTER is set should Ndis Miniport driver drop all received packets ? or will this be handled by Ndis ?
Regards
Anandhi
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Depends. Better drop the packets yourself or NDIS Tester will fail
some tests.
On 14 Feb 2002 14:52:46 -0000, “Anandhi”
wrote:
>Hi Devs,=0A=0AIf no PACKET_FILTER is set should Ndis Miniport driver drop a=
>ll received packets ? or will this be handled by Ndis ?=0A=0ARegards=0AAnan=
>dhi=0A =0A
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi,
Thanx Stephan, I have another query in this line.
How should Ndis Wdm Lower edge drivers handle Packet filtering ?
In case of my driver, it emulates Ethernet to layers above.
My NIC driver will be receiving only protocol packets from the lower
driver,
Ethernet Header is added to these protocol packets by my Nic Miniport
driver.
Thus, my driver supports one & only DIRECTED mode.
In such a scenario how should packet filtering be handled?
I am looking at this issue from WHQL perspective also.
Regards
Anandhi
On 02/14/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
Depends. Better drop the packets yourself or NDIS Tester will fail
some tests.Stephan
On 14 Feb 2002 14:52:46 -0000, “Anandhi”
> wrote:
>
> >Hi Devs,=0A=0AIf no PACKET_FILTER is set should Ndis Miniport driver drop a=
> >ll received packets ? or will this be handled by Ndis ?=0A=0ARegards=0AAnan=
> >dhi=0A =0A
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
If you support only directed frames (ie. no broadcasts or multicasts),
then you already either receive “all” frames or “none”. So what’s the
problem here? If the packet filter has been set to not receive
directed frames, simply discard *all* frames.
Note: Multicast *and* broadcast frames have the I/G (Individual/Group)
bit set in the destination MAC address (broadcast are just special
multicasts). Thus, you can determine if a frame is a multicast by
simply checking the I/G bit. See the following NDIS “filter libary”
macros:
ETH_IS_MULTICAST()
ETH_IS_BROADCAST()
Background info: The I/G bit is *always* the first bit of a frame that
gets transmitted onto the medium (Ethernet, Token-Ring, FDDI,
whatever). Thus, the I/G bit is in the first byte (MSB) of the
destination MAC address and is 0x01 for Ethernet (but 0x80 for
Token-Ring).
On Sat, 16 Feb 2002 4:37:15, “Anandhi”
wrote:
>
>Hi,
>
>Thanx Stephan, I have another query in this line.
>
>How should Ndis Wdm Lower edge drivers handle Packet filtering ?
>
>In case of my driver, it emulates Ethernet to layers above.
>My NIC driver will be receiving only protocol packets from the lower
>driver,
>Ethernet Header is added to these protocol packets by my Nic Miniport
>driver.
>Thus, my driver supports one & only DIRECTED mode.
>In such a scenario how should packet filtering be handled?
>I am looking at this issue from WHQL perspective also.
>
>Regards
>Anandhi
>On 02/14/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
>> Depends. Better drop the packets yourself or NDIS Tester will fail
>> some tests.
>>
>> Stephan
>> —
>> On 14 Feb 2002 14:52:46 -0000, “Anandhi”
>> wrote:
>>
>> >Hi Devs,=0A=0AIf no PACKET_FILTER is set should Ndis Miniport driver drop a=
>> >ll received packets ? or will this be handled by Ndis ?=0A=0ARegards=0AAnan=
>> >dhi=0A =0A
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi Stephan,
On 02/20/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
If you support only directed frames (ie. no broadcasts or multicasts),
then you already either receive “all” frames or “none”. So what’s the
problem here?
The problem is in 2K & NT4 OS tries to set for the packetfilter of my
driver to 0x11 ( Which is NDIS_PACKET_TYPE_DIRECTED +
NDIS_PACKET_TYPE_MULTICAST + NDIS_PACKET_TYPE_BROADCAST )
Now if my driver supports only NDIS_PACKET_TYPE_DIRECTED, i will reject
this OID Set operation, because of which NO filter is getting set & the OS
doesn’t send any Send request from there on. So i was forced to modify my
driver to support all these packet types. Currently my driver claims to
support the following filter types
NDIS_PACKET_TYPE_DIRECTED + NDIS_PACKET_TYPE_MULTICAST +
NDIS_PACKET_TYPE_BROADCAST + NDIS_PACKET_TYPE_PROMISCUOUS +
NDIS_PACKET_TYPE_SOURCE_ROUTING
My driver at the receive edge will receive only IP Packets (mine is a WDM
Lower edge driver) to which i add a Ethernet Header & indicate it up. So
though above mentioned packet types are supported only Directed packets
will be indicated to Ndis.
With all this, i have another INTERESTING OBSERVATION with NdisTest Kit
The 1c_srecv test reports that: “Received 5 unexpected calls to
NdisIndicateReceive”
During this test i don’t indicate a single packet up, this was verified by
setting break point in my receive path.
So does this means Ndis is misbehaving ?!
Do Corect me if i am wrong.
Regards
Anandhi
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
There is no problem if you pretend to support filter bits you don’t
actually support. However, the respective tests (multicast etc.) will
probably fail.
The “unexpected NdisIndicateReceive()” messages that you see is
probably due to loopback in NDIS itself. Do you specify
NDIS_MAC_OPTION_NO_LOOPBACK?
On Wed, 20 Feb 2002 10:24:8, “Anandhi”
wrote:
>
>Hi Stephan,
>
>On 02/20/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
>> If you support only directed frames (ie. no broadcasts or multicasts),
>> then you already either receive “all” frames or “none”. So what’s the
>> problem here?
>
>The problem is in 2K & NT4 OS tries to set for the packetfilter of my
>driver to 0x11 ( Which is NDIS_PACKET_TYPE_DIRECTED +
>NDIS_PACKET_TYPE_MULTICAST + NDIS_PACKET_TYPE_BROADCAST )
>
>Now if my driver supports only NDIS_PACKET_TYPE_DIRECTED, i will reject
>this OID Set operation, because of which NO filter is getting set & the OS
>doesn’t send any Send request from there on. So i was forced to modify my
>driver to support all these packet types. Currently my driver claims to
>support the following filter types
>NDIS_PACKET_TYPE_DIRECTED + NDIS_PACKET_TYPE_MULTICAST +
>NDIS_PACKET_TYPE_BROADCAST + NDIS_PACKET_TYPE_PROMISCUOUS +
>NDIS_PACKET_TYPE_SOURCE_ROUTING
>
>My driver at the receive edge will receive only IP Packets (mine is a WDM
>Lower edge driver) to which i add a Ethernet Header & indicate it up. So
>though above mentioned packet types are supported only Directed packets
>will be indicated to Ndis.
>
>With all this, i have another INTERESTING OBSERVATION with NdisTest Kit
>The 1c_srecv test reports that: “Received 5 unexpected calls to
>NdisIndicateReceive”
>During this test i don’t indicate a single packet up, this was verified by
>setting break point in my receive path.
>So does this means Ndis is misbehaving ?!
>
>Do Corect me if i am wrong.
>
>Regards
>Anandhi
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hi Stephan,
On 02/20/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
There is no problem if you pretend to support filter bits you don’t
actually support. However, the respective tests (multicast etc.) will
probably fail.
Nop! none of the other test including multicast test fail with my driver.
The “unexpected NdisIndicateReceive()” messages that you see is
probably due to loopback in NDIS itself. Do you specify
NDIS_MAC_OPTION_NO_LOOPBACK?
Yup! i do specify the following MAC Options
NDIS_MAC_OPTION_NO_LOOPBACK + NDIS_MAC_OPTION_COPY_LOOKAHEAD_DATA +
NDIS_MAC_OPTION_RECEIVE_SERIALIZED + NDIS_MAC_OPTION_TRANSFERS_NOT_PEND
Do U mean to say i should NOT specify NDIS_MAC_OPTION_NO_LOOPBACK ?
But why ?
From the test result, it looks like either Ndis is doing some unnecessary
loopback or the NdisTest driver is reporting some valid indications as
Unexpected PacketIndications.
Regards
Anandhi
Stephan
On Wed, 20 Feb 2002 10:24:8, “Anandhi”
> wrote:
>
> >
> >Hi Stephan,
> >
> >On 02/20/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
> >> If you support only directed frames (ie. no broadcasts or multicasts),
> >> then you already either receive “all” frames or “none”. So what’s the
> >> problem here?
> >
> >The problem is in 2K & NT4 OS tries to set for the packetfilter of my
> >driver to 0x11 ( Which is NDIS_PACKET_TYPE_DIRECTED +
> >NDIS_PACKET_TYPE_MULTICAST + NDIS_PACKET_TYPE_BROADCAST )
> >
> >Now if my driver supports only NDIS_PACKET_TYPE_DIRECTED, i will reject
> >this OID Set operation, because of which NO filter is getting set & the OS
> >doesn’t send any Send request from there on. So i was forced to modify my
> >driver to support all these packet types. Currently my driver claims to
> >support the following filter types
> >NDIS_PACKET_TYPE_DIRECTED + NDIS_PACKET_TYPE_MULTICAST +
> >NDIS_PACKET_TYPE_BROADCAST + NDIS_PACKET_TYPE_PROMISCUOUS +
> >NDIS_PACKET_TYPE_SOURCE_ROUTING
> >
> >My driver at the receive edge will receive only IP Packets (mine is a WDM
> >Lower edge driver) to which i add a Ethernet Header & indicate it up. So
> >though above mentioned packet types are supported only Directed packets
> >will be indicated to Ndis.
> >
> >With all this, i have another INTERESTING OBSERVATION with NdisTest Kit
> >The 1c_srecv test reports that: “Received 5 unexpected calls to
> >NdisIndicateReceive”
> >During this test i don’t indicate a single packet up, this was verified by
> >setting break point in my receive path.
> >So does this means Ndis is misbehaving ?!
> >
> >Do Corect me if i am wrong.
> >
> >Regards
> >Anandhi
>
> —
> You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
Hmm, how can you pass a multicast test when you don’t support
multicasts?
Most drivers, except Token-Ring drivers, usually set
NDIS_MAC_OPTION_NO_LOOPBACK simply because most media like Ethernet do
not allow for external loopback of own send packets.
Anyway, I don’t know why NDIS Tester complains about unexpected
receive packets. Connect a debugger or run DebugView or DebugMon and
see if there are any hints from NDIS Tester there.
On Wed, 20 Feb 2002 23:39:22, “Anandhi”
wrote:
>
>Hi Stephan,
>
>On 02/20/02, “xxxxx@hotmail.com (Stephan Wolf)” wrote:
>> There is no problem if you pretend to support filter bits you don’t
>> actually support. However, the respective tests (multicast etc.) will
>> probably fail.
>
>Nop! none of the other test including multicast test fail with my driver.
>
>>
>> The “unexpected NdisIndicateReceive()” messages that you see is
>> probably due to loopback in NDIS itself. Do you specify
>> NDIS_MAC_OPTION_NO_LOOPBACK?
>
>Yup! i do specify the following MAC Options
>NDIS_MAC_OPTION_NO_LOOPBACK + NDIS_MAC_OPTION_COPY_LOOKAHEAD_DATA +
>NDIS_MAC_OPTION_RECEIVE_SERIALIZED + NDIS_MAC_OPTION_TRANSFERS_NOT_PEND
>
>Do U mean to say i should NOT specify NDIS_MAC_OPTION_NO_LOOPBACK ?
>But why ?
>From the test result, it looks like either Ndis is doing some unnecessary
>loopback or the NdisTest driver is reporting some valid indications as
>Unexpected PacketIndications.
>
>Regards
>Anandhi
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> Hmm, how can you pass a multicast test when you don’t support
multicasts?
In NdisTest Kit there is no test which can simulate Packet reception, esp from the multicast addr that get set. The 1c_srecv test tests for looped back receive. & All this is done at Ndis Level itself.
That explains how the multicast tests pass.
Most drivers, except Token-Ring drivers, usually set
NDIS_MAC_OPTION_NO_LOOPBACK simply because most media like Ethernet do
not allow for external loopback of own send packets.Anyway, I don’t know why NDIS Tester complains about unexpected
receive packets. Connect a debugger or run DebugView or DebugMon and
see if there are any hints from NDIS Tester there.
Nop i cudn’t get any useful info from the NDIS Tester 
God help me!
Best regards
Anandhi
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com