handling NDIS_PACKET_EXTENSION in an IM

Hmm, not sure what you mean exactly but the IM knows which offload
tasks have been enabled for its virtual adapters, doesn\'t it? Thus it
can generate its own packets and indicate them up. Am I missing
something obvious here?

Stephan
---
On Fri, 22 Mar 2002 13:30:33 -0500, \"Thomas F. Divine\"
<pcausa@hotmail.com> wrote:

>Also, how does one know how to handle the case where the packet received by
>an NDIS IM driver must be modified.
>
>In addition, how does an NDIS IM driver know how to setup the extension (so
>the higher-level gets what it expects) in packets that are generated
>autonomously in the NDIS IM to be indicated upwards as received packets? (I
>guess that the answer is to monitor all the NDIS task offload operations to
>learn what is expected...).
>
>It is a mess, IMHO. One quick-and-dirty is to disable NDIS task offload. Any
>performance gain that (may be) provided by task offload is lost, but the
>functionality of layered filters becomes manageable.
>--
>Thomas F. Divine
>
>PCAUSA - Tools & Resources For Network Software Developers
>NDIS Protocol/Intermediate/Hooking - TDI Client/Filter
><http://www.pcausa.com> - <http://www.rawether.net>
>
>\"Stephan Wolf\" <stewo68@hotmail.com> wrote in message
>news:6e8a2a95.0203220815.2c526915@posting.google.com...
>> I think there is a problem with how the NDIS_PACKET_EXTENSION needs to
>> be handled in an NDIS intermediate driver.
>>
>> For send packets one can use NdisIMCopySendPerPacketInfo() and
>> NdisIMCopySendCompletePerPacketInfo().
>>
>> However, there is no such function for the receive path.
>>
>> Now I am wondering how to handle the NDIS_PACKET_EXTENSION OOB data
>> for received packets. Shall it be copied from the original
>> (NDIS_GET_ORIGINAL_PACKET) to the local packet before indicating it?
>> Completely or only parts and if so which parts.
>>
>> I think there is currently a potential problem with that. The docs say
>> protocols shall use the OOB of the *original* receive packet. Thus,
>> there is no need to copy any OOB data to the local packet in the IM.
>>
>> BUT, what if the IM modifies the packet data such that for instance
>> the TCP checksum is no longer valid and needs to be recalculated by
>> the TCP/IP stack. TCP/IP (as well as NDIS Tester) currently checks the
>> TCP checksum flag in the *original* packet, which says \"TCP checksum
>> ok\".
>>
>> I think there should be an equivalent to NdisIMCopySendPerPacketInfo()
>> for the receive path, which copies the relevant OOB data extensions.
>> The IM could then clear any TCP checksum flags or modify whatever
>> needs to be modified. Protocols should then check the OOB in the
>> received packet, not the original packet.
>>
>> MS: Any comments?
>>
>> Stephan