"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)
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.
