Forum Replies Created
-
Posts
-
The only idea I have is that you have some other third-party software (which includes NDIS/WFP filter) and somehow results the software conflict… Try to setup two fresh Windows connected over the switch or direct cable.
P.S. To ensure, retested with reversed copy direction and the result is still the same…
I’ve just taken dnstrace sample (dumps DNS packets and passes everything else without any special handling) and tried to copy one large file from the system running dnstrace to another one. Here is the result with dnstrace running and without:
.The sample code you tested was designed for the demo purposes only. If you are interested in the performance tests you can check this post.
Capture tool was primarily designed for testing/debugging purposes and it utilizes relatively slow file stream I/O, e.g. each intercepted packet is delayed for the time needed to write it into the file resulting the increased latency and decreased bandwidth.
If you need a high speed traffic capture solution you have to implement in-memory packet caching and write captured packets into the file using dedicated thread instead of doing this in the packet filtering one. Or you could use use the memory mapped file and let Windows cache manager to do the rest 🤔
P.S. And yes, Fast I/O may improve the performance even further…
You can change adapter mode calling SetAdapterMode without stopping the filtering or resetting events. Mode flag only defines what to do with an original packet, in listen mode it is passed over, in tunnel it is dropped.
This one seems to work just fine:
;------------------------------------------------------------------------- ; ndiswg_lwf.INF -- WinpkFilter NDIS LWF driver (WinTun build) ; ; Copyright (c) NT Kernel Resources. All rights reserved. ;------------------------------------------------------------------------- [version] Signature = "$Windows NT$" Class = NetService ClassGUID = {4D36E974-E325-11CE-BFC1-08002BE10318} Provider = %Ntkr% CatalogFile = ndiswg.cat PnpLockdown = 1 [Manufacturer] %Ntkr%=Ntkr,NTx86,NTia64,NTamd64,NTARM64 [Ntkr.NTx86] %ndiswg_Desc%=Install, nt_ndiswg [Ntkr.NTia64] %ndiswg_Desc%=Install, nt_ndiswg [Ntkr.NTamd64] %ndiswg_Desc%=Install, nt_ndiswg [Ntkr.NTARM64] %ndiswg_Desc%=Install, nt_ndiswg ;------------------------------------------------------------------------- ; Installation Section ;------------------------------------------------------------------------- [Install] AddReg=Inst_Ndi Characteristics=0x40000 NetCfgInstanceId="{ACAA7086-8B4C-4443-B5CE-9694A907670C}" Copyfiles = ndiswg.copyfiles.sys [SourceDisksNames] 1=%ndiswg_Desc%,"",, [SourceDisksFiles] ndiswg.sys=1 [DestinationDirs] DefaultDestDir=12 ndiswg.copyfiles.sys=12 [ndiswg.copyfiles.sys] ndiswg.sys,,,2 ;------------------------------------------------------------------------- ; Ndi installation support ;------------------------------------------------------------------------- [Inst_Ndi] HKR, Ndi,Service,,"ndiswg" HKR, Ndi,CoServices,0x00010000,"ndiswg" HKR, Ndi,HelpText,,%ndiswg_HelpText% HKR, Ndi,FilterClass,, compression HKR, Ndi,FilterType,0x00010001,0x00000002 HKR, Ndi\Interfaces,UpperRange,,"noupper" HKR, Ndi\Interfaces,LowerRange,,"ndis5,ndis4" HKR, Ndi\Interfaces, FilterMediaTypes,,"ethernet, wan, ppip, bluetooth, ndis5, nolower" HKR, Ndi,FilterRunType, 0x00010001, 1 ;this filter must run before any protocol can bind to the below miniport ;------------------------------------------------------------------------- ; Service installation support ;------------------------------------------------------------------------- [Install.Services] AddService=ndiswg,,ndiswg_Service_Inst [ndiswg_Service_Inst] DisplayName = %ndiswg_Desc% ServiceType = 1 ;SERVICE_KERNEL_DRIVER StartType = 1 ;SERVICE_SYSTEM_START ErrorControl = 1 ;SERVICE_ERROR_NORMAL ServiceBinary = %12%\ndiswg.sys LoadOrderGroup = NDIS Description = %ndiswg_Desc% AddReg = NdisImPlatformBindingOptions.reg [Install.Remove.Services] DelService=ndiswg,0x200 [NdisImPlatformBindingOptions.reg] HKR, Parameters, NdisImPlatformBindingOptions,0x00010001,2 [Strings] Ntkr = "NT Kernel Resources" ndiswg_Desc = "WinpkFilter LightWeight Filter for WinTun" ndiswg_HelpText = "WinpkFilter NDIS LightWeight Filter for WinTun"Windows Packet Filter NDIS filter driver does not bind to WinTun network adapter because of the following in wintun.inf:
HKR, Ndi\Interfaces, LowerRange, , "nolower"while in ndisrd_lwf.inf we have:
HKR, Ndi\Interfaces, FilterMediaTypes,,"ethernet, wan, ppip, bluetooth"So there are two choices:
- Change wintun.inf ‘nolower’ to ‘ethernet’
- Add ‘nolower’ to the list of FilterMedia types in ndisrd_lwf.inf
As a side effect second option will cause Windows Packet Filter driver binding to the interfaces it normally would not bind to and therefore it is not supported by stock driver build.
Then there must be something wrong with your modified SYN packet. Enable checksum verification in Wireshark and check if packet checksums are good.
From what I can see there is no SYN-ACK packet from your HTTP server. So,
- Does your HTTP server listen on port 153?
- Check if HTTP server if firewall protected and disable Windows Defender firewall if the server is Windows.
First I would check if packet are delivered to the destination. You could setup the HTTP server in the LAN and try to connect to it while capturing traffic using tcpdump/wireshark (on the server). For the TCP connection you must see the incoming TSP SYN and if the SYN is OK then also the outgoing SYN_ACK.
The approach looks good in general. I hope you remember to recalculate IP/TCP checksum and adjust MAC addresses accordingly.
Yes, it is possible to do using Windows Packet Filter, however:
- this is not trivial, as you need to write the code to select and re-route network packets
- implementation may depend on VPN you are using, so I would recommend to start with something simple, e.g. routing ICMP PING or DNS
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.
