Hello,
I assume my last post was completely missed out.I want to modify the
incoming TSDU in ClientEventReceive and ClientEventChainedReceive
Handlers. If i copy the buffer and modify the copy and make the client
receive my modified buffer with appropriate set of the BytesIndicated and
BytesAvailable in case of ClientEventReceive and Receive length in case of
ClientEventChainedReceive to appropriate values the client returns pending
and does not consumes data for a long time. It slows down the IE which is
the application in case it does not receives data for a long time and the
page is partially received .it happens only the times when full tsdu is
indicated the size of data increases 1460 becuase of my addition in receive
buffer.I want to know that does this problem persists because of the buffer
received more that 1460 bytes by the client ? Is there some upper or maximum
limit of the indicated data in tdi (DDK says there is a limit of 128
minimum indicated bytes but nothing about maximum value… ) ? I know the
maximum tcp segment size but does that has to do something here with what i
am trying to do ? what exactly is the correct way to do this ?
Pls shed some light …
—Subodh
First, some terminology: If you’re working at the TDI level, you’re not
working with packets, because the headers have been removed.
Next, what do you mean by “slows down”? If you mean it may 10-30 seconds
to complete, I wonder if you’re not getting resounds, resents and such
(which, by the way, would undercut my belief that you’re not working at
the packet level). I’ve seen this phenomenon in modifying packets via an
NDIS IM driver. I’d fire up a packet sniffer to look at traffic. In
fact, if you’re working at the TDI level or the NDIS level, a packet
sniffer is a basic tool.
Third, about the size. I suspect this is indirectly related to packet
size, because a TSDU is, I believe, pretty much a packet without
headers, or maybe part of a packet. I’m inclined to doubt a TSDU would
be assembled from 2 or more packets. A possible consequence of this
inferred fact is that if you modify a TSDU and it’s larger than the
maximum size of a packet (MTU, more or less), who knows what might
happen? I’ve never tried to modify a TSDU to the extent of enlarging it,
and I don’t know of anyone else who’s reported success, so I simply
don’t know. Lots of people, on the other hand, have modified packets via
NDIS IM drivers. Unfortunately, that’s really, really complicated, in
part because in an NDIS IM driver one may have to reassemble packets
from fragments, and doing that plunges the driver into a whole other
realm of design complexity.
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP
Maybe I should have gotten more sleep last night. Let me correct a
sentence: “If you mean it may take 10-30 seconds to complete, I wonder
if you’re not getting resends, resynchs and such (which, by the way,
would undercut my belief that you’re not working at the packet level).”
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP
> headers, or maybe part of a packet. I’m inclined to doubt a TSDU
would
be assembled from 2 or more packets. A possible consequence of this
TSDU is NDIS packet, since TdiReturnChainedReceives is
NdisReturnPackets.
Max
James,
Yeah i am working on TDI level, Sorry for the word packet… i was so tired
at the time i wrote the mail (late evening time mail)…By slows down i
mean to say that the client returns STATUS_PENDING and if the client is IE
the page is partially recieved and never opened…
Hope this clears the problem…
—Subodh
----- Original Message -----
From: “James Antognini”
Newsgroups: ntdev
To: “Windows System Software Developers Interest List”
Sent: Sunday, July 13, 2003 10:42 PM
Subject: [ntdev] Re: How to modify the packet
> First, some terminology: If you’re working at the TDI level, you’re not
> working with packets, because the headers have been removed.
>
> Next, what do you mean by “slows down”? If you mean it may 10-30 seconds
> to complete, I wonder if you’re not getting resounds, resents and such
> (which, by the way, would undercut my belief that you’re not working at
> the packet level). I’ve seen this phenomenon in modifying packets via an
> NDIS IM driver. I’d fire up a packet sniffer to look at traffic. In
> fact, if you’re working at the TDI level or the NDIS level, a packet
> sniffer is a basic tool.
>
> Third, about the size. I suspect this is indirectly related to packet
> size, because a TSDU is, I believe, pretty much a packet without
> headers, or maybe part of a packet. I’m inclined to doubt a TSDU would
> be assembled from 2 or more packets. A possible consequence of this
> inferred fact is that if you modify a TSDU and it’s larger than the
> maximum size of a packet (MTU, more or less), who knows what might
> happen? I’ve never tried to modify a TSDU to the extent of enlarging it,
> and I don’t know of anyone else who’s reported success, so I simply
> don’t know. Lots of people, on the other hand, have modified packets via
> NDIS IM drivers. Unfortunately, that’s really, really complicated, in
> part because in an NDIS IM driver one may have to reassemble packets
> from fragments, and doing that plunges the driver into a whole other
> realm of design complexity.
>
> –
> If replying by e-mail, please remove “nospam.” from the address.
>
> James Antognini
> Windows DDK MVP
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
I should think that TSDU is an NDIS packet without ethernet, IP and TCP
headers. Or am I mistaken (I haven’t used chained receive)?
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP
It is NDIS_PACKET structure. TdiReturnChainedReceives is
NdisReturnPackets.
Maybe there was some MDL hackery done to the MDL chain of the packet
to skip the headers, but I have great doubts in it. After all,
StartingOffset is specified to ChainedReceive TDI event too, and I
expect the headers to be “under” this StartingOffset.
Max
----- Original Message -----
From: “James Antognini”
Newsgroups: ntdev
To: “Windows System Software Developers Interest List”
Sent: Monday, July 14, 2003 8:15 PM
Subject: [ntdev] Re: How to modify the packet
> I should think that TSDU is an NDIS packet without ethernet, IP and
TCP
> headers. Or am I mistaken (I haven’t used chained receive)?
>
> –
> If replying by e-mail, please remove “nospam.” from the address.
>
> James Antognini
> Windows DDK MVP
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to
xxxxx@lists.osr.com
Max,
Header is just before the Starting offset Provded with chained receive,and
what i have observed that NT 4 uses ClientEventReceive Extensively while 2K
and XP uses ClientEventChainedReceive extensively.
TdiReturnChainedReceive is fine for returning the NDIS_PACKET back to
NDIS.But What i have done is to call ClientEventRecieve inside
ClientEventChainedRecive to deliver the modified payload in breaks of 1460
and the reminder but strage enough the either the client doest not consumes
data for long time, or if i use ClientEventChainedRecieve for normal 1460
and call ClientEventReceive With reminder then some how miniport knows that
i am trying to indicate a fake packet and bug checks D2.
—Subodh
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Developers Interest List”
Sent: Tuesday, July 15, 2003 1:22 AM
Subject: [ntdev] Re: How to modify the packet
> It is NDIS_PACKET structure. TdiReturnChainedReceives is
> NdisReturnPackets.
>
> Maybe there was some MDL hackery done to the MDL chain of the packet
> to skip the headers, but I have great doubts in it. After all,
> StartingOffset is specified to ChainedReceive TDI event too, and I
> expect the headers to be “under” this StartingOffset.
>
> Max
>
> ----- Original Message -----
> From: “James Antognini”
> Newsgroups: ntdev
> To: “Windows System Software Developers Interest List”
>
> Sent: Monday, July 14, 2003 8:15 PM
> Subject: [ntdev] Re: How to modify the packet
>
>
> > I should think that TSDU is an NDIS packet without ethernet, IP and
> TCP
> > headers. Or am I mistaken (I haven’t used chained receive)?
> >
> > –
> > If replying by e-mail, please remove “nospam.” from the address.
> >
> > James Antognini
> > Windows DDK MVP
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to
> xxxxx@lists.osr.com
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@softhome.net
> To unsubscribe send a blank email to xxxxx@lists.osr.com
> Header is just before the Starting offset Provded with chained
receive,and
what i have observed that NT 4 uses ClientEventReceive Extensively
while 2K
and XP uses ClientEventChainedReceive extensively.
This depends on NIC miniport driver and not on the OS version - namely
on what indication method the miniport uses to handle receives. I saw
NT4 using chained receive path.
data for long time, or if i use ClientEventChainedRecieve for normal
1460
The packets indicated by ClientEventChainedRecieve will be passed to
TdiReturnChainedReceives, which is NdisReturnPackets.
So, using your own fake packet in ClientEventChainedRecieve will cause
it to be passed to NdisReturnPackets, which I think is a crash.
The way to go is to convert ChainedReceive indications to usual
Receive ones, and only indicate the usual receives to upper edge.
You must also do the proper synchronization between ClientEventReceive
flow from down to up and TDI_RECEIVE IRPs flow from up to down. At
least you must not call any receive indication callback if you have an
outstanding TDI_RECEIVE. In this case, copy the data to the IRP’s
buffer, dismiss the callback and possibly complete the IRP.
Max
I’m sure you’re right. I should have read the DDK description of
TdiReturnChainedReceives before speaking. Sorry.
–
If replying by e-mail, please remove “nospam.” from the address.
James Antognini
Windows DDK MVP