Re: NDIS passthru packet redirection

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance




"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: TOE brain dump
    ... primarily over ATMish core networks. ... "if you can't find header address ... the flow, if you can find a VC from cache, send the packet there" ... destination node address selector bits in header, ...
    (Linux-Kernel)
  • 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)
  • Re: NDIS passthru packet redirection
    ... I solved this with adjusting the TCP checksum. ... Now I must redirect the answer packet to the calling application. ... TCP header or TCP data isn't changed, the you don't need to update the TCP ...
    (microsoft.public.development.device.drivers)
  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from 192.160.1.0/24 to any in via dc1 ...
    (comp.unix.bsd.freebsd.misc)