none
Windows 8 Logo testing problems with WFP kernel driver RRS feed

  • Question

  • Hello,

    We are getting several errors when running the Windows 8 logo tests for our WFP driver, and we suspect they might be caused by an incorrect WFPLogo.Info.txt file, but we are not quite sure about it.

    Overall we have plenty of doubts about the certification criteria and we would like to ask for some clarifications.

    Our module is a callout kernel driver, which we use just for monitoring and information retrieval; this means that we do not inject packets, nor modify buffers: only retrieval of some metadata.

    So these are some of our questions:

    - Is it necessary a NDF for certification? We know that the NDF must be in User-mode, but we want to certify a kernel driver.

    - How does it work the "WFPLogo.Info.txt" ? What should we activate for a simple (almost passthrough) monitoring driver?

    - Our driver is not a firewall, so we understand that we need to make "IsAFirewall" FALSE, but then why is it still doing firewall tests?

    - Is there any extended documentation or reference about all this, besides what is shown at http://msdn.microsoft.com/en-us/library/windows/hardware/hh748200.aspx ?

    - Lot of certification errors are so ambiguous that we don't know their meaning, is there any way of getting extended info about them?

    - Is it necessary to include a filter, when we aren't doing any filtering? And if not, how can we configure the test in order to not run the filter test?

    Thanks a lot in advance!

    Thursday, November 15, 2012 3:44 PM

