locked
TCP Header in FWPM_LAYER_STREAM_PACKET_V4 RRS feed

  • Question

  • Hi,

    I'm learning how to write filters using WFP and there is one thing I don't understand...

    I've registered my driver in the FWPM_LAYER_STREAM_PACKET_V4 layer and my callout see any incoming/outcoming packets (including SYN/ACK/FIN etc).

    I'd like to access to the TCP Header of all packets... I'm able to read the outgoing packets tcp header with this code:

    status = FwpsAllocateCloneNetBufferList0(
    	(NET_BUFFER_LIST*)layerData,
    	NULL,
    	NULL,
    	0,
    	&nbl);
    
    if (!NT_SUCCESS(status))
    {
    	DbgPrint("Cannot AllocateCloneNetBufferList: %lx", status);
    	goto Exit;
    }
    
    nb = NET_BUFFER_LIST_FIRST_NB(nbl);
    
    if (direction == FWP_DIRECTION_OUTBOUND)
    {
    	tcp_header = (TCP_HEADER*)NdisGetDataBuffer(
    		nb,
    		sizeof(TCP_HEADER),
    		NULL,
    		sizeof(UINT16),
    		0);
    }
    

     

     

    but the same code for the INCOMING packets fails (NdisGetDataBuffer returns NULL).

    I'm not able to understand why it works for the outgoing packets and not for the incoming ones... could anyone explain me why and how to access to the TCP header for the incoming packets?

    Thank you very much!
    Marco

    Wednesday, August 4, 2010 12:17 AM

Answers

  • At STREAM_PACKET, for outbound traffic, the NBL offset is at the Transport header.  For Inbound, the NBL offset is at the beginning of the data.  You need to call NdisRetreatNetBufferListDataStart and retreat the size of the transport header (found in the metadata).  when done, you need to call NdisAdvanceNetBufferListDataStart and advance by the same size returning the NBL to the original offset.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, August 4, 2010 4:01 AM
    Moderator
  • Found it!

    My mistake was retreating the cloned buffer... and the buffer was cloned from the pointer after the TCP header. So I was reading dirty stuff because I was already at the beginning of the cloned buffer.

    So, for the records, the correct way is to call NdisRetreatNetBufferListDataStart to (NET_BUFFER_LIST*)layerData and not to nb !

    Thanks,
    Marco

    • Marked as answer by Marco Mura Thursday, August 5, 2010 12:06 AM
    Thursday, August 5, 2010 12:06 AM

All replies

  • At STREAM_PACKET, for outbound traffic, the NBL offset is at the Transport header.  For Inbound, the NBL offset is at the beginning of the data.  You need to call NdisRetreatNetBufferListDataStart and retreat the size of the transport header (found in the metadata).  when done, you need to call NdisAdvanceNetBufferListDataStart and advance by the same size returning the NBL to the original offset.

     

    Hope this helps,

     


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Wednesday, August 4, 2010 4:01 AM
    Moderator
  • Hi,

    thanks for your reply, but unfortunately it doesn't work.

    I have already tried to call NdisRetreatNetBufferListDataStart on nb with the size inMetavalues->transportHeaderSize. In this case NdisGetDataBuffer doesn't fail but it reads dirty data.

    Thanks,
    Marco

    • Proposed as answer by closso Wednesday, November 5, 2014 10:43 PM
    Wednesday, August 4, 2010 4:14 AM
  • Found it!

    My mistake was retreating the cloned buffer... and the buffer was cloned from the pointer after the TCP header. So I was reading dirty stuff because I was already at the beginning of the cloned buffer.

    So, for the records, the correct way is to call NdisRetreatNetBufferListDataStart to (NET_BUFFER_LIST*)layerData and not to nb !

    Thanks,
    Marco

    • Marked as answer by Marco Mura Thursday, August 5, 2010 12:06 AM
    Thursday, August 5, 2010 12:06 AM