locked
Getting re-classified in context of Injection thread RRS feed

  • Question

  • I am trying to reinject some packets out of band at outgoing packet V4 layer and my calssfyFn is called again -- however, FwpsQueryPacketInjectionState0 does not indicate that the packet was self injected previously (_INJECTED_BY_SELF OR _PREVIOUSLY_INJECTED_BY_SELF).

    . . .this later causes some synchronization problems with my driver.

    note that this does not happen on Windows 7 RTM but only on Windows 7 SP1.

    Is this normal ?

    stack trace below:

    dpqwfp!wfpClassifyOutSend
    NETIO!ProcessNonBufferedCallout+0x23
    NETIO!ProcessCallout+0x184
    NETIO!ProcessFastCalloutClassify+0x30
    NETIO!KfdClassify+0x115
    tcpip!ProcessOutboundTransportLayerClassify+0x625
    tcpip!WfpProcessOutTransportStackIndication+0x49c
    tcpip!IppInspectLocalDatagramsOut+0x101
    tcpip!IppSendDatagramsCommon+0x5a8
    tcpip!IpNlpSendDatagrams+0x4b
    tcpip!IppSlowSendDatagram+0x31
    tcpip!IpNlpFastSendDatagram+0x1067
    tcpip!TcpTcbSend+0x787
    tcpip!TcpCreateAndAcceptTcb+0x79f
    tcpip!TcpListenerReceive+0xd7
    tcpip!TcpMatchReceive+0x60f
    tcpip!TcpPreValidatedReceive+0x293
    tcpip!TcpNlClientReceivePreValidatedDatagrams+0x15
    tcpip!IppLoopbackTransmit+0xda
    tcpip!IppLoopbackEnqueue+0x13d
    tcpip!IppDispatchSendPacketHelper+0xf6
    tcpip!IppPacketizeDatagrams+0x8d6
    tcpip!IppSendDatagramsCommon+0x652
    tcpip!IppInspectInjectRawSend+0xc6
    fwpkclnt!FwpsInjectNetworkSendAsync0+0x134
    dpqwfp!wfpInjectSendNBL
    0x9628d80b

     

     

    • Edited by RRTG Thursday, March 17, 2011 8:08 PM
    Wednesday, March 16, 2011 7:36 PM

All replies

  • Do you see this issue constantly with your driver?

    Thanks,

    Charlie


    Charlie
    Thursday, March 17, 2011 6:53 PM
  • Not always but mostly in the scenarios when my driver receives multiple NBs in a simgle NBL.
    I re-inject them one NB per NBL (per http://msdn.microsoft.com/en-us/library/ff569975(VS.85).aspx ).
    I get re-classified for the ACK for the injected packet while still in the context of injection handler.

    Is this normal ? Should I expect to be reclassified with another packets while still in context of the injection handler, reinjecting of a different packet ?

     

    Thursday, March 17, 2011 8:20 PM
  • Is it the same driver code you used for Win7 RTM and SP1? If yes could you please send a copy of sample code to wfp@microsoft.com so I could take a deeper look?

    Thanks,

    Charlie


    Charlie
    Thursday, March 17, 2011 11:28 PM
  • Yes, it is the same driver.

    I will have to ask before sending the code. meanwhile, Can you please answer this :

    Should I expect to be reclassified with another packets while still in context of the injection handler, reinjecting of a different packet ?

    Friday, March 18, 2011 12:07 AM
  • Hi RRTG,

    I am not sure I'm clear about your question. If you reinject new packets in outbound transport V4 layer, it will be reclassified by your callout driver, and your driver should allow these packets based on the queried injection state result.

    Thanks,

    Charlie


    Charlie
    Friday, March 18, 2011 12:33 AM
  • I understand that if I reinject a  packet a transport v4 layer, it may be reclassified to my callout driver. FwpsQueryPacketInjectionState0 will be used to determine injection state/history.

    my question is :

    when I call FwpsInjectNetworkSendAsync0 to reinject a packet, and before FwpsInjectNetworkSendAsync0 has returned, should my classfyFn be called with a different packet (other than the one I just injected ) in the same thread/stack ?

    Look at the stack I have shared. FwpsInjectNetworkSendAsync0 injects a packet A, my callout (dpqwfp!wfpClassifyOutSend) is classified/called for packet B.


    Friday, March 18, 2011 3:38 AM
  • Hi RRTG,

    Looks like you're reinjecting SYN packet while the 2nd indication is a SYN-ACK packet. Could you confirm if it's the case for your driver?

    Thanks,

    Charlie


    Charlie
    Wednesday, March 23, 2011 9:51 PM