Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 949 total)
  • Author
    Posts

  • Vadim Smirnov
    Moderator

    P.S. I was a little bit confused about your claim regarding code signing certificates costs, but yes, if you tried to order directly from the main page then it is a kind of expensive. However, if you try this link then you might be pleasantly surprised. 🙂

    • This reply was modified 2 days, 6 hours ago by  Vadim Smirnov.

    Vadim Smirnov
    Moderator

    Well, yes, this is an option. However, it won’t protect if any other applications using standard winpkfilter build are running.

    By the way we can sign your custom build with our code-signing certificate. Some of the customers prefer this option not only because of certificate costs but mostly because a relatively complex driver signing process.


    Vadim Smirnov
    Moderator

    Hmm, interesting question and I’m afraid I don’t have a quick answer. Inspecting all active processes for the open driver handle does not look a good idea. However, I think such functionality could be added to the driver itself, an example store the driver opened handles counter in the registry.

    Still, I’m not sure that this type of functionality is really needed though, normally you should tie your NAT application with custom driver build. In this situation your NAT application always knows if it uses the driver or not while no other application are aware about the custom driver build therefore can’t use the driver.

    in reply to: InternetGateway on Win10: DNS reply has invalid UDP cksum #11037

    Vadim Smirnov
    Moderator

    Yes, you are right, it is bug. You should add UDP checksum recalculation in two places:

    //DNS hook
    //If we receive DNS packet on the NAT client adapter then we redirect it 
    //to this system configured DNS server
    if((pDlg->m_DNSIp.S_un.S_addr != INADDR_ANY) && (pDlg->m_DNSIp.S_un.S_addr != INADDR_NONE))
    {
        if ((hAdapters[dwIndex]->m_NATState == CLIENT)&&
        (PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_RECEIVE))
        {
            if (ntohs(pUdpHeader->th_dport) == 53/*DNS port*/)
            {
                // Save the DNS IP used by the NAT client system
                hAdapters[dwIndex]->m_LocalDNS.S_un.S_addr = ntohl(pIpHeader->ip_dst.S_un.S_addr);
                
                pIpHeader->ip_dst.S_un.S_addr = pDlg->m_DNSIp.S_un.S_addr;
            
                if(bForceRouting) 
                {
                    bNeedToBeRouted = pDlg->IsNeedToForceRouting(pEthHeader->h_dest, pIpHeader->ip_dst.S_un.S_addr, pProviderCard->m_Index);
                }
    
                RecalculateUDPChecksum(&PacketBuffer);
                RecalculateIPChecksum (&PacketBuffer);
            }
        }
    
        // DNS reply came, substitute source IP back to the original DNS address
        if ((hAdapters[dwIndex]->m_NATState == CLIENT)&&
            (PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_SEND))
        {
            if (ntohs(pUdpHeader->th_sport) == 53/*DNS port*/)
            {
                pIpHeader->ip_src.S_un.S_addr = htonl(hAdapters[dwIndex]->m_LocalDNS.S_un.S_addr);
                RecalculateUDPChecksum(&PacketBuffer);
                RecalculateIPChecksum (&PacketBuffer);
            }
        }
    }

    Internet Gateway is a very old sample and I have a newer NAT library implementation (not available for public though) where surprisingly this bug was already fixed.

    in reply to: Which process sent the UDP packet? #11033

    Vadim Smirnov
    Moderator

    Although sendto() can be called on unbound socket according MSDN “If the socket is unbound, unique values are assigned to the local association by the system, and the socket is then marked as bound”. So, I suspect that this is equivalent to calling bind explicitly. However, worth to test to ensure.

    in reply to: Which process sent the UDP packet? #11031

    Vadim Smirnov
    Moderator

    You can use GetExtendedUdpTable to find the dwLocalAddr:dwLocalPort to dwOwningPid association and then if necessary call GetOwnerModuleFromUdpEntry with TCPIP_OWNER_MODULE_INFO_BASIC to obtain pModuleName and pModulePath.

    in reply to: msi installer 3.2.18.1 x64 on WIN 8.1 #11025

    Vadim Smirnov
    Moderator

    Installers were fixed for Windows 8.1

    in reply to: msi installer 3.2.18.1 x64 on WIN 8.1 #11022

    Vadim Smirnov
    Moderator

    Thanks for reporting this. Difficult to say before testing but probably it is somehow related to detected Windows version…

    Update: from what I can see installer installs the wrong driver version on Windows 8.1. Instead installing Windows 8 driver it installs Windows 10 driver. This behavior is caused by that fact that both Windows 8.1 and Windows 10 have VersionNT value set to 603 and this requires a sort of workaround:

    https://support.microsoft.com/en-ie/help/3202260/versionnt-value-for-windows-10-and-windows-server-2016

    • This reply was modified 2 months, 4 weeks ago by  Vadim Smirnov.
    in reply to: Clone of ETH_REQUEST #10981

    Vadim Smirnov
    Moderator

    For C# (and other .NET languages) it is recommended to use .NET C++/CLI class library (source code available on GitHub).

    The TestDotNet project (more advanced version of PassThru) demonstrates the usage of the above-mentioned class library.

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10642

    Vadim Smirnov
    Moderator

    Is it possible to drop limitation #3, so we can use any mac address.

    Yes, sure, it is possible. I also wanted to make few more adjustments to this new driver. Will add it this to the list.

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10640

    Vadim Smirnov
    Moderator

    Always glad to help 🙂

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10638

    Vadim Smirnov
    Moderator

    You have not paid enough attention to my previous post mentioning locally administered MAC address requirement. You can read a little more on this here. In you case addr[0] = 0x74 and it does not meet the condition to be locally administered MAC address. You can use 0x72, 0x76, 0x7A or 0x7E instead.

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10633

    Vadim Smirnov
    Moderator

    OK, I have added NetworkAddress property. You can download the updated driver using the same link

    Though please note that in this build assigning the network adapter hardware address has a few limitations:

    1) It should not be multicast address (addr[0] & 0x01 == 0)
    2) It should not be broadcast address (FF-FF-FF-FF-FF-FF)
    3) It should be marked as assigned by the local administrator (addr[0] & 0x2 == 1)

    Example of valid address is 06-01-02-03-04-05

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10630

    Vadim Smirnov
    Moderator

    I’ve created a quick NDIS 6.0 replacement for the original VirtNet driver. You can download it from here. Let me know how it worked for you…

    in reply to: VirtNet does not install on Windows 10 version 1809 x64 #10629

    Vadim Smirnov
    Moderator

    I have devoted some time over the weekend to this issue, but I still don’t have a good idea what was changed by an update and how to fix this. It is definitely not about driver signing because that phase is passed fine. And setupapi.dev.log does not contain any helpful information:

    >>>  [Device Install (DiInstallDevice) - ROOT\NET\0000]
    >>>  Section start 2019/02/04 11:53:39.838
          cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
         ndv: Flags: 0x00000004
         dvi: {Plug and Play Service: Device Install for ROOT\NET\0000}
    !    dvi:      Installing NULL driver!
         dvi:      {DIF_ALLOW_INSTALL} 11:53:39.858
         dvi:           Default installer: Enter 11:53:39.858
         dvi:           Default installer: Exit
         dvi:      {DIF_ALLOW_INSTALL - exit(0xe000020e)} 11:53:39.862
         dvi:      {DIF_REGISTER_COINSTALLERS} 11:53:39.862
         dvi:           Default installer: Enter 11:53:39.862
         dvi:           Default installer: Exit
         dvi:      {DIF_REGISTER_COINSTALLERS - exit(0x00000000)} 11:53:39.866
         dvi:      {DIF_INSTALLDEVICE} 11:53:39.866
         dvi:           Default installer: Enter 11:53:39.866
    !    dvi:                Installing NULL driver!
         dvi:                Install Null Driver: Removing device sub-tree. 11:53:39.870
         dvi:                Install Null Driver: Removing device sub-tree completed. 11:53:39.874
         dvi:                Install Null Driver: Restarting device. 11:53:39.878
         dvi:                Install Null Driver: Restarting device completed. 11:53:39.882
         dvi:                Install Device: Configuring device class. 11:53:39.882
         dvi:                Install Device: Configuring device class completed. 11:53:39.882
         dvi:                Device Status: 0x01802401, Problem: 0x1c (0x00000000)
         dvi:                Install Device: Starting device 'ROOT\NET\0000'. 11:53:39.886
         dvi:                Install Device: Starting device completed. 11:53:39.894
         dvi:           Default installer: Exit
         dvi:      {DIF_INSTALLDEVICE - exit(0x00000000)} 11:53:39.898
         ump: {Plug and Play Service: Device Install exit(00000000)}
    <<<  Section end 2019/02/04 11:53:39.910
    <<<  [Exit status: SUCCESS]
    
    >>>  [Delete Device - ROOT\NET\0000]
    >>>  Section start 2019/02/04 11:59:51.125
          cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
         dvi: Query-and-Remove succeeded
    <<<  Section end 2019/02/04 11:59:51.133
    <<<  [Exit status: SUCCESS]

    Mentioned Problem: 0x1c is CM_PROB_FAILED_INSTALL for which I could find anything helpful besides https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-failed-install

    The only solution I can see so far would be creating a new NDIS 6 virtual network adapter driver…

Viewing 15 posts - 1 through 15 (of 949 total)