On FreeBSD the stock code will attempt to expand the interface MTU any time a packet is to be sent that exceeds the current MTU. This results in a down/up on the interface that is wildly disruptive to existing services on that adapter and, eventually, is likely to run into MTU limits and start logging failures, even with jumbo-frame capable adapters. Thus if compiling on a FreeBSD machine disable this capability. Tested against 12.3-STABLE and 13.1-STABLE on v4.38-9760 from the FreeBSD ports tree but likely applies here as well; see bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267178
OpenVPN always allowed 8 ACKs in P_ACK_V1 packets but only used
up to 4 in other control packets. Since Softether drops all packets with
more than 4 ACKs it also drops legimate P_ACK_V1.
See also this issue: https://github.com/schwabe/ics-openvpn/issues/1486
On big endian system, while store 32 bits and 16bits number in memory of UINT64 variable "tmp", first 4 bytes of it always be zero makes "cookie" and "size" always be zero, lead to udpaccel unusable.
GenX25519 command - Create new X25519 keypair
Help for command "GenX25519"
Purpose:
Create new X25519 keypair
Description:
Use this to create a new X25519 keypair, which can be used for WireGuard.
Both the private and public key will be shown.
The public key can be shared and is used to identify a peer.
Also, it can always be retrieved from the private key using the GetPublicX25519 command.
The private key should be kept in a secure place and never be shared.
It cannot be recovered once lost.
Usage:
GenX25519
==========================================================================================
GetPublicX25519 command - Retrieve public X25519 key from a private one
Help for command "GetPublicX25519"
Purpose:
Retrieve public X25519 key from a private one
Description:
Use this if you have a private X25519 key and want to get its corresponding public key.
Usage:
GetPublicX25519 [private]
Parameters:
private - The private X25519 key you want to get the corresponding public key of.
Our own implementation works fine, however we should use OpenSSL's one since we already link to the library.
Base64Decode() and Base64Encode() return the required buffer size when "dst" is NULL.
This allows to efficiently allocate a buffer, without wasting memory or risking an overflow.
Base64FromBin() and Base64ToBin() perform all steps, returning a heap-allocated buffer with the data in it.
Turns out %S refers to ANSI/UTF-8 and %s to UTF-16.
This commit fixes a buffer overflow reported by AddressSanitizer and removes an unnecessary conversion to UTF-16.
The open-source project began with version 1.00, build 9022.
With the exception of an informative message fallback for builds older than 9428 (2014), all checks were for closed-source builds.
- <pthread.h> included for the "pthread_t" type definition.
- <net/ethernet.h> include removed as the header doesn't exist.
- AI_ALL and AI_V4MAPPED defined to 0 as the options don't exist.
Also, the default timeout value is set to 30000 (milliseconds) instead of 10000.
The change is made because it was reported that some routers failed to connect in time.
This commit also fixes a bug which caused the server to initialize all boolean options to false.
It was caused by SiLoadProtoCfg() not checking whether the item exists in the configuration file.
CfgGetBool() always returns false if the item doesn't exist.
From a functional point of view, the main improvement is that GetIP() now always prioritizes IPv6 over IPv4.
The previous implementation always returned an IPv4 address, unless not available: in such case it failed.
This means that now connections to hostnames should be established via IPv6 if available.
From a programmer point of view, getting rid of the insane wrappers is enough to justify a complete rewrite.
As an extra, several unrelated unused global variables are removed.
Before this commit, the IP address reported by the NAT-T server was immediately discarded.
That's because the peer should be accessible via the IP address used to establish the TCP connection.
User "domosekai" (https://www.domosekai.com) pointed out that the NAT-T IP address should be taken into account.
In his case it's required due to his broadband carrier's NAT causing TCP and UDP to have different external IPs.
Co-authored-by: domosekai <54519668+domosekai@users.noreply.github.com>
