I have now set the OID_TCP_TASK_OFFLOAD to return
NDIS_STATUS_NOT_SUPPORTED, but I have reservations in
doing so.
Since the “modified” packets are not handed down to the
miniport, but are reversed back up the stack, and all
others are passed down normally, how will this affect
the “normal” operations? Will the return of not supported
forced IP to perform the checksum operations, and will
this adversely affect performance?
After further research, I’ve discovered the following.
The protocol type is a masked bit(s) on the packet->flags. But this
doesn’t appear to be my problem. I had attempted to set the
flags in case TCP/IP task offloading was in effect, to “lie”
to the protocol, telling it that the checksums had been calc’ed
and compared and were valid. I’ve abandoned that tack and now
calc my own checksums for the injected packet. Ethereal says
that the actual packet data is all good.
I’ve also found that if the packet header size is incorrect,
the packet will not flow up, even to ethereal. It is currently
being set as sizeof(ETH_HEADER), or 14 bytes.
netstat -s however shows an incrementing of “Received Address Errors”
in the IPV4 stats. So apparently IP was seeing the packet all along
and rejecting it for some reason. I have no idea why Ethereal would
display a perfectly formed, and addressed, packet, and IP would consider
the address to contain errors? Does the OID_TCP_TASK_OFFLOAD affect
inbound packets as well as outbound?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Thomas F. Divine
Sent: Tuesday, May 25, 2004 7:48 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IPSec IM driver, created udp packet, not making it
through ndis?
“Chris Caviness” wrote in message news:xxxxx@ntdev…
I’ve calculated the checksums properly, and have set the following in
the new packet
ChecksumFlags.Receive.NdisPacketIpChecksumFailed = 0;
ChecksumFlags.Receive.NdisPacketIpChecksumSucceeded = 1;
ChecksumFlags.Receive.NdisPacketTcpChecksumFailed = 0;
ChecksumFlags.Receive.NdisPacketTcpChecksumSucceeded = 0;
ChecksumFlags.Receive.NdisPacketUdpChecksumFailed = 0;
ChecksumFlags.Receive.NdisPacketUdpChecksumSucceeded = 1;
NDIS_PER_PACKET_INFO_FROM_PACKET(DivertPacket, TcpIpChecksumPacketInfo) =
pChecksumFlags;
I’ve done more testing, and the protocol type returned is 0x02.
On normal incoming packets, this appears to return 0x00.
NDIS_SET_PACKET_PROTOCOL_TYPE is not a valid macro, however I have
found NdisSetPacketPoolProtocolId which associates a packet pool
with a protocol. I’m going to try adding that to the code just after
the rcvpacketpool is allocated and see what happens.
Not a good idea…
I said "Take a look at the macros in NDIS.h. Perhaps by looking at
NDIS_GET_PACKET_PROTOCOL_TYPE you can figure out what
NDIS_SET_PACKET_PROTOCOL_TYPE would be… "
Please read carefully…
Thomas F. Divine
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Thomas F. Divine
Sent: Tuesday, May 25, 2004 6:25 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IPSec IM driver, created udp packet, not making it
through ndis?
Take a look at the macros in NDIS.h. Perhaps by looking at
NDIS_GET_PACKET_PROTOCOL_TYPE you can figure out what
NDIS_SET_PACKET_PROTOCOL_TYPE would be… Set the protocol type to
NDIS_PROTOCOL_ID_DEFAULT to tell TCP/IP that this is NOT a packet with
offloaded checksum pre-computed.
If you disable NDIS Task Offload (as mentioned in one of the articles and in
the MS DDK PassThru sample) then this won’t be needed.
Thomas F. Divine
http://www.rawether.net
“Chris Caviness” wrote in message news:xxxxx@ntdev…
Thank you for your prompt reply. You’re just the man I wanted to hear
from. 
I based this on your IP filtering sample. On MSDN, I’ve found where you can
retrieve the protocol type in the packet, but cannot find where or how to
set this?
Oddly enough, when I’ve set up traps to examine normal inbound udp packets
and compared the data in the structures to my own reversed injected packet,
they appear initially to be identical? I suspected that the protocol type
may be incorrect and so IP is ignoring the receive indication, but alas,
can’t figure out how to change that…
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Thomas F. Divine
Sent: Tuesday, May 25, 2004 5:16 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] IPSec IM driver, created udp packet, not making it
through ndis?
The problem can be in areas other then the actual packet data itself.
See the information on the PCAUSA site:
“NdisReinitializePacket Does Not Completely Reinitialize A Packet”
http://www.pcausa.com/support/KB05050101.htm
“Modifying NDIS Intermediate (IM) Drivers And NDIS Task-Offload”
http://www.ndis.com/pcakb/KB05280101.htm
You may also want to set the protocol type in the packet to
NDIS_PROTOCOL_ID_DEFAULT.
Hope this helps.
Thomas F. Divine
http://www.pcausa.com
“Chris Caviness” wrote in message news:xxxxx@ntdev…
I’m writing an IM driver that intercepts outbound IPSec, wraps in a udp
envelope
and sends it back up the stack to our tunneling protocol listening on port
xxxx.
I’ve gotten to the point where the new ether/ip/udp headers are created in a
new
packet/buffer, and the old ipsec packet/payload are copied in, and the
packet is
indicated up to the protocol above.
Using TEthereal, I can see the UDP packet traverse up the stack, but udp
port
listeners I’m using to test never get the packet?
HELP!!!
Can NDIS refuse to move the packet up the stack? If so, why is it making it
into
winpcap/ethereal, which installs as a protocol? Is there some magic
required to
make IP take interest in the packet and forward it up to the application
layer?
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@circadence.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@circadence.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@circadence.com
To unsubscribe send a blank email to xxxxx@lists.osr.com