ClientEventChainedReceive problem in TDI drivers  
Author Message
andreadambra





PostPosted: Mon Oct 25 13:49:05 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers

Hi,

I am working on a TDI Filter Driver. Most of the stuff in driver is working
fine as of now, but getting in some problems.

I want to know in what situations ClientEventReceive and
ClientEventChainedReceive are being called by the Transport. My driver is
handling ClientEventReceive without any problem but on some machines
ClientEventChainedReceive is being called and that's whem driver is getting
screwed up. Somehow i am not able to handle
ClientEventChainedReceiveproperly in my driver. Partialy the reason is also
I am not able to reproduce that event in any of my machines. I saw this
happening at some remote machines.

I want to know:

1. Is it possible to reproduce this event in local machines which are always
giving me ClientEventReceive.
2. What does this ClientEventChainedReceive depends on ??? Is it a card
dependent issue (Since when the person sitting on remote machines replaced
his broacom card with IO cards, he started getting ClientEventReceive. Don't
know why this is happening ???? Locally i am using different cards from
National Semiconductor, Sis etc. and it is always ClientEventReceive.

3. I am getting this event in both XP and 2K machines, There should not be
the OS dependency. If that is the case thn how this type of things are
happening in Windows 98 ???

Looking forward to your reply.

Thanks and regards,
Puneet

Windows OS37  
 
 
DaveCattley





PostPosted: Mon Oct 25 13:49:05 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers Puneet,

The 'chained' variant of receive events on NT show up typically when the
underlying NIC indicates entire packets using NdisMIndicateReceivePackets().
In this case, the ProtocolRecievePackets() handler is typically called by
NDIS and the protocol has asyncronous access to the entire packet (MDL chain).

Basically, you need to get yourself some NICs that use that mechanism
instead of indicating each packet via NdisMXxxIndicateReceive().

Your filter, however, cannot depend on one behavior or the other. The
transport (I assume TCPIP.SYS in your case), the NIC, and the TDI client
(AFD, NBT, TPTDI.SYS, HTTP.SYS, etc.) all play a roll in deciding what type
of receive callback will occur.

I word of caution: The MDL chain or NDIS_BUFFER in the event callback must
be treated very carefully. A TDI filter can intercept the Client ReceiveXXX
event easily enough but cannot (easily, anyway) intercept the call from the
TDI client when it returns the buffer chain. This creates the situation that
your filter must either process the data before calling the original client
event handler or copy the data before calling the original client event
handler. Failing to do this can result in some rather strange bugs if the
TDI client happens to free the buffer before the filter processes the data.

Best of luck,
Dave Cattley
Systems Software Development





> Hi,
>
> I am working on a TDI Filter Driver. Most of the stuff in driver is working
> fine as of now, but getting in some problems.
>
> I want to know in what situations ClientEventReceive and
> ClientEventChainedReceive are being called by the Transport. My driver is
> handling ClientEventReceive without any problem but on some machines
> ClientEventChainedReceive is being called and that's whem driver is getting
> screwed up. Somehow i am not able to handle
> ClientEventChainedReceiveproperly in my driver. Partialy the reason is also
> I am not able to reproduce that event in any of my machines. I saw this
> happening at some remote machines.
>
> I want to know:
>
> 1. Is it possible to reproduce this event in local machines which are always
> giving me ClientEventReceive.
> 2. What does this ClientEventChainedReceive depends on ??? Is it a card
> dependent issue (Since when the person sitting on remote machines replaced
> his broacom card with IO cards, he started getting ClientEventReceive. Don't
> know why this is happening ???? Locally i am using different cards from
> National Semiconductor, Sis etc. and it is always ClientEventReceive.
>
> 3. I am getting this event in both XP and 2K machines, There should not be
> the OS dependency. If that is the case thn how this type of things are
> happening in Windows 98 ???
>
> Looking forward to your reply.
>
> Thanks and regards,
> Puneet
>
>
>
 
 
Maxim





PostPosted: Wed Oct 27 12:39:50 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers > I word of caution: The MDL chain or NDIS_BUFFER in the event callback must
> be treated very carefully. A TDI filter can intercept the Client ReceiveXXX

Also note that the TDI filter cannot indicate its own MDLs up via chained
receive. The client will call TdiRequrnChainedReceives, which is
NdisReturnPackets, and which will cause havoc if this MDL chain is not the one
created by the lowest NIC driver.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com


 
 
Maxim





PostPosted: Wed Oct 27 12:38:31 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers > 2. What does this ClientEventChainedReceive depends on ??? Is it a card
> dependent issue

Correct.

It can only be called if the card's driver uses NdisMIndicateReceivePacket. If
the card's driver uses the old-style indication - then the chained receive is
never called.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com


 
 
Puneet





PostPosted: Thu Oct 28 04:54:28 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers Hello Dave and Maxim,

Thanks for the reply.

I got your point. Looks like atleast Broadcom chipsets are making call to
NdisMIndicateReceivePackets, and because of which i am getting 'chained'
variant of receive events.

any idea when and in which case i will get to see
"ClientEventChainedReceiveExpedited" and "ClientEventReceiveExpedited".
Initially i though if there is a heavy data then i will be seeing it but
this doesn't seems to be the case for >10 MB mails also..

any hints ??

thanks and regards,
Puneet



> > 2. What does this ClientEventChainedReceive depends on ??? Is it a card
> > dependent issue
>
> Correct.
>
> It can only be called if the card's driver uses
NdisMIndicateReceivePacket. If
> the card's driver uses the old-style indication - then the chained receive
is
> never called.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation

> http://www.storagecraft.com
>
>


 
 
Maxim





PostPosted: Thu Oct 28 08:41:37 CDT 2004 Top

Drivers >> ClientEventChainedReceive problem in TDI drivers "Expedited" is OOB. I think that Telnet is the only app-level protocol
which uses OOB data.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation

http://www.storagecraft.com



> Hello Dave and Maxim,
>
> Thanks for the reply.
>
> I got your point. Looks like atleast Broadcom chipsets are making call to
> NdisMIndicateReceivePackets, and because of which i am getting 'chained'
> variant of receive events.
>
> any idea when and in which case i will get to see
> "ClientEventChainedReceiveExpedited" and "ClientEventReceiveExpedited".
> Initially i though if there is a heavy data then i will be seeing it but
> this doesn't seems to be the case for >10 MB mails also..
>
> any hints ??
>
> thanks and regards,
> Puneet
>


> > > 2. What does this ClientEventChainedReceive depends on ??? Is it a card
> > > dependent issue
> >
> > Correct.
> >
> > It can only be called if the card's driver uses
> NdisMIndicateReceivePacket. If
> > the card's driver uses the old-style indication - then the chained receive
> is
> > never called.
> >
> > --
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation

> > http://www.storagecraft.com
> >
> >
>
>