> Testing the signatures and the driver on ARM64 would be good. We don't > have any ARM64 Windows hardware at our disposal.
Drop me a package and I'll take it for a spin. I have at least one device with Secure Boot set up on a released build (1803). > We don't have any tap-windows6 -specific tests at the moment, so I > generally just run the OpenVPN test suite against a bunch of OpenVPN 2.x > / Access Server / Private Tunnel servers: > <https://github.com/OpenVPN/openvpn-windows-test.git> I can give that a shot. If I can't figure something out from the README, I'll ask questions here. > Given that tap-windows6 driver has seen lots of modifications having > more focused tests would be good. Any ideas what we should test and how? As for tap-windows6, I have to profess a merely general understanding of what it does: It allows the usermode daemon to read, intercept, and emit raw network traffic, while the firewalling, routing, and encryption are done by the OpenVPN daemon after the traffic leaves the driver. Given that, I can think of a few test cases (not ordered in any way): (All tests should run under Driver Verifier with basic sanity and NDIS checks enabled.) * Heavy load on multiple TAPs * Upgrade * Empty, small, ~MTU, >MTU, and Jumbo packets * API fuzzing * Power transition testing ...but all of these take varying levels of dev investment to automate. The easiest next step would be to expand the ping test to try varying packet sizes (-l). (Windows' ping doesn't have a 'flood' option...) My 2c, Jon
pgpOcqUOVOlMd.pgp
Description: PGP signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
