Re: NDIS passthru packet redirection

Hi Thomas,

I solved this with adjusting the TCP checksum. I never touched the TCP data,
but as I can read on the specs, TCP checksum must be updated, if ip adresses
are changed.
Now I must redirect the answer packet to the calling application. This is
only possible in PtReceivePackets, but this function is never calling. So I
must enable OID_GEN_CURRENT_PACKET_FILTER with NdisRequest. I did this in
MPInitialize but my IM always crashs.
How can I solve this?

--
Best regards,
Mathias

"Thomas F. Divine [DDK MVP]" <tdivine@xxxxxxxxxxxxxxxx> wrote in message
news:ekO8wGISGHA.2300@xxxxxxxxxxxxxxxxxxxxxxx

"Mathias Walter" <mathias.walter@xxxxxxx> wrote in message
news:ulvE1JHSGHA.2536@xxxxxxxxxxxxxxxxxxxxxxx
Hi again,

it's still not working. It's so strange for me. All other packets are
send very well, even if I copy all packets to my own packet and send my
own packet, except the redirected one.
Are you sure, that it's not necessary to recalculate the tcp checksum? If
I modify ip addresses in the ip header, the pseudo-header is changed. The
tcp checksum is based on the pseudo-header checksum or am I wrong?

I redirect IP packets successfully for send and receiver. As long as the
TCP header or TCP data isn't changed, the you don't need to update the TCP
header.

In addition, even if you screw up the headers you should see modified
packets on the wire. They may be screwed up, but they would at least be
modified.

Since you are NOT seeing any modified packet, you have something
fundamentally wrong - but I don't see it.


If TASK_OFFLOAD is disabled, if I return NDIS_STATUS_NOT_SUPPORTED in
MPQueryInformation or must I do something else?

As long as you return NDIS_STATUS_NOT_SUPPORTED, then that's the end of
task offload.


Is there any other things missing?

--
Regards, Mathias

"Thomas F. Divine [DDK MVP]" <tdivine@xxxxxxxxxxxxxxxx> wrote in message
news:Ob3he0GSGHA.1844@xxxxxxxxxxxxxxxxxxxxxxx
You might skip the call to NDIS_SET_ORIGINAL_PACKET. That is effectively
saying that your new packet is the same as the original packet. Set it
to NULL or to your packet.
If you have disable NDIS task offload, then all of that OOB stuff
doesn't matter. If you have not disabled NDIS task offload,then you
should examine the OOB data and see if it applies to your modified
packet.

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com


"Mathias Walter" <mathias.walter@xxxxxxx> wrote in message
news:ue3u7lGSGHA.4456@xxxxxxxxxxxxxxxxxxxxxxx
Hello Thomas,

thank you for your quick response.

I did all things you sad, except that I moved along the buffer chain
and copied each buffer memory separately. I changed this as you
suggested, but it's still not working.

I changed the miniport.c MPSendPackets function as following:

if (!(SndFltAction & SND_FLT_REDIR_PACKET)) {
//
// Copy the OOB data from the original packet to the new
// packet.
//
NdisMoveMemory(NDIS_OOB_DATA_FROM_PACKET(MyPacket),
NDIS_OOB_DATA_FROM_PACKET(Packet),
sizeof(NDIS_PACKET_OOB_DATA));
//
// Copy relevant parts of the per packet info into the new packet
//
#ifndef WIN9X
NdisIMCopySendPerPacketInfo(MyPacket, Packet);
#endif

//
// Copy the Media specific information
//
NDIS_GET_PACKET_MEDIA_SPECIFIC_INFO(Packet,
&MediaSpecificInfo,
&MediaSpecificInfoSize);

if (MediaSpecificInfo || MediaSpecificInfoSize)
{
NDIS_SET_PACKET_MEDIA_SPECIFIC_INFO(MyPacket,
MediaSpecificInfo,
MediaSpecificInfoSize);
}

} else {
// Copy package buffers
NdisQueryPacketLength(Packet, &TotalPacketLength);
// Allocate my data buffer for the whole packet
NdisAllocateMemoryWithTag( &pBuf, TotalPacketLength, TAG );

// Allocate my buffer handle
NdisAllocateBuffer( &Status, &pMyBuffer,
pAdapt->SendBufferPoolHandle, pBuf, TotalPacketLength );

// Insert my buffer into my packet
NdisChainBufferAtFront( MyPacket, pMyBuffer );

DbgPrint("copying packet data...\n");

// Copy original packet data into my new buffer
NdisCopyFromPacketToPacketSafe(MyPacket, 0, TotalPacketLength,
Packet, 0, &uiCopied, NormalPagePriority);

// Redirect IP to myself
pIPHeader = (struct ip*)&pBuf[sizeof(struct ether_header)];
pIPHeader->ip_dst.s_addr = inet_addr("10.150.36.8");
chksum = getChecksum(pIPHeader);
pIPHeader->ip_sum = chksum;
DbgPrint("redirected to ip: %d.%d.%d.%d\n", pBuf[30], pBuf[31],
pBuf[32], pBuf[33]);

NDIS_SET_ORIGINAL_PACKET(MyPacket,
NDIS_GET_ORIGINAL_PACKET(Packet));
NdisSetPacketFlags(MyPacket, NdisGetPacketFlags(Packet));
Status = NDIS_GET_PACKET_STATUS( Packet );
NDIS_SET_PACKET_STATUS( MyPacket, Status );
NDIS_SET_PACKET_HEADER_SIZE(MyPacket,
NDIS_GET_PACKET_HEADER_SIZE(Packet));

FltPrintPacketInfo(MyPacket); // prints ip information
}

