Layer 3 TUN Driver for Windows https://git.zx2c4.com/wintun/atom/?h=sr%2Fapi-improvements 2021-04-13T21:56:04Z 2021-04-13T21:56:04Z Simon Rozman simon@rozman.si 2021-04-12T11:08:42Z urn:sha1:47b16dc884992d9c100bc0161d4ca6776a3cd507 Should client desire to prepare packets for Wintun inside the ring memory (e.g. to reduce memory copying), the final sending packet size is not always known at the WintunAllocateSendPacket() time. This commit modifies Wintun to calculate the packet size on delivery to NDIS. The packet size is derived from IPv4/IPv6 packet header. Signed-off-by: Simon Rozman <simon@rozman.si> 2021-04-13T21:56:04Z Simon Rozman simon@rozman.si 2021-04-10T13:33:01Z urn:sha1:564a883e23fff00140c10271f08b37dc649d57c8 To avoid additional packet memory allocation and copy when sending or receiving packets, this commit introduces additional available space before and after layer 3 IPv4 or IPv6 packet in the Wintun rings. Wintun will ignore data in those areas. Requested-by: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Simon Rozman <simon@rozman.si> 2021-04-13T21:55:08Z Jason A. Donenfeld Jason@zx2c4.com 2021-04-13T21:54:58Z urn:sha1:5edd8d25179ef93ea2b0c44d724df0ab9a1082ce Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> 2021-04-13T21:50:50Z Simon Rozman simon@rozman.si 2021-04-13T10:50:13Z urn:sha1:51a4f299c39f5b53a41da6caf7d10157123420e6 Wondering, why WinDbg is refusing to load symbols for wintun.sys recently... By default, building puts .pdb files to the output folder. Next to the final binaries: wintun.sys, wintun.dll, example.exe... Wait?! But the wintun.pdb from wintun.dll overwrites the wintun.pdb from wintun.sys then. Signed-off-by: Simon Rozman <simon@rozman.si> 2021-04-13T21:50:50Z Simon Rozman simon@rozman.si 2021-04-13T10:44:39Z urn:sha1:227b76480cef69c714183a5c9d33b42b825af467 The time stamping with Inf2Cat never makes the wintun output really "up- to-date". This keeps triggering wintun project rebuilds over and over again. Including all the projects depending on wintun. Thou, the api project really depends on the driver built by wintun project, those needless driver rebuilds are utterly annoying. To be correct, the amd64 api project also depends on the arm64 api project - a dependency which cannot be described using .sln. So, one way or another, a developer must build projects inside the .sln in a specific order. Another solution would be to split the solution file (pun intended). One .sln for driver, another for the api and example projects. Then open the one the developer is focused on. Signed-off-by: Simon Rozman <simon@rozman.si> 2021-04-13T21:50:50Z Simon Rozman simon@rozman.si 2021-04-13T10:09:13Z urn:sha1:d35312d33f95a0250ccfac1f9a58729fb16f287f Signed-off-by: Simon Rozman <simon@rozman.si> 2021-04-10T11:37:22Z Simon Rozman simon@rozman.si 2021-04-10T11:37:22Z urn:sha1:3a8dbb6ae2e91a5b977641d84e86fdf4d51f1ad5 Signed-off-by: Simon Rozman <simon@rozman.si> 2021-03-19T11:04:23Z Simon Rozman simon@rozman.si 2021-03-19T10:55:58Z urn:sha1:2f1d1ab8273f6d574f8e28261ddfc72ac4f8015d The \xa9 is © on Windows-125x code pages. When Wintun was compiled on a Windows computer using UTF-8 as default code page (for "non-Unicode" programs), the Copyright notice in resources was wrong. Signed-off-by: Simon Rozman <simon@rozman.si> 2021-03-19T10:52:11Z Simon Rozman simon@rozman.si 2021-03-19T10:52:11Z urn:sha1:a6fa9c1b678c8bd4212cae6b2a55fb7b279b6c6e While the Wintun driver is typically released only at <major>.<minor> milestones, the wintun.dll did see some intermediate releases. To make MSI logic correctly decide to upgrade local wintun.dll file, the version inscribed in wintun.dll file resources should increment in those intermediate releases. MSI ignores file timestamps. One could use REINSTALLMODE=emus Installer property to force copying wintun.dll when its version doesn't change. But REINSTALLMODE applies to all files in the MSI session and would be an additional requirement when authoring MSI packages with wintun.dll. Bumping only the final ZIP filename version is not sufficient. Therefore, a <major>.<minor> or <major>.<minor>.<build> versioning is introduced. Furthermore, we no longer distinguish between WintunVersion and WintunVersionStr. All our releases used strictly numeric <major>.<minor> notation, making WintunVersion and WintunVersionStr always the same. When the driver didn't change, just bump the version in wintun.proj and run `msbuild wintun.proj /t:Zip` to rebuild the wintun.dll and make the new ZIP file. Signed-off-by: Simon Rozman <simon@rozman.si> 2021-03-16T09:11:00Z Simon Rozman simon@rozman.si 2021-03-16T09:11:00Z urn:sha1:1ccd623e94197fd93d5380b90d5476343c078a9f MinGW supplies all Windows header files using lowercase filenames. This makes some of the #include lines in wintun.h fail to resolve the .h files correctly on a case-sensitive filesystem. Signed-off-by: Simon Rozman <simon@rozman.si>