locked
Is Netbios bypassing the Stream layer? RRS feed

  • Question

  • My Filterdriver catches IN/OUTBOUND TCP and the TCP Stream Layer.
    When a host at port 139 is connected, i have following behaviour/events:

    Outgoing TCP connection for port 139
    Classify_ALE_AUTH_CONNECT_V4 DBG_DEBUG3 remote fs access layerData=0x0
    Classify_ALE_AUTH_CONNECT_V4 DBG_NETWORK local=172.017.004.225:49197 remote=172.017.003.005:139 protocol=6 flags=0x0 pid=4

    Reauthorizing
    Classify_ALE_AUTH_CONNECT_V4 DBG_DEBUG3 remote fs access layerData=0x0
    Classify_ALE_AUTH_CONNECT_V4 DBG_NETWORK local=172.017.004.225:49197 remote=172.017.003.005:139 protocol=6 flags=0x4 pid=4 process=Systemprocess=System

    This is the first of the three-packet TCP handshake, e.g. SYNC sent to remote host
    Classify_OUTBOUND_TCP_V4 DBG_TRANSPORT local=172.017.004.225:49197 remote=172.017.003.005:139 protocol=6 flags=0x0 length=32(120) TR
        0000  C02D008B 91EF440F 00000000 80022000  .-....D....... .
        0010  00000000 020405B4 01030308 01010402  ................
         Data <NULL>

    The second step of TCP establishment, SYNC-ACK received from remote host
    Classify_INBOUND_TCP_V4 DBG_TRANSPORT local=172.017.004.225:49197 remote=172.017.003.005:139 protocol=6 flags=0x0 length=0(52) TR
        0000  008BC02D 6458EF55 91EF4410 80122000  ...-dX.U..D... .
        0010  04910000 020405B4 01030308 01010402  ................
         Data <NULL>

    Flow established
    03/27/2008-15:45:03.148 0004:0052 CNetworkFilter::Classify_ALE_FLOW_ESTABLISHED_V4 DBG_NETWORK local=172.017.004.225:49197 remote=172.017.003.005:139, protocol=6, process=System flow=1068
    03/27/2008-15:45:03.148 0004:0052 CNetworkFilter::Classify_ALE_FLOW_ESTABLISHED_V4 DBG_DEBUG3 remote fs access layerData=0x0

    The last step of TCP establishment, send ACK to remote host. As you can see, this packet contains TCP Data. A callout function at the stream layer was never called for this data, so i believe there is a way to bypass the stream layer. I think, every TCP payload must be reflected at the stream layer, so this behaviour is at least strange (or a bug).
    Classify_OUTBOUND_TCP_V4 DBG_TRANSPORT local=172.017.004.225:49197 remote=172.017.003.005:139 protocol=6 flags=0x0 length=92(192) TR
        0000  C02D008B 91EF4410 6458EF56 50180100  .-....D.dX.VP...
        0010  00000000                             ....
         Data
        0000  81000044 20454E45 42464346 44434143  ...D ENEBFCFDCAC
        0010  41434143 41434143 41434143 41434143  ACACACACACACACAC
        0020  41434143 41002046 47454A45 45454246  ACACA. FGEJEEEBF
        0030  43434143 41434143 41434143 41434143  CCACACACACACACAC


    For normal connections (WebBrowsers, telnet) i never saw that the third packet of the TCP establishment carries any data.

    Can Microsoft confirm this behaviour and will it be fixed?

    Bye for now, Jens



    Thursday, March 27, 2008 3:06 PM

Answers

  • Hi Jens,

     

    I can confirm this is a bug in the interaction between the TCP/IP Stack and WFP which causes us not delivering the first TCP data segment to STREAM layer for certain style of socket applications.

     

    Please contact Microsoft PSS if a hotfix is needed.

     

    Thank you for reporting this issue to us.

     

    Thanks,

    Biao.W.

     

     

    Monday, March 31, 2008 8:40 PM

All replies

  • Are you setting the FWP_CALLOUT_FLAG_CONDITIONAL_ON_FLOW flag when registering your STREAM callout?

     

    Thanks,

    Biao.W.

    Friday, March 28, 2008 3:00 AM
  • No, flags in structure FWPS_CALLOUT0 is zero.

    I know from Window XP a similar behaviour: Netbios (TCP Port 139) connections are established via TDI function calls, but when it comes to datatransfer the TDI function for sending data is not used.

    Jens.
    Friday, March 28, 2008 8:11 AM
  • Hi Jens,

     

    I can confirm this is a bug in the interaction between the TCP/IP Stack and WFP which causes us not delivering the first TCP data segment to STREAM layer for certain style of socket applications.

     

    Please contact Microsoft PSS if a hotfix is needed.

     

    Thank you for reporting this issue to us.

     

    Thanks,

    Biao.W.

     

     

    Monday, March 31, 2008 8:40 PM
  • Hi Biao,

    thanks for this Info.

    What is the Hotfix Number? I have to check if the hotfix solves my problems.

    Bye, Jens
    Tuesday, April 1, 2008 8:51 AM
  • Jens, I meant to say you will need to contact PSS to request a hotfix be developed.

     

    Thanks,

    Biao.W.

     

    Tuesday, April 1, 2008 2:40 PM