[Vadim Smirnov]

I think the problem is that TB3 adapters are not persistent and in order to provide the reliability Ethernet Bridge have to reconfigure dynamically, e.g detect when TB3 adapters added/removed to/from the system.

You could use https://www.ntkernel.com/docs/windows-packet-filter-documentation/c-api/setadapterlistchangeevent/ to monitor network adapter changes and reconfigure the bridging accordingly.

[Vadim Smirnov]

If you ask about x64 build of this tool then regretfully no, it does not exist for x64. However, user-mode implementation of Ethernet Bridge is available for both x86 and x64.

Source code:
https://github.com/wiresock/ndisapi/tree/master/examples/cpp/ethernet_bridge

Binaries:
https://github.com/wiresock/ndisapi/releases/tag/v3.2.28.1

Implementation details:

Bridging Networks with Windows Packet Filter

[Vadim Smirnov]

OK, if you need to SOCKSify the traffic from 10.0.0.0/24 then the NAT is a wrong proposal. Instead you can redirect TCP/UDP traffic from the 10.0.0.0/24 to the local (running on the gateway) transparent TCP/UDP proxies which will handle the authentication with SOCKS5 server and forward traffic through it. I have mentioned the SOCKSIFY sample above which does this for the locally originated traffic, but the same can be easily done for the LAN traffic too.

Another component you may need here is DHCP server to assign IP addresses to the PS4 and XBOX, it can be a part of your software or external service.

You can use support(at)ntkernel.com if you prefer the direct communication.

[Vadim Smirnov]

OK, let’s assume you have a PC with two network adapters: first network adapter having an address 10.0.0.1 is connected to the LAN segment with PS4 and XBOX, second network adapter with an address 192.168.1.25 is connected to the Internet via your home router and you would like to pass TCP/UDP traffic from the PS4 and XBOX through the remote SOCKS5 server (GPN server) to optimize the latency on the route. Is that correct so far?

[Vadim Smirnov]

If you need to ‘socksify’ the traffic then this sample could be more useful:

https://github.com/wiresock/ndisapi/tree/master/examples/cpp/socksify

It is a little bit limited, e.g. it intercepts only locally originated traffic and passes it through the SOCKS proxy. The same can be done with non-local traffic either. However I need more details…

[Vadim Smirnov]

In the context of the Internet Gateway the Provider is the interface connected to the Internet, the Client is the network interface connected to the internal network you would like to share the Internet to. Internet Gateway sample does not implement DHCP protocol, so all IP addresses (except the Provider which is typically assigned by ISP) should be assigned manually.

[Vadim Smirnov]

It is worth mentioning that there is more than one way to achieve this depending on the exact requirements, however basic NAT sample can be found here.

[Vadim Smirnov]

Here you can find SYSTEM_PERFORMANCE_INFORMATION for Windows 8 and later.

[Vadim Smirnov]

I think you could try to monitor non paged pool usage via ZwQuerySystemInformation with SystemPerformanceInformation class. Although SYSTEM_PERFORMANCE_INFORMATION is not officially documented but I don’t think that in Windows 10 it is very different (if different at all) from the one below (I think this definition is from times of NT 4.0/2000/XP):

typedef struct _SYSTEM_PERFORMANCE_INFORMATION {
    LARGE_INTEGER IdleProcessTime;
    LARGE_INTEGER IoReadTransferCount;
    LARGE_INTEGER IoWriteTransferCount;
    LARGE_INTEGER IoOtherTransferCount;
    ULONG IoReadOperationCount;
    ULONG IoWriteOperationCount;
    ULONG IoOtherOperationCount;
    ULONG AvailablePages;
    ULONG CommittedPages;
    ULONG CommitLimit;
    ULONG PeakCommitment;
    ULONG PageFaultCount;
    ULONG CopyOnWriteCount;
    ULONG TransitionCount;
    ULONG CacheTransitionCount;
    ULONG DemandZeroCount;
    ULONG PageReadCount;
    ULONG PageReadIoCount;
    ULONG CacheReadCount;
    ULONG CacheIoCount;
    ULONG DirtyPagesWriteCount;
    ULONG DirtyWriteIoCount;
    ULONG MappedPagesWriteCount;
    ULONG MappedWriteIoCount;
    ULONG PagedPoolPages;
    ULONG NonPagedPoolPages;
    ULONG PagedPoolAllocs;
    ULONG PagedPoolFrees;
    ULONG NonPagedPoolAllocs;
    ULONG NonPagedPoolFrees;
    ULONG FreeSystemPtes;
    ULONG ResidentSystemCodePage;
    ULONG TotalSystemDriverPages;
    ULONG TotalSystemCodePages;
    ULONG NonPagedPoolLookasideHits;
    ULONG PagedPoolLookasideHits;
    ULONG Spare3Count;
    ULONG ResidentSystemCachePage;
    ULONG ResidentPagedPoolPage;
    ULONG ResidentSystemDriverPage;
    ULONG CcFastReadNoWait;
    ULONG CcFastReadWait;
    ULONG CcFastReadResourceMiss;
    ULONG CcFastReadNotPossible;
    ULONG CcFastMdlReadNoWait;
    ULONG CcFastMdlReadWait;
    ULONG CcFastMdlReadResourceMiss;
    ULONG CcFastMdlReadNotPossible;
    ULONG CcMapDataNoWait;
    ULONG CcMapDataWait;
    ULONG CcMapDataNoWaitMiss;
    ULONG CcMapDataWaitMiss;
    ULONG CcPinMappedDataCount;
    ULONG CcPinReadNoWait;
    ULONG CcPinReadWait;
    ULONG CcPinReadNoWaitMiss;
    ULONG CcPinReadWaitMiss;
    ULONG CcCopyReadNoWait;
    ULONG CcCopyReadWait;
    ULONG CcCopyReadNoWaitMiss;
    ULONG CcCopyReadWaitMiss;
    ULONG CcMdlReadNoWait;
    ULONG CcMdlReadWait;
    ULONG CcMdlReadNoWaitMiss;
    ULONG CcMdlReadWaitMiss;
    ULONG CcReadAheadIos;
    ULONG CcLazyWriteIos;
    ULONG CcLazyWritePages;
    ULONG CcDataFlushes;
    ULONG CcDataPages;
    ULONG ContextSwitches;
    ULONG FirstLevelTbFills;
    ULONG SecondLevelTbFills;
    ULONG SystemCalls;
} SYSTEM_PERFORMANCE_INFORMATION, *PSYSTEM_PERFORMANCE_INFORMATION;

