Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 616 through 630 (of 1,498 total)
  • Author
    Posts
  • in reply to: VirtNet in Windows 10 #9336
    Vadim Smirnov
    Keymaster

      Hmm, probably driver package have to be updated to support Windows 10. We will check and update the package if necessary.

      in reply to: 'Jumbo Frame' – 9000 bytes length frames #9335
      Vadim Smirnov
      Keymaster

        Question: What happens if, for whatever reason, all 1000 buffers are filled before a receiver calls ReadPacket(hDriver, &Request)?

        First, I have to note that part of this buffers (10% or 100 packets) is reserved and never placed into the adapter queue. So if packets queue grows up to 900 buffers (an example, if user mode application stops reading packets from the driver) then the driver stops placing followed packets into the queue. Instead it checks packets against loaded static filters and current adapter mode, if the packet should be passed then it is passed, if it should be dropped OR PLACED INTO THE QUEUE then is is DROPPED. Such driver behaviour allows to avoid network lock if user mode application is hangs. An example, in case of remote debugging you can set the static filter to pass TCP port 3389 (RDP) and even if you stop the filtering application in debugger (causing driver queue grow up to maximum size) you still won’t loose the RDP connection. Although, please note that all other network activity (except allowed explicitely by static filters) will be blocked.

        in reply to: 'Jumbo Frame' – 9000 bytes length frames #9330
        Vadim Smirnov
        Keymaster

          There are actually two different things by the link you posted, socket buffer size and winpcap buffer size. If your question is about WinpkFilter driver internal buffers then for Windows Vista and later driver preallocates 1000 buffers for 1514 bytes sized packets. This value is hardcoded (changing requires driver recompile) and can’t be changed from user mode application.

          in reply to: 'Jumbo Frame' – 9000 bytes length frames #9328
          Vadim Smirnov
          Keymaster

            It also requires driver recompilation with ‘#define MAX_ETHER_FRAME 9000’.

            in reply to: 'Jumbo Frame' – 9000 bytes length frames #9326
            Vadim Smirnov
            Keymaster

              Do you mean incoming jumbo frames?

              in reply to: 'Jumbo Frame' – 9000 bytes length frames #9324
              Vadim Smirnov
              Keymaster

                Yes, this is possible for your custom build.

                in reply to: 'Jumbo Frame' – 9000 bytes length frames #9320
                Vadim Smirnov
                Keymaster

                  Yes, this is a part of required changes, but it is not enough to change this definition in common.h and rebuild ndisapi.dll. In order to enable jumbo frames you also have to enable jumbo frames in winpkfilter driver and rebuild it.

                  in reply to: WinPkFilter/Wireshark(WinPcap) #9317
                  Vadim Smirnov
                  Keymaster

                    If you look at those packets closer then you will notice that TTL for each fllowed duplicated packet is decremented. Without going deep into details this behaviour is caused by single interface IP routing combined with loopback packet indications (required by Winpcap to collect packets). And thus there are several ways to fix it.

                    1) You can disable IP routing feature on the host by going to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters registry key and changing IPEnableRouter from 1 to 0. IP routing feature is required only for the Internet Gateway sample and it is enabled only if you install this sample. If you don’t need it for smething else then it is safe to disable.

                    2) You can drop re-routed packets in WinpkFilter application.

                    3) WinpkFilter has some filter flags to prevent loopback packet indications which are normally used in promiscuous mode. I have to check if these flags are applicable to this situation with single interface routing but this is another possible approach – just filter these packets out on the driver level.

                    in reply to: Traffic Shaper #9293
                    Vadim Smirnov
                    Keymaster

                      I think you can take a look at WAN Emulator sample code. The part responsible for packet delay is very similar to what you need to do to implement bandwidth limiter.

                      WAN Emulator (PacketDelayerLayer.cpp) has two packet queues, one for incoming packets and another for outgoing. All intercepted packets first are placed into these queues and sent out from these queues by two dedicated threads after delaying packets for the specified number of milliseconds.

                      To limit bandwidth for the specified IP address you should do very similar things by queueing packets, but instead of delaying each packet for the fixed amount of milliseconds you should first calculate the time passed since last send operation, then calculate the amount of data which would be passed for the particular IP address during this time using you bandwidth limit parameter and then send out as many packets as it fits into the calculated amount of bytes.

                      Hope it helps…

                      in reply to: NDISWANIP #9290
                      Vadim Smirnov
                      Keymaster

                        Yes, in Windows 10 it is a little bit trickier to identify NDISWANIP interface and yes, you are right I have to update ListAdapters sample.

                        However, it is not a complex task at all. in order to do this you have to enumerate subkeys of the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}. Each subkey represents a network interface and the name of the subkey is the same as returned by WinpkFilter driver internal network interface name. For each network connection subkey you have to open ‘Connection’ subkey and check ‘PnPInstanceId’ value. If it is ‘SWD\MSRRAS\MS_NDISWANIP’ then this connection corresponds NDISWANIP connection under earlier versions of Windows.

                        Hope it helps…

                        in reply to: Query regarding socket #9286
                        Vadim Smirnov
                        Keymaster

                          WinpkFilter works at the NDIS level, while socket is a high level abstraction, also for some packets (an example, routed packets) there can be no socket object at all.

                          Also, is there any way to get process metadata(process name, pid etc) using winpkfilter?

                          Yes, there is a way. You can use IP helper API to query active connections from the system and use protocol/IP/port information to match the packet against the connection and figure out the originating process.

                          in reply to: Hi there, How i can change my Ip Address. #9285
                          Vadim Smirnov
                          Keymaster

                            Yes, besides changing the IP address you have to recalculate packet checksums. You can find some C++ sample code in the Internet Gateway. When doing NAT it changes source IP address and recalculates checksums.

                            in reply to: WinpkFilter news/updates. #9190
                            Vadim Smirnov
                            Keymaster

                              Windows Packet Filter Kit 3.2.7 released:

                              • Significantly improved driver performance for high speed networks.

                              If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

                              Your order ID.
                              An approximate date of purchasing.

                              in reply to: WinpkFilter news/updates. #9122
                              Vadim Smirnov
                              Keymaster

                                Windows Packet Filter Kit 3.2.6 released:

                                • Added special reserved pool for packets handled in kernel mode (these are packets which are not supposed to be redirected to user mode application for further processing: passed/blocked according loaded filters and collected from non-tunneled network interfaces). This feature seriously improves remote debugging capabilities for WinpkFilter based applications. An example, if you debug over RDP and your application load static filters to pass RDP connections prior putting network interface into the tunnel mode then you can safely put breakpoints in the packet processing thread, suspend it, analyze individual packets without a risk to be disconnected.
                                • Fixed Visual Studio 2015 compiler errors when building WinpkFilter NDIS 6.x Lightweight Filter drivers

                                If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

                                1. Your order ID.
                                2. An approximate date of purchasing.
                                in reply to: WinpkFilter news/updates. #5520
                                Vadim Smirnov
                                Keymaster

                                  Windows Packet Filter 3.2.5 released:

                                  • Fixed NDIS-hooking driver on Windows XP crash
                                  • Fixed issue with NDIS Lightweight Filter driver (driver bypassed some packets without analyses in low memory resources state)

                                  If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

                                  1. Your order ID.
                                  2. An approximate date of purchasing.
                                Viewing 15 posts - 616 through 630 (of 1,498 total)