locked
Reinject packets with source local destination local RRS feed

  • Question

  • I have a callout driver inspecting all packets at FWPM_LAYER_INBOUND_IPPACKET_V4 and then reinjects all the packets (this is just a test).

     

    Let us say the machine with the callout driver has IP address A. Another machine pings A and this works fine; i.e packet is inspected by the callout, reinjected into the inbound queue and the pinging machine receives a reply.

     

    Now, let us say that I attempt to ping A from the machine that has the callout installed. For some reason, this does now work. The packet is inspected and reinjected, however the ping does not receive a reply. Removing the driver (or stopping it) allows ping A from the machine with the callout to work; a reply is received. I have tested the same scenario with other protocols (say http) but the same was noted.

    Is some special processing required when both source and destination of an inspected packet happen to be on the local machine?

    Tuesday, November 29, 2011 4:27 PM

All replies

  • Is the injection successful?  Does the injection API you call return STATUS_SUCCESS?  In the Completion function does the NBL->Status also have STATUS_SUCCESS?

     

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, November 29, 2011 11:21 PM
    Moderator
  • Injection is done using FwpsInjectNetworkReceiveAsync0() since I am filtering incoming data. This returns STATUS_SUCCESS. However, in the completion function, NBL->Status is 0xC000021B (STATUS_DATA_NOT_ACCEPTED in ntstatus.h). This error does not occur for packets that are not generated on and directed to the same machine.

    Should some other way of injection into the receive path be used when not modifying any data? I am under the impression that this is not the case but might be wrong.

    All help (past and future) are, and have been, greatly appreciated.
    Tuesday, December 6, 2011 8:09 AM
  • From the thread named: "Block send and inject recv at datagram layer" there seems to be a somewhat of a similar issue:

    Quoting: "Yes recv- inject from/to a loopback address will not be accepted by the tcpip stack as if such an packet arrives from the wire."

    Does this also stand for the case mentioned here?

    Tuesday, December 6, 2011 8:49 AM
  • When you are injecting the packet, you can't specify loopback (127.0.0.1 || ::1)  You need to inject to an actual address on the machine.  Is this the case, or are you specifying loopback?

     

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Tuesday, December 6, 2011 4:31 PM
    Moderator
  • The packet that is injected has source IP being the IP of the machine (let us say, 10.7.3.1) and the destination is the same IP as the source. So, if I have a ping, the IP header looks like this:
    Source Field: 10.7.3.1
    Destination Field: 10.7.3.1.

    The IP header of the packet that is injected looks as follows (obtained with WinDBG)
    45 00 00 3c 00 90 00 00 80 01 00 00 0a 07 03 01 0a 07 03 01

    I have always been under the impression that this is some sort of loopback, such a packet will not go onto the wire. Maybe it does not have the loopback address, but the mechanism is the same. Am I correct to think this?
    Wednesday, December 7, 2011 9:32 AM
  • Yes, the only time you have to modify the addresses when injected is when they are the actual loopback addresses, in which case you need to modify them to the actual address on the NIC (i.e. 10.0.0.1).

    Can you provide a memory dump where you are broken in at the completion function?  You can send this to DHarper AT Microsoft DOT com.

    Thanks

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, December 7, 2011 8:01 PM
    Moderator