Since pseudo checksums can now be arbitrary
values, the WinDivertHelperCalcChecksums function
no longer attempts to calculate the pseudo-
header checksum.
The MSVCRT*.dll dependency has been removed by:
(1) using Win32 API equivalents where possible,
and (2) re-implementing some basic C runtime
functions. This prevents multiple MSVCRTs from
being loaded at runtime (if the application uses
a different version than the DLL). The new
WinDivert.dll only depends on KERNEL32.dll and
ADVAPI32.dll.
Furthermore, the MINGW build has been extended
to generate a WinDivert.lib import library file.
This means that the MINGW DLL can now be used
directly by Visual Studio (any version).
For some reason pseudo checksums do not work on
some systems. The workaround is to modify
WinDivertSend() so that it calculates the full
checksums before forwarding the packet to the
driver.
This allows projects that are strictly "GPLv2
only" to use WinDivert without licensing issues.
See the FSF's compatibility matrix here:
https://www.gnu.org/licenses/gpl-faq.en.html
This change does not affect existing projects
that can continue to use the LGPLv3 as before.
Also, bump the WinDivert version to 1.4.1.
Bump version and change magic numbers to make the driver incompatible with
older versions. Also cleanup some driver checksum code missed by previous
commit.
* Re-brand "DIVERT" to "WINDIVERT" throughout the code-base.
* New flags:
> WINDIVERT_FLAG_PASSTHRU: Do not drop nor capture packets. Useful
for injection-only handles.
> WINDIVERT_FLAG_NO_CHECKSUM: Do not guarantee that diverted packets
have a correct checksum.
NOTE: Not yet tested!
* New default values and limits for various WinDivert parameters,
including WINDIVERT_PARAM_QUEUE_LEN, WINDIVERT_PARAM_QUEUE_TIME, and
the maximum filter length.
* New extended WinDivert functions that support asynchronous I/O:
> WinDivertRecvEx(..)
> WinDivertSendEx(..)
NOTE: Not yet tested!
* The WinDivert driver now services reads (receives) out-of-band.
The motivation is because WFP callouts are run at DISPATCH_LEVEL, so
we should not be doing expensive work in the ClassifyFn. This is also
the same reason why the filter length has been restricted.
basil00