[Vadim Smirnov]

Hi,

Well, OID_GEN_TRANSMIT_QUEUE_LENGTH is an optional, so you are not guaranteed to receive anything useful.

I had not tried to overflow the network card, but I think you could limit your packet sending rate according the card transmit speed. Anyway, faulting the system at high rates looks confusing, I would rather expect card to drop packets if the rate exceeds its capabilities.

Regards,
Vadim

[Vadim Smirnov]

Agree, but the way of doing this is completely undocumented and thus may vary between Windows versions. The lack of commercial software doing this probably means that this feature is hard to implement/support.

[Vadim Smirnov]

In this context above the layer is the driver level abstraction associated with FILE_OBJECT (CNdisApi object) with independent static filters table, packets queue and etc..

Using different layers for each application, both of them cannot intercept the same packet?

They can if packet was not previously dropped by upper (for outgoing packets) or lower (for incoming packets) layers.

Layers architecture allows to share single driver between several different packet filter applications.

[Vadim Smirnov]

Standard driver build supports only one packet filter table and is supposed to be used from one user mode process. You can use multiply CNdisApi instances but setting the new filter table will override the previously loaded one. So you are supposed to collect all required filters into the single table.

However, there is also a multiply layers driver build available to winpkfilter customers which supports multiply packet filter tables (one per filter layer) which can be used from several application as long as they use different layers.

[Vadim Smirnov]

What do you mean “is not working”?

If the table you load into the driver is equivalent to the following:

// Common values
pFilters->m_StaticFilters[0].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[0].m_ValidFields = NETWORK_LAYER_VALID;
pFilters->m_StaticFilters[0].m_FilterAction = FILTER_PACKET_REDIRECT;
pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;

// Network layer filter
pFilters->m_StaticFilters[0].m_NetworkFilter.m_dwUnionSelector = IPV4; 
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_TCP;

pFilters->m_StaticFilters[1].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[1].m_ValidFields = 0;
pFilters->m_StaticFilters[1].m_FilterAction = FILTER_PACKET_PASS;
pFilters->m_StaticFilters[1].m_dwDirectionFlags = PACKET_FLAG_ON_SEND;

Then it should redirect outgoing TCP packets into the user mode, pass any other outgoing packets (except TCP) over and redirect ALL incoming packets into the user mode.

[Vadim Smirnov]

Yes, it is possible. As an example you can check the 3rd scenario in filter.cpp:

//**************************************************************************************
// 1. Block all ICMP packets
// Common values
pFilters->m_StaticFilters[0].m_Adapter.QuadPart = 0; // applied to all adapters
pFilters->m_StaticFilters[0].m_ValidFields = NETWORK_LAYER_VALID;
pFilters->m_StaticFilters[0].m_FilterAction = FILTER_PACKET_DROP;
pFilters->m_StaticFilters[0].m_dwDirectionFlags = PACKET_FLAG_ON_SEND | PACKET_FLAG_ON_RECEIVE;

// Network layer filter
pFilters->m_StaticFilters[0].m_NetworkFilter.m_dwUnionSelector = IPV4; 
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_ValidFields = IP_V4_FILTER_PROTOCOL;
pFilters->m_StaticFilters[0].m_NetworkFilter.m_IPv4.m_Protocol = IPPROTO_ICMP;

Please note, that in you code you use incorrect value for m_dwDirectionFlags

[Author]

Posts