none
0xc000021b (STATUS_DATA_NOT_ACCEPT) with WFP at FWPM_LAYER_OUTBOUND_TRANSPORT_V4 layer RRS feed

  • Question

  • Hi,

    I'm seeing a 0xc000021b (STATUS_DATA_NOT_ACCEPT) error code in the injection completion function when I try to clone and inject the NET_BUFFER_LIST after modifying the destination address to a local interface address (not local loopback). I don't see any issues when the modified destination address is a non-local address.

    The flow I'm using is:

    1. Register callout at FWPM_LAYER_OUTBOUND_TRANSPORT_V4 layer.
    2. In the classify function, check the injection state using FwpsQueryPacketInjectionState. If already injected, exit.
    3. Clone the NET_BUFFER_LIST using FwpsAllocateCloneNetBufferList routine
    4. Allocate and initialize the FWPS_TRANSPORT_SEND_PARAMS structure with the required destination IP address - local interface IP address.
    5. Call FwpsInjectTransportSendAsync routine with this FWPS_TRANSPORT_SEND_PARAMS structure to inject the modified packet(s) back into the stack.
    6. Wait for the injectionCompletionFn to be called. I free the FWPS_TRANSPORT_SEND_PARAMS here. In this completion routine, the NBL->status is always 0xc000021b.

    If in step 4 above, I insert a non-local interface IP address, the NBL->status in the completion function is 0 (success). Does the use of a local interface address involve a different workflow? I'm not sure if I'm missing something.

    Looking forward to answers/suggestions on this.

    Thursday, July 18, 2019 11:54 PM

All replies

  • Hi, foobar1024

    There is a similar discussion.

    Best regards,

    Strive


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, July 19, 2019 10:25 AM
  • Hi Strive,

    Thanks for pointing out the discussion. Yes, it looks similar, but unfortunately, it doesn't have a resolution yet :(

    Meanwhile, I've been debugging the issue myself, and this is what I've discovered so far:

    1. I've registered for callouts at two layers - INBOUND_IPPACKET layer and OUTBOUND_TRANSPORT layer.
    2. The packet which I modify at the OUTBOUND_TRANSPORT layer also hits the INBOUND_IPPACKET layer (because the modified destination address is that of the local interface).
    3. I don't process the packet at the INBOUND_IPPACKET layer, but my classify function is invoked because of the filtering conditions. I think the problem lies here.
    4. After returning from the classify function at the INBOUND_IPPACKET layer, the outbound-injection-completion function, the NBL->status is 0xc000021b.

    My workflow at the INBOUND_IPPACKET classify to not process this packet is:

    1. Check if I have rights to perform any actions on the packet. Exit otherwise.
    2. Set FWPS_CLASSIFY_OUT->actionType to FWP_ACTION_CONTINUE
    3. Capture connection info like IP protocol, ports from the NBL (by retreating/advancing NBL offset, but ensuring that the original offset is always restored).
    4. Use the info captured in 3 above to determine if this is "connection of interest". As in this case, the packets are not of interest, my code returns from here.

    Also, to test my hypothesis, I used the ping command with the local interface ip. The ping command also fails with "General failure". This happens after I intercept and continue from my classify function at INBOUND_IPPACKET layer.

    So, I think the question to ask now is how do I continue execution at INBOUND_IPPACKET layer for connections which are not of interest. Can you help me with that?

    Tuesday, July 23, 2019 6:24 PM
  • Hi, foobar1024

    Thank you for your reply.

    I'm curious about why you are modifying the destination address to a local interface address.

    DATA_NOT_ACCEPT is like a packet that is dropped because it does not conform to TCP/IP protocol.

    Meanwhile, Can you provide a demo so that I can reproduce your problem and research it further.

    Look forward to your reply:)

    Best regards,

    Strive


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, July 24, 2019 9:29 AM
  • Hi Strive,

    Thanks for reaching out and sorry for the delay in responding.

    I was able to fix the initial issue. The issue was the way I was setting the actionType field in the classifyFn.
    Once I fixed that, I was able to observe the intended behavior.

    Thanks!

    Monday, September 16, 2019 11:16 PM