(gdb) bt
0 0x00007f43857a5e14 in __GI___pthread_mutex_init (mutex=0x0, mutexattr=0x0) at pthread_mutex_init.c:89
1 0x00007f4385eaaf1b in UnixNewLock () at SoftEtherVPN/src/Mayaqua/Unix.c:1845
2 0x00007f4385e92331 in NewLockMain () at SoftEtherVPN/src/Mayaqua/Object.c:89
3 0x00007f4385e92359 in NewLock () at SoftEtherVPN/src/Mayaqua/Object.c:101
4 0x00007f4385e92765 in NewCounter () at SoftEtherVPN/src/Mayaqua/Object.c:171
5 0x00007f4385e92e76 in NewRef () at SoftEtherVPN/src/Mayaqua/Object.c:339
6 0x00007f4385e76939 in NewSkEx (no_compact=0) at SoftEtherVPN/src/Mayaqua/Memory.c:863
7 0x00007f4385e68c95 in NormalizePathW (
dst=0x7ffe65932940 L"\xd6ff2ffb\xfbf14ce5\xad8669ca\x41998a9c\x5107d62d\x8d2ab3f2\x37ceaad2\xffc947ec\xad8ed8d8\x33e9f2f7\xc05723a9\x843263e3\x5516beb3\x12571e2a\xd81405f3\xf92194fe\xd807aa98\x12835b01\x243185be\x550c7dc3\xfd74170d\x12835b01\x553185be\x550c7dc3\x72be5d74\x80deb1fe\x9bdc06a7\xc19bf1f4\x72be5d74\x80deb1fe\x9bdc06a7\xc19bf174\x894d4018\xc54302b8\x145dc92\x143b3917\x62aa4fb8\x915764b1\xd5e11bef\x9d5fbc5\xb956c25b\x59f111f1\x923f82a4\xab1c5ed5\x3956c25b\x59f111f1\x923f82a4\xab1c5ed5\xbaeb40", size=2048, src=<optimized out>)
at SoftEtherVPN/src/Mayaqua/FileIO.c:1960
8 0x00007f4385e69188 in ConbinePathW (
dst=0x7ffe65932940 L"\xd6ff2ffb\xfbf14ce5\xad8669ca\x41998a9c\x5107d62d\x8d2ab3f2\x37ceaad2\xffc947ec\xad8ed8d8\x33e9f2f7\xc05723a9\x843263e3\x5516beb3\x12571e2a\xd81405f3\xf92194fe\xd807aa98\x12835b01\x243185be\x550c7dc3\xfd74170d\x12835b01\x553185be\x550c7dc3\x72be5d74\x80deb1fe\x9bdc06a7\xc19bf1f4\x72be5d74\x80deb1fe\x9bdc06a7\xc19bf174\x894d4018\xc54302b8\x145dc92\x143b3917\x62aa4fb8\x915764b1\xd5e11bef\x9d5fbc5\xb956c25b\x59f111f1\x923f82a4\xab1c5ed5\x3956c25b\x59f111f1\x923f82a4\xab1c5ed5\xbaeb40", size=2048,
dirname=0xbace10 L"/root/.local/bin", filename=0x7ffe65932100 L"SoftEtherVPN/build/vpntest") at SoftEtherVPN/src/Mayaqua/FileIO.c:1686
9 0x00007f4385e6af48 in UnixGetExeNameW (name=0x7f4385ede820 <exe_file_name_w> L"/tmp/a.out", size=2048, arg=0xbb5050 L"./vpntest") at SoftEtherVPN/src/Mayaqua/FileIO.c:1401
10 0x00007f4385e6b04b in InitGetExeName (arg=<optimized out>) at SoftEtherVPN/src/Mayaqua/FileIO.c:1367
11 0x00007f4385e7470a in InitMayaqua (memcheck=memcheck@entry=0, debug=debug@entry=1, argc=argc@entry=3, argv=argv@entry=0x7ffe659340e8)
at SoftEtherVPN/src/Mayaqua/Mayaqua.c:456
12 0x0000000000401282 in main (argc=3, argv=0x7ffe659340e8) at SoftEtherVPN/src/vpntest/vpntest.c:259
"2050 LA_DEL_CRL" - this entry appear in logfile when you delete cert from Certificate Revocation List. Thats why need to change it.
"2051 LA_SET_CRL" - this entry must appear in logfile when you edit cert in Certificate Revocation List, but it doesn't happen (perhaps it's a bug)
Since 35200a29ea we build complete installers using CMake, meaning that there's no need for BuildUtil anymore.
MSBuild projects that are not migrated to CMake yet are kept for reference.
This commit also updates BUILD_WINDOWS.md so that it mentions Visual Studio 2019 instead of 2017.
To solve the problem that the escape condition of the loop that tries name resolution in UDP mode was reversed in the keep-alive function of the Internet connection, so the name resolution retry is set to 250 msec interval instead of the normal 60 second interval.
This works for all VPN protocols.
In SessionMain(): for DHCPDISCOVER and DHCPREQUEST frames, write the static IP address (which is retrieved from the user notes) in the SIADDR field of DHCPHEADER.
In VirtualDhcpServer(): for DHCPDISCOVER and DHCPREQUEST frames, read the static IP address from the SIADDR field of DHCPHEADER and assign it to the client.
- When building on Windows XP using Visual Studio 2008, I encountered the following issue.
- I did a fresh install of Windows XP SP3 32-bit, then applied updates including .NET 3.5. Next I installed MS Visual Studio 2008, then updated with sp1. All of this according to the documentation in your readme for building on Windows.
- In file src/BuildUtils/VpnBuilder.cs, there are two "if" statements testing the same thing, which is to determine if it is a 32-bit or 64-bit machine/compiler. But the then and else clauses are reversed, so clearly, one of them is wrong. The result I saw is that the SDK path being used to run RC.exe is left as the NULL string and so it fails to run the RC.exe program.
- This happens early in the build process, building the build utils. The two "if" statements are used to set paths for the Visual Studio VC and SDK directories. Depending on the integer pointer size, it uses different paths in the registry.
- When I looked in the registry on my Windows XP machine, there is no key HKLM\SOFTWARE\Wow6432Node, I have only seen that on 64-bit machines.
- For the fix, I consolidated the two "if" statements into one, the existing statement on line 380 would only set a value for Paths.VisualStudioVCDir (which got set correctly). Now I moved the code for also setting Paths.MicrosoftSDKDir, while reversing the values from the incorrectly coded "if" statement.
- I can understand that under certain circumstances, this issue would not be encountered, but should be easily reproducible when installing a clean system.
error: cannot initialize a variable of type 'wchar_t *' with an lvalue of type 'const wchar_t [4]'
wchar_t *protocol_str = (udp ? L"UDP" : L"TCP");
^ ~~~~~~~~~~~~~~~~~~~~~~~
The "session created" and "session deleted" messages were useful when a single OPENVPN_SERVER object handled multiple UDP sessions.
Now that each session has its own OPENVPN_SERVER object and session creations/deletions are logged by PROTO, the messages are redundant.
In future we will change the OpenVPN implementation so that the multi-session handling code is deleted.
The messages were like this:
OpenVPN Module: The OpenVPN Server Module is starting.
OpenVPN Session 1 (192.168.122.211:47390 -> 0.0.0.0:1194): A new session is created. Protocol: UDP
OpenVPN Session 1 (192.168.122.211:47390 -> 0.0.0.0:1194): Deleting the session.
OpenVPN Module: The OpenVPN Server Module is stopped.
ProtoHandleDatagrams() takes care of deleting a session if marked as halted.
However, the check is performed when a packet for that session is received; that never happens if the remote host doesn't send at least a packet.
This commit fixes the issue by moving the check into the loop that iterates through all sessions.
ProtoOptionsGet command - Lists the options for the specified protocol
Help for command "ProtoOptionsGet"
Purpose:
Lists the options for the specified protocol
Description:
This command can be used to retrieve the options for a specific protocol.
Detailed info (e.g. value type) will be shown.
You can change an option's value with the ProtoOptionsSet command.
Usage:
ProtoOptionsGet [protocol]
Parameters:
protocol - Protocol name.
ProtoOptionsSet command - Sets an option's value for the specified protocol
Help for command "ProtoOptionsSet"
Purpose:
Sets an option's value for the specified protocol
Description:
This command can be used to change an option's value for a specific protocol.
You can retrieve the options using the ProtoOptionsGet command.
To execute this command, you must have VPN Server administrator privileges.
Usage:
ProtoOptionsSet [protocol] [/NAME:option_name] [/VALUE:string/true/false]
Parameters:
protocol - Protocol name.
/NAME - Option name.
/VALUE - Option value. Make sure to write a value that is accepted by the specified protocol!
PROTO_OPTION is a structure that describes an option (who would've guessed?).
It's designed in a way that allows it to occupy as low memory as possible, while providing great flexibility.
The idea is similar to the one implemented in LIST for trivial types, with the difference that PROTO_OPTION doesn't require casting due to the use of union.
The reason why we don't build these two targets is that they're not used.
More specifically: they require proper configuration to work correctly, which is currently missing.
While vpninstall may be worth salvaging, vpnweb is definitely a relict of the past because it relies on ActiveX.
vpndrvinst is the name of the target and thus the default output name, let's use it.
`vpndrvinst.exe" also sounds less fishy than "driver_installer.exe"...
BuildUtil compiles the project as 32 bit and 64 bit, before building the installer package.
64 bit binaries have the "_x64" suffix and are added to the package alongside the 32 bit ones (that have no suffix).
The CMake project compiles the binaries for a single architecture and they have no suffix.
We decided that providing two separate installers is the best solution.
As for the binaries with the "_ia64" suffix: they never existed during the this repository's lifespan.
The MSBuild project built the binary into "src/bin/hamcore", causing it to be added to "hamcore.se2".
As hinted by the name of the file ("vpnsetup_nosign.exe"), it is not signed by BuildUtil, possibly to save time (the setup package is signed).
The CMake project builds the binary in the same directory as the other ones, allowing the setup to install them without the need to build a package.
Previously, the file needed to be present in order for the setup to work.
This commit removes the requirement so that the setup can be ran from the build directory without the need to copy the file (which is now removed from the repository).
The inclusion of the headers is probably a very old leftover, from when OpenSSL was not encapsulated into Mayaqua yet.
In fact, there was a "HAM_C" (defined in vpndrvinst.c) definition check in Mayaqua/Encrypt.h preventing the redefinition of OpenSSL types.
When "VPN_EXE" is defined, Mayaqua.h defines WinMain(), which handles arguments in a special way.
This commit passes "WIN32" to add_executable(), so that WinMain() is used as entry point instead of main().
The use of main() instead of WinMain() was causing service mode not to work due to the "/service" argument being discarded.
Our CMake project used to forcefully create and use two different build directories: "build" and "tmp".
This commit changes the behavior so that only the build directory CMake is ran in is used.
The "configure" script now runs CMake in "build" by default, instead of "tmp".
strtok() and wcstok() are considered unsafe functions.
A segmentation fault caused by the use of strtok() was recently reported.
Co-authored-by: Takuho NAKANO <takotakot@users.noreply.github.com>
The SSTP implementation doesn't provide packet identification, because it's not required: the protocol is identified by the HTTP header it sends to the server.
"ClientOption", as the name implies, is only used in a client context.
The issue was introduced in 235bd07e67. Before that, an unrelated check prevented UnixVLanSetState() from being called in a server context.
SoftEther VPN originally created the NIC in the UP state and never changed it, even when the the client was not connected.
The behavior was changed in 59e1483dbf, which also added the NicDownOnDisconnect option
The option was disabled by default for backwards compatibility with scripts that don't check whether the NIC is down, but it's not ideal.
This commit forces the correct behavior and removes the commands "TUNDownOnDisconnectEnable", "TUNDownOnDisconnectDisable" and "TUNDownOnDisconnectGet".
