Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 16 through 30 (of 1,499 total)
  • Author
    Posts
  • in reply to: Wiresock poor performance #13991
    Vadim Smirnov
    Keymaster

      Yes, I’ve tested WireSock on a 10Gbps connection, and it has demonstrated decent performance, even outperforming the official WireGuard client in my tests.

      Regarding high-load traffic, while WireSock processes packets before forwarding them to WireGuard, it is designed for efficiency. In practice, it handles substantial traffic loads well without becoming a bottleneck.

      However, I recommend testing WireSock on a clean machine with a well-known WireGuard profile—such as Cloudflare Warp—to rule out any potential software conflicts at the low network level that might impact performance.

      in reply to: Wiresock poor performance #13984
      Vadim Smirnov
      Keymaster

        WireSock CLI includes a built-in feature for capturing traffic and saving it as PCAP files.

        Certain components of WireSock are open source, such as BoringTun and NDISAPI, while others are proprietary but available for commercial licensing.

        in reply to: Wiresock poor performance #13981
        Vadim Smirnov
        Keymaster

          Normally, you would see the errors in the log. However, please avoid using debug logging during performance measurements.

          in reply to: Wiresock poor performance #13978
          Vadim Smirnov
          Keymaster

            I have a 400/400 Mbps connection. Here are the test results using WireSock with a Cloudflare Warp configuration and an MTU set to 1280:

            WireSock Virtual Adapter Mode
            WireSock Transparent Mode

            I recommend checking your MTU settings. Unlike the official WireGuard client for Windows, WireSock does not defragment fragmented WireGuard UDP packets for performance reasons. Therefore, it is crucial to use an appropriate MTU to avoid connectivity issues.

            Vadim Smirnov
            Keymaster

              Thank you for pointing that out. I made an incorrect assumption about the parameters, but I believe you understood the main idea correctly—when there are no packets to read, the packet events should be reset, and the thread should wait on them. I appreciate the clarification!

              Vadim Smirnov
              Keymaster

                The high CPU usage is likely due to the fact that the packet event is never reset. This causes the thread to continuously poll the driver without pausing.

                Solution:
                You need to reset the AutoResetEvent or ManualResetEvent in waitHandlesManualResetEvents after processing packets. This ensures the thread properly waits for new packets instead of running in a tight loop.

                Fixed Code:

                
                private static unsafe void PassThruUnsortedThread
                (
                    NdisApi filter,
                    WaitHandle[] waitHandles,
                    IReadOnlyList<AutoResetEvent> waitHandlesManualResetEvents)
                {
                    const int bufferSize = 32;
                    var buffers = new IntPtr[bufferSize];
                
                    for (int i = 0; i < buffers.Length; i++)
                    {
                        buffers[i] = (IntPtr)filter.CreateIntermediateBuffer();
                    }
                
                    while (true)
                    {
                        int eventIndex = WaitHandle.WaitAny(waitHandles);  // Wait for an event to be signaled
                
                        uint packetsSuccess = 0;
                
                        while (filter.ReadPacketsUnsorted(buffers, bufferSize, ref packetsSuccess))
                        {
                            for (int i = 0; i < packetsSuccess; i++)
                            {
                                EthernetPacket ethPacket = buffers[i].GetEthernetPacket(filter);
                                if (ethPacket.PayloadPacket is IPv4Packet iPv4Packet)
                                {
                                    if (iPv4Packet.PayloadPacket is TcpPacket tcpPacket)
                                    {
                                        // Console.WriteLine($”{iPv4Packet.SourceAddress}:{tcpPacket.SourcePort} -> {iPv4Packet.DestinationAddress}:{tcpPacket.DestinationPort}.”);
                                    }
                                }
                            }
                
                            if (packetsSuccess > 0)
                            {
                                filter.SendPacketsUnsorted(buffers, packetsSuccess, out uint numPacketsSuccess);
                            }
                        }
                
                        // Reset the event to allow proper waiting
                        if (eventIndex >= 0 && eventIndex < waitHandlesManualResetEvents.Count)
                        {
                            waitHandlesManualResetEvents[eventIndex].Reset();
                        }
                    }
                }
                

                Explanation:

                • Wait for an event: WaitHandle.WaitAny(waitHandles); ensures the thread only runs when a packet event is signaled.
                • Process packets normally: The loop reads packets, processes them, and sends them back.
                • Reset the event: After processing packets, waitHandlesManualResetEvents[eventIndex].Reset(); is called to prevent continuous polling.

                This should significantly reduce CPU usage.

                in reply to: local devices become unreacheable after some time #13970
                Vadim Smirnov
                Keymaster

                  Great! Thank you for the update! 👍

                  in reply to: amneziawg support #13963
                  Vadim Smirnov
                  Keymaster

                    I’m excited to announce that AmneziaWG support is now available in WireSock Secure Connect v2.1.4!

                    🔗 Download WireSock Secure Connect

                    in reply to: [Wiresock] Bugs and Feature Requests #13959
                    Vadim Smirnov
                    Keymaster

                      Thank you for your message! Let me clarify a few points:

                      Interface Name in Commands
                      Instead of using the placeholder %i, you can safely rely on the WIRESOCK_TUNNEL_NAME environment variable in your scripts and commands. This variable provides the actual Wiresock tunnel name at runtime, ensuring proper command execution.

                      Table = off Setting
                      Currently, Table = off is not supported by Wiresock. Could you let us know where you found this setting mentioned in the Wiresock documentation? If it’s listed somewhere, we’d like to correct that reference to prevent confusion.

                      If you have any additional questions or need further assistance, feel free to let me know!

                      in reply to: WinPkFilter 3.6 API documentation #13953
                      Vadim Smirnov
                      Keymaster

                        I apologize for not being able to update the documentation sooner—these past months have been incredibly busy. The key difference between versions 3.4 and 3.6 lies in the subset of extensions to the Static Filters API. These include the following new functions:

                        • AddStaticFilterFront
                        • AddStaticFilterBack
                        • InsertStaticFilter
                        • RemoveStaticFilter
                        • ResetPacketFilterTable
                        • EnablePacketFilterCache
                        • DisablePacketFilterCache
                        • EnablePacketFragmentCache
                        • DisablePacketFragmentCache

                        All these functions are documented inline in ndisapi.cpp. I will update the online documentation as soon as I have time.

                        in reply to: WireSock DNS is going over VPN (bug?) #13949
                        Vadim Smirnov
                        Keymaster

                          All DNS requests on Windows are resolved within the DNSCACHE process, making it impossible to identify the originating application.

                          in reply to: Winpkflt Rebind #13947
                          Vadim Smirnov
                          Keymaster

                            Yes, that’s exactly what I mean. This technique is implemented in the WireSock VPN Client’s Transparent mode to ensure that packets sent by the TCP stack fit within 1420 bytes.

                            in reply to: Winpkflt Rebind #13945
                            Vadim Smirnov
                            Keymaster

                              I would apply MSS clamping when relaying the TCP SYN packet from the Ethernet to the WireGuard interface. If issues persist despite the MSS clamping, I recommend recording the processed traffic (see the capture example) and analyzing it in Wireshark

                              in reply to: Connected to tunnel, but no traffic works #13942
                              Vadim Smirnov
                              Keymaster

                                Logs and PCAP files would be helpful for investigating your issue.

                                in reply to: Winpkflt Rebind #13941
                                Vadim Smirnov
                                Keymaster

                                  The Ethernet connection likely has a larger MTU than the WireGuard adapter. To address this discrepancy, you need to clamp the Maximum Segment Size (MSS) for TCP connections.

                                Viewing 15 posts - 16 through 30 (of 1,499 total)