Forum Replies Created
-
Posts
-
From what I can see ebridge can see both TB connections, so lets keep the ‘listadapters’ aside.
As I can see both TB adapters on the central host have auto-configured IP addresses and pinging by name does not work. Could you assign all TB adapters some fixed IPv4 addresses and try to ping over the bridge? E.g.
PC1-TB [10.0.0.1/24] <–> [10.0.0.2/24]TB1-PC2-TB2[10.0.0.3/24] <–> [10.0.0.4] TB-PC3
Then try to ping 10.0.0.4 from 10.0.0.1 and vice versa while running the ebridge. If bridge works then you should be able to, if not then send me captures to look what is going wrong.
Does ebridge displays your TB adapters at all or they are just ignored by software? If it does not then probably I do need to add TB medium support first. Could you please run ‘listadapters’ from the standard tools and share its output?
You can share Google driver to my gmail.com account ‘gmkernel’.
I don’t have the hardware to test with on my side, so let’s try to look at what is going on the network layer. Here is the Debug build of Ethernet Bridge which saves packets capture from all bridged adapters. Try to test it with Thunderbolt (e.g. send pings from the one host connected to the bridge to another one) and send me PCAP files and ‘ipconfig /all’ output.
I have tested Ethernet Bridge sample only over Ethernet and WiFi adapters and if you look through this paper then bridging WiFi was a tricky task (required MAC level address translation). I have never tested Ethernet Bridge over Thunderbolt, but I suspect that it has its own specifics which should taken into account.
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.
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_bridgeBinaries:
https://github.com/wiresock/ndisapi/releases/tag/v3.2.28.1Implementation details:
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.
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?
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…
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.
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.
Here you can find SYSTEM_PERFORMANCE_INFORMATION for Windows 8 and later.
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;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
