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
  • Hi foobar1024,

    I seem to have a very similar problem, if not the same, but I can't figure out what I'm doing wrong. Would you mind sharing how you originally set the actionType and what you changed it to to make it work? Also, which classifyFn did that apply to?

    Thanks for your help,

    Michael

    Wednesday, May 6, 2020 9:56 PM
  • Hi Michael,

    I don't fully understand the internals of WFP stack, but I can share what I think might have happened. As you can see from one of my earlier comments, I was working with intercepting at two layers. Both these callouts were added at the same sublayer. 
    In one of the classify functions, I was setting the actionType to "FWP_ACTION_CONTINUE" as a default value. If the connection was of interest, I'd make a clone (for re-injection) and mark the actionType for the original flow to "FWP_ACTION_BLOCK". However, I was not removing the FWPS_RIGHT_ACTION_WRITE flag from the (FWPS_CLASSIFY_OUT *)classifyOut->rights field.
    For flows where I made a clone and re-injected it into the stack, the re-injected flow would be intercepted by other callouts (and/or possibly by other drivers too). I'm guessing some sanity checks at these layers might be causing them to think of this as a malformed packet/flow causing them to discard it (this is what Strive has also mentioned earlier).
    Once I set the rights field with the FWPS_RIGHT_ACTION_WRITE flag cleared, I didn't encounter this issue.

    Hope this helps!

    Thursday, May 7, 2020 8:24 PM
  • Hi foobar1024,

    Thank you for your explanation. I guess my problem is slightly different in that I only register at FWPM_LAYER_ALE_AUTH_CONNECT_V4 & FWPM_LAYER_OUTBOUND_TRANSPORT_V4. I've dumbed down my code to pretty closely mimic the Inspect sample code. I altered the filter conditions in both projects to only process UDP traffic. My code pends the connect, then completes/reauth's it and clones & reinjects the connect associated data. On completion the NLB->Status is 0xc000021b every once in a while but by no means all the time (maybe 1 in 10 or so on average). When I do the very same with the Inspect code, I always get STATUS_SUCCCES on completion...

    Michael

    Monday, May 11, 2020 12:22 AM