locked
Issue at FWPM_LAYER_STREAM_V4 when pass more data RRS feed

  • Question

  • Hi All, I have encountered an issue at FWPM_LAYER_STREAM_V4.

    Before I choose filter data at stream layer, I assume it is working as same as the packet which I send or receive at the socket API application.

    For example, when I use socket Application send 2000 bytes, at the stream layer, it will be send 2000 bytes too. When I use socket Application receive 2000 bytes, it also will be receive 2000 bytes.

    I did not set the filter at FWPM_LAYER_INBOUND_TRANSPORT_V4 or FWPM_LAYER_OUTOUND_TRANSPORT_V4, because it is working in TCP layer, as you know, TCP will split the big packet to many small packets.

    However, I found that the stream layer as I expected when it is sending data. But it is as same as the Transport layer when it is receiving data. For example, if the data is a 2000 bytes packet, It will be split a 1460 bytes packet and 540 bytes packet when it is received.

    Because I must analyze data from a complete packet when receive data, so what's wrong with it? Is it possible to receive complete data when receive data at FWPM_LAYER_STREAM_V4?



    Thanks in advance!

    Thursday, January 9, 2014 2:42 AM

All replies

  • On inbound the data has been packetized (split into the proper MTUs, and headers added). so the data you are indicated are the sizes from the packet payloads. on outbound, the data has not been packetized yet, so you are indicated the whole amount passed to the socket call.

    If you need more bytes on inbound to act on, you can use the FWPS_STREAM_ACTION_NEED_MORE_DATA.  This flag will cause more data to be provided to the next callout invocation.

    http://msdn.microsoft.com/en-us/library/windows/hardware/ff570891(v=vs.85).aspx

    Hope this helps,


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------

    Thursday, January 9, 2014 3:42 AM
    Moderator