NdisSend(&Status,
pAdapt->BindingHandle,
MyPacket);

The function FltPrintPacketInfo prints out the correctly changed
destination address.
A network monitor on the destination computer does not recieve any
packages.

What is still missing or wrong?

--
Regards, Mathias

"Thomas F. Divine [DDK MVP]" <tdivine@xxxxxxxxxxxxxxxx> wrote in
message news:uO9gWGGSGHA.4960@xxxxxxxxxxxxxxxxxxxxxxx

"msnews.microsoft.com" <mathias.walter@xxxxxxx> wrote in message
news:e0tcWxFSGHA.4792@xxxxxxxxxxxxxxxxxxxxxxx
Hello,

I want to redirect tcp packets to different destination. For that, I
modified the passthru example from the Win2003 DDK and changed the
destination ip address in MPSendPackets (allocate my own packet and
buffers).

But the packet is routed somewhere else.

In Ethereal the old destination address is showing. I don't know why.

The request always times out.

I disabled task offloading at all (
NdisSetPacketPoolProtocolId(pAdapt->SendPacketPoolHandle,
NDIS_PROTOCOL_ID_DEFAULT); in PBindAdapter
and
Status = NDIS_STATUS_NOT_SUPPORTED in MPQueryInformation)
and calculate the ip header checksum. Do I need to calculate the tcp
checksum or pseudo-header checksum too?

If you did not modify the TCP header or payload, then you do not need
to recalcuate the TCP headers. Only the IP header.


Does anyone know, why Ethereal shows the original destination ip
address?
What can I do to make the redirection working?

Probably...

...you didn't actually modify the IP header correctly.

You must allocate your own NDIS_PACKET and NDIS_BUFFER (you said that
you did this already...) _AND_ you must also allocate your own virtual
memory (byte array) for the modified packet data. The simplest way is
to allocate a non-paged byte array whose length is the total packet
length. Allocate a NDIS_BUFFER for this array VM, then chain it to
your NDIS_PACKET. Now you can use NdisCopyFromPacketToPacket to copy
the original packet data to your own private copy. Then change the
destination IP in YOUR VM and re-calcuate the IP header checksum (You
should not modify the original data).

You can use the debugger to examine the packet just before you call
NdisSend to insure that what you are sending is correct.

Ethereal (or any network monitor) can cause confusion if it is run on
the same machine that hosts your NDIS IM filter driver. NDIS does some
software loopback of send packets when Ethereal is running, and these
can be misleading. In Ethereal on the local host you may see what was
originally sent - NOT your modified packet. I suggest that you use a
separate machine on the network to observe what is actually sent on
the wire.

Good luck,

Thomas F. Divine, Windows DDK MVP
http://www.pcausa.com









.

Relevant Pages

  • Re: How to handle TCP checksum, if adapter support TCP checksum offloading?
    ... the TCP/IP stack calculates the TCP pseudo header checksum ... When i run my client on 172.10.10.11, the very first packet (which is SYN, ... It has only the sum of TCP pseudo header. ...
    (microsoft.public.development.device.drivers)
  • bge on 64-bit pci: corrupt packets
    ... TCP packets sent over the vlan would get corrupted while sending. ... The content of the packet would get corrupted, ... The problem appears to go away when a 32-bit PCI slot is used. ... Not only were there no tcp checksum errors, ...
    (freebsd-hackers)
  • RE: Strange kernel happenings
    ... > packet has arrived intact. ... the ip header check sum covers the ip header only. ... The checksum in the IP header covers the ip header only, ... ICMP has a checksum, which covers the entire ICMP message. ...
    (Incidents)
  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • RE: First TCP packet
    ... The TCP datagram travels inside an IP packet, ... to B should be the TTL on the IP Header. ... might change depending of devices on the path ...
    (Pen-Test)