[Vadim Smirnov]

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]

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]

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.

[Vadim Smirnov]

Great! Thank you for the update! 👍

[Vadim Smirnov]

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

🔗 Download WireSock Secure Connect

[Vadim Smirnov]

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!

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

I don’t see any handshake responses in the log. WireSock sends multiple handshake packets to the server, but there’s no response. This behavior is typical when the WireGuard protocol is blocked. You might want to try using the SOCKS5 configuration option—it could resolve the issue.

[Vadim Smirnov]

Hello Olivier,

Thank you for your message and for considering WinpkFilter as a solution for your network monitoring module. I’m glad to hear it aligns well with your requirements, and I appreciate your kind words about my responsiveness.

For your trial, you are welcome to use the publicly available version of WinpkFilter. However, please keep in mind that I don’t recommend using this build in a production environment on a permanent basis, as it may lead to potential conflicts.

Should you need any further assistance or clarification, feel free to reach out.

Best Regards,
Vadim

[Vadim Smirnov]

Olivier,

Yes, you can use a single instance of CNdisApi. Please refer to the dual_packet_filter class, which demonstrates how two threads can operate across two network interfaces.

Additionally, you can assume the timestamp when the Read call occurs, with some level of precision. For higher accuracy, minor driver modifications would be needed; for example, the reserved bytes in INTERMEDIATE_BUFFER could be used to store more precise timestamps.

[Author]

Posts