Answers

  • NDF is only a requirement if you BLOCK any traffic.  If you install the WHCK's QFE's, this behavior for the tests will be present if you install QFE Update 005 http://msdn.microsoft.com/en-us/windows/hardware/jj553782#update

    The info file is a way to gather further information about your callout driver.  You need to tailor it to your driver's behavior.  i.e. If you do not block any traffic, then set "IsAFirewall = 0;"  QFE 005 also addresses drivers that are not firewall centric.  The tests will still run, however many will short circuit.  The exception is the PowerManagement suite, which will still run with the assumption that all traffic will be allowed.

    Additionally documentation is in the help file for the WHCK.  This has basic explanations of the info file and answer file.

    What errors are you seeing?  Most errors that we have seen are because the proper action is not happening to the traffic...

    No need for adding filters you are not going to ship.  install QFE 005, and I'd wager your certification pass will be much happier.

    Hope this helps,


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

    Monday, November 19, 2012 4:26 PM
    Moderator
  • There is an issue where if the validate test fails, none of the other tests will run.  To remedy this, you will need to modify the job (until QFE 7 is released in December).

    Open the HCK Manager.  Drill down to $\SoftwareDevice\FilterDriver\WindowsFilteringPlatform\.  Edit Job “WindowsFilteringPlatform_Tests”.  Under Tasks tab > Setup tab, edit “RunJob – Validate – WFP Usage”. under Failure action select FailAndContinue.  Save.

    Can you send me the log for the validate case? %WinDir%\System32\Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.Validate.WFPUsage.NTLog to  DHarper@AT@Microsoft.DOT.Com.  When you send this, please send me a high overview of what your product does.  The Validate usage has several purposes, and one is to flag unexpected usages of WFP.  (Just because it's unexpected, doesn't mean it's not supported, we just need to know how its being used so we can enhance our HCK content).

    No the answer file is not mandatory.

    If you are not a firewall, then so long as you don't tamper with Windows Firewall running, this will pass.

    "NoPermitBlockAll" really applies to firewalls.  as an inspection filter, you should be returning only FWP_ACTION_CONTINUE.

    As for most of the support reqs, if you read the actual requirement, they state essentially that these features can be made to work in the presence of your product, so answering TRUE to these is expected.

    Hope this helps,


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

    Wednesday, November 21, 2012 5:44 PM
    Moderator
  • If you specify IsAFirewall = 0; Then many of the tests are short circuited because they don't apply to your product.

    The context behind the "If you are not a firewall, then so long as you don't tamper with Windows Firewall running, this will pass." statement was in response to the "ProperlyDisableWindowsFirewall" question.  This tests checks that Windows Firewall is running as well as MPSSvc.  If it is not, then it checks to see if the firewall network category was taken.  tamper means either disabling the Windows Firewall (not taking the firewall category) or stopping / disabling the MPSSvc service.

    The requirement reads

    Host firewalls are provided the ability to selectively turn parts of Windows Firewall on or off. These parts specify different types of rules (and subsequently filter sets), and may also be referred to as categories. Filter sets that may be selectively turned off are Boot-Time Filters, Firewall Filters, Connection Security Filters, and Stealth Filters.
    
    The Register interface is supported by the HNetCfg.FwProducts COM object. The put_DisplayName()call must be used to fill in your product information. Before turning off the firewall rules category, vendor firewalls must ensure that all filters must be installed.This requirement ensures better interoperability with Windows. In addition, if all installed host firewalls on the system are uninstalled for any reason, Windows Firewall is aware of this, and will automatically turn on the firewall filters, ensuring that the system is always protected. The Connection Security filters need to remain enabled to keep Windows scenarios protected. Specifically, the Connection Security filters ensure that the system supports communications which require authentication and encryption

    Now this is not to say that you may need to add some Windows Firewall policy to get through the tests.  For example, the PowerManagedStates test will be limited to only PERMIT cases for non-firewall products, but Windows Firewall will block unsolicited incoming packets by default.  You can handle this in different ways, either plumbing the policy via the answer file, or create a Windows Firewall exception before the tests run to allow all traffic from %WinDir%\System32\WFPLogo.exe

    As to your (direct) question, it doesn't matter whether the other answer file entries are blank, or left populated, as they will never be run (due to the short circuiting of the tests mentioned above).  You would care only about the ArchitecturalDesign.PacketInjection.NoDeadlocks. entries in the answer file.

    Hope this helps,


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


    Monday, January 13, 2014 11:09 PM
    Moderator

All replies

  • NDF is only a requirement if you BLOCK any traffic.  If you install the WHCK's QFE's, this behavior for the tests will be present if you install QFE Update 005 http://msdn.microsoft.com/en-us/windows/hardware/jj553782#update

    The info file is a way to gather further information about your callout driver.  You need to tailor it to your driver's behavior.  i.e. If you do not block any traffic, then set "IsAFirewall = 0;"  QFE 005 also addresses drivers that are not firewall centric.  The tests will still run, however many will short circuit.  The exception is the PowerManagement suite, which will still run with the assumption that all traffic will be allowed.

    Additionally documentation is in the help file for the WHCK.  This has basic explanations of the info file and answer file.

    What errors are you seeing?  Most errors that we have seen are because the proper action is not happening to the traffic...

    No need for adding filters you are not going to ship.  install QFE 005, and I'd wager your certification pass will be much happier.

    Hope this helps,


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

    Monday, November 19, 2012 4:26 PM
    Moderator
  • Hi Dusty, thanks for your answers.

    We have reduced the error count, but we are still getting some, even after having installed QFE 005 and 006.

    Our driver is not a firewall, so our callout types are only INSPECTION, we never block or deny. 
    That's why we set the "IsAFirewall" option to zero, but if we set the "Support" options to zero, then we get errors for those options; so, as we understand, we must set those settings to 1.

    We are getting the following errors:

    On the "WFP" category:
    - Failed the Job "WindowsFilteringPlatform_Tests" (Task "RunJob - Validate - WFP Usage" Failed)

    (it's worth noting that this error appears always, no matter what the value of "UseWFP" is)

    On the "AppContainers" category:
    - Failed the Job "AppContainers_Tests" (Task "RunJob - REQ - WFP-based products must not block App Container apps operating within their declared network intentions by defaul" Failed)

    This is the content of our info file (only the options, without comments or anything else):

       UseAnswerFile = 0;

       CalloutDriver = 1;
       IsAFirewall = 0;
       LayeredOnMicrosoftWindowsFirewall = 0;
       DoesMACFiltering = 0;
       DoesVSwitchFiltering = 0;
       DoesPacketInjection = 0;
       DoesStreamInjection = 0;
       DoesConnectionProxying = 0;

       SupportModernApplications = 1;
       CleanUninstall = 1;
       NoProxyDeadlocks = 0;
       IdentifyingProvider = 1;
       AssociateProvider = 1;
       TerminatingFilter = 0;
       UseOwnSubLayer = 1;
       MaintainHelperClass = 0;
       NoAVs = 1;
       NonTampered3rdPartyObjects = 1;
       NoPacketInjectionDeadlocks = 0;
       NoStreamStarvation = 0;
       SupportPowerManagement = 1;
       WFPObjectEnumAndACLs = 1;
       MaxWinSock = 1;
       ProperlyDisableWindowsFirewall = 1;
       NoPermitBlockAll = 1;
       SupportTupleExceptions = 0;
       SupportAppExceptions = 0;
       SupportMACAddressExceptions = 0;
       UseWFP = 1;
       SupportARP = 1;
       SupportNeighborDiscovery = 1;
       SupportDHCP = 1;
       SupportIPv4 = 1;
       SupportIPv6 = 1;
       SupportDNS = 1;
       Support6To4 = 1;
       SupportAutomaticUpdates = 1;
       SupportBasicWebsiteBrowsing = 1;
       SupportFileAndPrinterSharing = 1;
       SupportICMPErrorMesages = 1;
       SupportInternetStreaming = 1;
       SupportMediaExtenderStreaming = 1;
       SupportMobileBroadBand = 1;
       SupportPeerNameResolution = 1;
       SupportRemoteAssistance = 1;
       SupportRemoteDesktop = 1;
       SupportTeredo = 1;
       SupportVirtualPrivateNetworking = 1;
       InteropWithOtherExtensions = 0;
       NoEgressModification = 0;
       SupportLiveMigration = 0;
       SupportRemoval = 0;
       SupportReordering = 0;

    Please alto note that we have 43 "not run" tests. Is it normal for this info file?
    So, any ideas about how to fix those errors?

    A few more doubts:


    - Answer file, is it mandatory?
    - The description for the "ProperlyDisableWindowsFirewall" test leads to think that we must support it, even if we are not a true firewall. Is it mandatory for every WFP driver, firewall or not?
    - Same thing with the "NoPermitBlockAll" test, should be supported by a non-firewall filter?

    Thanks a lot for your help!



    Wednesday, November 21, 2012 4:23 PM
  • There is an issue where if the validate test fails, none of the other tests will run.  To remedy this, you will need to modify the job (until QFE 7 is released in December).

    Open the HCK Manager.  Drill down to $\SoftwareDevice\FilterDriver\WindowsFilteringPlatform\.  Edit Job “WindowsFilteringPlatform_Tests”.  Under Tasks tab > Setup tab, edit “RunJob – Validate – WFP Usage”. under Failure action select FailAndContinue.  Save.

    Can you send me the log for the validate case? %WinDir%\System32\Filter.Driver.WindowsFilteringPlatform.ArchitecturalDesign.Validate.WFPUsage.NTLog to  DHarper@AT@Microsoft.DOT.Com.  When you send this, please send me a high overview of what your product does.  The Validate usage has several purposes, and one is to flag unexpected usages of WFP.  (Just because it's unexpected, doesn't mean it's not supported, we just need to know how its being used so we can enhance our HCK content).

    No the answer file is not mandatory.

    If you are not a firewall, then so long as you don't tamper with Windows Firewall running, this will pass.

    "NoPermitBlockAll" really applies to firewalls.  as an inspection filter, you should be returning only FWP_ACTION_CONTINUE.

    As for most of the support reqs, if you read the actual requirement, they state essentially that these features can be made to work in the presence of your product, so answering TRUE to these is expected.

    Hope this helps,


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

    Wednesday, November 21, 2012 5:44 PM
    Moderator
  • No the answer file is not mandatory.

    If you are not a firewall, then so long as you don't tamper with Windows Firewall running, this will pass.

    Ok, the answer file is not mandatory but I would like to use it to script (automate) the one case I do have to manually configure something:   the Injection case.

    My driver too is *not a firewall* and it does not disable the Windows Firewall.

    So for all of the other cases in the answer file that do not map to something I need to do relative to my driver/product, should those answer entries be:

    a) Blank

    b) The command that the HCK populates in the sample (e.g. netsh <blah>) to manipulate the Windows Firewall

    c) something else?

    It seems like (b) is incongruous with your statement  "then so long as you don't tamper with Windows Firewall running, this will pass".

    What does 'tamper' mean?   Are the commands from the 'default' WfpLogo.Answer tampering or required?

    Thanks


    Dave Cattley

    Monday, January 13, 2014 7:58 PM
  • If you specify IsAFirewall = 0; Then many of the tests are short circuited because they don't apply to your product.

    The context behind the "If you are not a firewall, then so long as you don't tamper with Windows Firewall running, this will pass." statement was in response to the "ProperlyDisableWindowsFirewall" question.  This tests checks that Windows Firewall is running as well as MPSSvc.  If it is not, then it checks to see if the firewall network category was taken.  tamper means either disabling the Windows Firewall (not taking the firewall category) or stopping / disabling the MPSSvc service.

    The requirement reads

    Host firewalls are provided the ability to selectively turn parts of Windows Firewall on or off. These parts specify different types of rules (and subsequently filter sets), and may also be referred to as categories. Filter sets that may be selectively turned off are Boot-Time Filters, Firewall Filters, Connection Security Filters, and Stealth Filters.
    
    The Register interface is supported by the HNetCfg.FwProducts COM object. The put_DisplayName()call must be used to fill in your product information. Before turning off the firewall rules category, vendor firewalls must ensure that all filters must be installed.This requirement ensures better interoperability with Windows. In addition, if all installed host firewalls on the system are uninstalled for any reason, Windows Firewall is aware of this, and will automatically turn on the firewall filters, ensuring that the system is always protected. The Connection Security filters need to remain enabled to keep Windows scenarios protected. Specifically, the Connection Security filters ensure that the system supports communications which require authentication and encryption

    Now this is not to say that you may need to add some Windows Firewall policy to get through the tests.  For example, the PowerManagedStates test will be limited to only PERMIT cases for non-firewall products, but Windows Firewall will block unsolicited incoming packets by default.  You can handle this in different ways, either plumbing the policy via the answer file, or create a Windows Firewall exception before the tests run to allow all traffic from %WinDir%\System32\WFPLogo.exe

    As to your (direct) question, it doesn't matter whether the other answer file entries are blank, or left populated, as they will never be run (due to the short circuiting of the tests mentioned above).  You would care only about the ArchitecturalDesign.PacketInjection.NoDeadlocks. entries in the answer file.

    Hope this helps,


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


    Monday, January 13, 2014 11:09 PM
    Moderator
  • Thanks Dusty.

    I did a test run with all commands left as they are in the answer file as defaults except for the injection commands which I updated to operate my driver as necessary.

    I did not add any exception for WFPLogo.exe.   I am unclear from your comments above if that is 'required' to complete the tests or not (in my case).

    The result of that run is that all but ArchitecturalDesign.SupportPowerManagedStates pass.

    The WFPLogo.wtl suggests that I am failing IPv4 Inbound TCP and IPv6 Inbound UDP.

    You have given me a 'clue' on how to try addressing this by adding a exception for WFPLogo.exe prior to running the test.

    Why does the test itself not make this step in the case of the 'shortcut' if Windows Firewall is

    a) Known to be on (and required and validated by the test)

    b) The test cannot possibly pass unless Windows Firewall is also conditioned to permit the inbound traffic.

    Did I miss some documented step in the HCK guide that says to add an exception for WFPLogo.exe?

    Thanks.


    Dave Cattley

    Tuesday, January 14, 2014 4:26 PM
  • There are so many variations and one offs that it was easiest just to have the user configure it. For example there are scenarios where someone is configured to be layered on top of Windows Firewall, telling WF what rules to plumb.  If we automatically plumbed the rules, then we are potentially missing a scenario for those consumers.

    No the documentation does state that if you are running with a firewall (aside from your product), that you will need to configure rules for it as well.

    If you are configured to use the answer file, then you can tweak it so that WIndows Firewall plumbs the policy for you.  Again because you are setting IsAFirewall = 0;, there are only 4 variations for the PowerManaged states and all of them are PERMIT, so you'd need to tweak the answer file appropriately.

    Hope this helps,


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

    Tuesday, January 14, 2014 10:33 PM
    Moderator
  • Thanks.   I am under the impression that I did just those steps.

    My product does not interfere with any of the traffic selections for those tests.

    My WFPLogo.Answer adds the commands for injection tests (which my product does do) and leaves the power managed states commands as they were in the sample WFPLogo.Answer like this:

    ###################################
    # ArchitecturalDesign.PacketInjection.NoDeadlocks
       numPacketInjectionCommands = 1;

    # ArchitecturalDesign.PacketInjection.NoDeadlocks.1
       LOGO_ADD    = %WinDir%\System32\mydriver-wfplogo\do-inject add mydriver\wfplogo %DIRECTION% %IP_VERSION% %LOCAL_IP% %REMOTE_IP% ;
       LOGO_DELETE = %WinDir%\System32\mydriver-wfplogo\do-inject delete mydriver\wfplogo ;

    # ArchitecturalDesign.PacketInjection.NoDeadlocks.2
       LOGO_ADD    = ;
       LOGO_DELETE = ;

    # ArchitecturalDesign.PacketInjection.NoDeadlocks.3
       LOGO_ADD    = ;
       LOGO_DELETE = ;

    # ...

    ###################################
    # ArchitecturalDesign.SupportPowerManagedStates.1
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Outbound IPv4 with Power States" Dir=Out Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                      Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.2
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Block Outbound IPv4 with Power States" Dir=Out Action=block Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.3
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Inbound IPv4 with Power States" Dir=In Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.4
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Block Inbound IPv4 with Power States" Dir=In Action=block Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                    Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.5
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Outbound IPv6 with  Power States" Dir=Out Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                       Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.6
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Block Outbound IPv6 with Power States" Dir=Out Action=block Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.7
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Inbound IPv6 with Power States" Dir=In Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    # ArchitecturalDesign.SupportPowerManagedStates.8
       LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Block Inbound IPv6 with Power States" Dir=In Action=block Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
       LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                    Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;

    ###################################

    And yet I get failure in the power-managed tests.   The NETSH commands from the sample WFPLogo.Answer look perfectly reasonable and correct to me.   I'm not sure what 'tweaking' is going to help.

    Thanks.

    -dave


    Dave Cattley

    Wednesday, January 15, 2014 3:57 PM
  • The default answer file has 8 variations for the SupportPowerManagedStates (.1 - .8).  When you specify "IsAFirewall = 0;", the test will only have 4 tests (.1 - .4).  In addition, all 4 of those tests are PERMIT cases.  To tweak your answer file you simply need to delete out the existing .2, .4, .6, .8 answers, and then renumber (.3 becomes .2, .5 becomes .3, and .7 becomes .4)

    # ArchitecturalDesign.SupportPowerManagedStates.1
        LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Outbound IPv4 with Power States" Dir=Out Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
        LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                      Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;
    
    # ArchitecturalDesign.SupportPowerManagedStates.2
        LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Inbound IPv4 with Power States" Dir=In Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
        LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;
    
    # ArchitecturalDesign.SupportPowerManagedStates.3
        LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Outbound IPv6 with  Power States" Dir=Out Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
        LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                       Dir=Out              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;
    
    # ArchitecturalDesign.SupportPowerManagedStates.4
        LOGO_ADD    = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Add    Rule Name="WFPLogo" Description="Permit Inbound IPv6 with Power States" Dir=In Action=allow Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL% Enable=Yes Profile=Any;
        LOGO_DELETE = %WinDir%\System32\NetSh.exe AdvFirewall Firewall Delete Rule Name="WFPLogo"                                                     Dir=In              Program=%APPLICATION% LocalIP=%LOCAL_IP% RemoteIP=%REMOTE_IP% Protocol=%PROTOCOL%            Profile=Any;
    

    Hope this helps,


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

    Wednesday, January 15, 2014 5:31 PM
    Moderator
  • I am now running the tests manually so that I can observe the detailed output in WFPLogo.

    I notice that when the command from the answer file is echoed in the WFPLogo window, all parameters *except* %REMOTE_IP% have had some meaningful substitution applied to them.

     

    %REMOTE_IP% is shown literally.    As if it is not the correct name or some such.

    So my command in the answer file:

       LOGO_ADD    = %WinDir%\System32\mydriver-wfplogo\do-inject add    mydriver\wfplogo %DIRECTION% %IP_VERSION% %LOCAL_IP% %REMOTE_IP% ;

    Is shown as

    run cmd.exe /c "%WinDir%\System32\mydriver-wfplogo\do-inject add mydriver\wfplogo OUT 4 1.0.0.1 %REMOTE_IP% "

    Why is %DIRECTION% %IP_VERSION% %LOCAL_IP% translated but %REMOTE_IP% is not?

    Is %REMOTE_IP% the correct 'form' for this parameter?


    Dave Cattley

    Wednesday, January 15, 2014 9:12 PM
  • This is not expected behavior.  I am investigating and will let you know. 

    Thanks,


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

    Wednesday, January 15, 2014 10:43 PM
    Moderator
  • It seems that whatever the last substitution parameter is in the command is not processed correctly.   I added a 'dummy' at the end of the command by putting the argument %PROTOCOL% after the %REMOTE_IP%.   Since my command does not care about %PROTOCOL% whatever WFPLogo supplies in that argument position is just ignored.

    The translated command line now has the correct IP address substituted in the argument position where %REMOTE_IP% is specified and the 'bug' is moved to the irrelevant %PROTOCOL% argument specified last.

    Evidently WFPLogo has trouble with the last argument.

    Effective work-around is to add an extra unnecessary argument for it to fail on that does not matter.


    Dave Cattley

    Thursday, January 16, 2014 6:34 PM
  • I have a local repro and am investigating the issue.  I do know from my repro that if you add 3 or more spaces between the last variable and the semicolon, the replacement seems to happen just fine.

    Thanks,


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


    Thursday, January 16, 2014 7:58 PM
    Moderator
  • I have found and fixed the issue. The fix will be in an upcoming HCK package. 

    Thanks,


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

    Thursday, January 16, 2014 10:21 PM
    Moderator