Receive TLS ClientHello despite max-payload limit set, to get all
the benefits of the option (decreased CPU consumption) but still
handle all TLS connections, including Kyber.
It has been reported that the DPI systems in Saudi Arabia and
United Arab Emirates are started to search for the beginning of
SNI extension header and its value, without parsing the TLS ClientHello
packet, in any part of TCP session.
Workaround the issue by splitting the packet right after the end
of extension headers and before its value.
https://ntc.party/t/goodbyedpi-in-saudi-arabia/7884https://ntc.party/t/goodbyedpi-in-uae/7914
If --max-payload 1200 is used and there's HTTP request with lots of cookies
which exceed 1200 bytes in size, this packet would have been skipped as
'too large', and the circumvention won't be applied.
Fix this by checking for "GET " or "POST" in the beginning of the packet
regardless of its size.
It was assumed that getopt checks argc count and does not require
null-terminated argv pointer to determine argv end for optional
parameter.
That is wrong.
Add null-terminated latest argv.
Fixes#246
This option excludes TCP packets with the data payload larger than
defined value from being copied by WinDivert driver to GoodbyeDPI.
As most of HTTP and TLS ClientHello packets are repatively small,
and file transfers are usually big and are sent/received using
the whole available MTU/MSS, we can just exclude them from
being processed by our userspace program to reduce unnecessary
CPU load.
This option is added specially for protonmail.com, as it sends
low Window Size in SYN-ACK for requests from Russia, to force
the client to fragment the packet. GoodbyeDPI doesn't do reassembling
and can't extract SNI in this case, thus won't circumvent the
censorship if --blacklist option is used.
