Re: How to handle TCP checksum, if adapter support TCP checksum offloading?

From: Thomas F. Divine [DDK MVP] (tdivine_at_NOpcausaSPAM.com)
Date: 08/04/04 

Date: Tue, 3 Aug 2004 22:30:47 -0400

I think that the OP is really interested in how to systematically account
for NDIS checksum task offload when sending modified packets of his own. He
has the situation where there is no NDIS checksum offload under control. Now
how to deal with the presence (or absence) fo this feature.

1.) Microsoft makes this recommendation in the MPQueryInformation handler of
the PassThru sample:

"NOTE on OID_TCP_TASK_OFFLOAD - if this IM driver modifies the contents of
data it passes through such that a lower miniport may not be able to perform
TCP task offload, then it should not forward this OID down, but fail it here
with the status NDIS_STATUS_NOT_SUPPORTED. This is to avoid performing
incorrect transformations on data."

2.) Here is another approach that may work:

I believe that it will work, but I have only tested it partially and those
tests were not recent.

Allocate a separate NDIS packet pool for your modified packets. Allocate by
calling NdisAllocatePacketPool. After allocating the pool, but before you
actually allocate any packets from the pool, call NdisSetPacketPoolId with
NDIS_PROTOCOL_ID_DEFAULT, defined in ntddndis.h. (This is probably the
default, but do it anyway to be safe...).

When you are sending your modified packets, use this pool instead of the
existing send pool that you use for re-wrapping passthru packets.

Do not copy OOB data, etc, into your modified packets.

In completion routines you can identify packets that came from this special
pool using NdisGetPoolFromPacket (XP and later only..) or some other scheme
on W2K. (Why in the world does Microsoft add features that are not back
fitted into other current OS's like W2K. It really makes them useless since
you can't count on them being present...).

In any case, in completion routines always return the packet to the pool it
was allocated from.

When you build your modified packet build the checksums correctly yourself
for all modified packets. Don't care whether there is NDIS Task Offload or
not.

Send the packet...

In the adapter miniport what actually happens if NDIS Task Offload is
enabled is that the miniport will check the NDIS packet flags using
NDIS_GET_PACKET_PROTOCOL_TYPE. If the protocol id is NDIS_PROTOCOL_ID_TCP_IP
then it will do the checksum in its hardware.

HOWEVER, your modified packets are allocated from the pool with
NDIS_PROTOCOL_ID_DEFAULT. For this protocol id the adapter will NOT do any
checksums.

Hope this makes sense. Please let me know if this works as I think it does.

Thomas F. Divine, Windows DDK MVP
http://www.ndis.com, http://www.rawether.net

"Stephan Wolf [MVP]" <stewo68@hotmail.com> wrote in message
news:6900h0l2tp83k4ovrlncs8gpng5ofetnf9@4ax.com...
> See
>
>
>
http://www.google.com/groups?threadm=e006f0hduqmhs0tklt7b7opucnmmf3rpm1%404ax.com
>
> [Read the whole thread]
>
> Stephan
> ---
> On Mon, 2 Aug 2004 16:20:08 -0700, "Rajesh Gupta" <guptar@gmail.com>
> wrote:
>
> >
> >
> >Hi Everyone,
> >I am writting a IM driver, where i am modifing the Source Ip and
Destonation
> >IP in the outgoing packets.
> >
> >I am not sure what to do with the TCP checksum, if adapter supports TCP
> >checksum offloading.
> >
> >I have tested my driver with adapter, which does not support TCP checksum
> >offloading. It works fine. My checksum calculations are fine. When i am
> >testing my IM driver on adapter which supports TCP checksum offloading,
its
> >not working.
> >
> >I am not sure, ho to handle TCp checksum offloading in IM driver. Here
are
> >the strange things i have noticed.
> >
> >1. If i do not change anything, then it does not work. Understood.
> >
> >2. If i calculate the TCP checksum (using TCp psuedo header and TCP
segment)
> >and insert this checksum in the TCP header. It works for the first TCp
> >packet. For rest of the packets, its incorrect. I have written simple
server
> >and client socket application. So this checksum works for first packet
i.e.
> >SYN packet. Thats strange to me, why it worked for SYN and after that its
> >incorrect for all other packets.
> >
> >NOTE: I am checking my packets on another machine. So i am seeing the
> >correct data send on wire using etherreal.
> >
> >3. I read somewhere, that sometimes TCP calculate the checksum of
> >psudoheader and fill this in the TCP header. So hardware only calculate
the
> >TCP segment checksum and does not have to touch the IP header. I tried
that.
> >Nothing works after that.
> >
> >I am not sure, why SYN worked and how should i handle this in my IM
driver?
> >
> >Thanks a lot in advance.
> >
> >Rajesh

Relevant Pages

  • Microsoft Windows Remote Desktop Protocol checksum and keystroke vulnerabilities
    ... All versions of Microsoft Windows using encrypted RDP are vulnerable to ... the checksum vulnerability. ... since packets with the same plaintext have matching checksums. ... When RDP has encryption enabled, packets are first encrypted using RC4, ...
    (Bugtraq)
  • [NT] Microsoft Windows Remote Desktop Protocol Checksum and Keystroke Vulnerabilities
    ... since packets with the same plaintext have matching checksums. ... the checksum vulnerability. ... Microsoft's Terminal Services Virtual Channels are also vulnerable. ... Client to server: ...
    (Securiteam)
  • Re: IM driver modifying packet content and task offload
    ... You can create packets in your IM driver and let the underlying miniport do the checksum. ... The TCP/IP transport calculates the one's complement sum across all fields in the pseudoheader, including Source IP Address, Destination IP Address, Protocol, and the TCP length for TCP packets. ...
    (microsoft.public.development.device.drivers)
  • Re: Is HT faster infiniband?
    ... > Proceedings of the ACM conference on Applications, Technologies, ... > links where link-level CRCs should catch all but 1 in 4 billion errors. ... the rate of checksum failures can be even ... > nearly 500,000 packets which failed the TCP or UDP or IP checksum. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Is HT faster infiniband?
    ... Proceedings of the ACM conference on Applications, Technologies, ... "Traces of Internet packets from the past two years show that between 1 ... links where link-level CRCs should catch all but 1 in 4 billion errors. ... the rate of checksum failures can be even ...
    (comp.sys.ibm.pc.hardware.chips)