You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by Frank42
Pages 1
I don't get to hung up on the record layer version info.
wShark seems to tag the traffic v1.2 or v1.3 after looking at the conversation.
I regularly see v1.3 traffic with a v1.2 record layer. The packet data say's it is v1.2 (0x0303). As in, this record layer is at version v1.2, but the conversation is v1.3. I don't believe the record layer version is there to identify the TLS version.
FFox does not show the cloudflare error. It gives: SSL_ERROR_NO_CYPHER_OVERLAP
I never saw the cloudflare screen/error. (InetExplorer shows it.)
--enable-sni translates to #define HAVE_SNI
It all makes sense when you explain it.
Thanks
In regards to the -313 error,....
I'm working on the idea that the server is looking for a missing extension. Not the content of the extensions. (I'd expect a different alert msg if this were the case.) I had always considered extensions as option info.
The client info below comes from my Wolf Example Client.
The server info below comes from a successful handshake using FFox, (forced to TLSv1.3, shows as draft 23).
The Client Hello is using one cipher: Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
The Server Hello supports this one as well: Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
FFox is sending many more extensions than Client is.
Both Client and FFox send:
Extension: supported_versions (len=3)
Extension: signature_algorithms (len=16)
Extension: ec_point_formats (len=2)
Extension: supported_groups (len=16)
Extension: key_share (len=432)
FFox send these as well:
1 Extension: server_name (len=21)
2 Extension: extended_master_secret (len=0)
3 Extension: renegotiation_info (len=1)
4 Extension: application_layer_protocol_negotiation (len=14)
5 Extension: status_request (len=5)
6 Extension: psk_key_exchange_modes (len=2)
7 Extension: padding (len=160)
I doubt #'s 1, 3, 4, 5, 6, 7 are necessary.
That leaves #2.
Does anything here jump out as different/wrong?
Thanks for the info.
I'm using: LIBWOLFSSL_VERSION_STRING "3.14.0"
I'm building with:
#define WOLFSSL_TLS13
#define HAVE_TLS_EXTENSIONS
#define HAVE_SUPPORTED_CURVES
#define HAVE_FFDHE_2048
#define HAVE_HKDF
#define WC_RSA_PSS
#define HAVE_AEAD
#define HAVE_AESGCM
#define HAVE_ECC
I'm using cmd:
client -h 104.28.30.12 -p 443 -d -v 4 -l TLS13-AES128-GCM-SHA256
The client is sending:
Supported Version: TLS 1.3 (draft 23) (0x7f17)
Per your description this should be: TLS 1.3 (draft 28) (0x7f1c)
That is, I'm pretty sure I'm building draft28 but it is reporting draft23.
I am unsure if this is related to the 313 error I'm seeing. (I'll suggest it is not.)
The server does not like the Client Hello (Handshake Failure)
A successful server handshake (Server Hello) sends:
Extension: supported_versions (len=2)
Supported Version: TLS 1.3 (draft 23) (0x7f17)
though the Server Hello handshake occurs in:
Handshake Type: Server Hello (2)
Version: TLS 1.2 (0x0303)
Did you find the cause of your 313 error?
One issue: #define HAVE_ECC // needed for server to generate a key
I can get the client example to connect to the server example but that is it. Client will not connect to any TSL1.3 sites.
From: wolfssl.com/docs/lts13/ Section: Using TLS 1.3 in wolfSSL
client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com-p 443 -g -A ./certs/wolfssl-website-ca.pem
Does not successfully connect.
wolfSSL Leaving SendTls13ClientHello, return 0
connect state: CLIENT_HELLO_SENT
received record layer msg
got ALERT!
Got alert
wolfSSL error occurred, error = 40 line:11884 file:c:\development\gemini\devarea
wolfSSL error occurred, error = 313 line:9424 file:c:\development\gemini\devarea
Can you confirm if your site supports TLSv1.3 or not?
(FFox (draft 23) say's no. My build of client (draft 23) say's no.)
Can I use the -d flag with a TLSv1.3 connection? i.e. Skip the cert verify?
I'm not having any success using Wolf to connect to a TLSv1.3 site.
The handshake fails at the client-hello. i.e. The server response with an Alert (Handshake failure)
The WolfSSL.com site does not appear to support TLSv1.3.
I can't connect to it w/ a FireFox browser (force TLSv1.3).
I can't run: client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com-p 443 -g -A ./certs/wolfssl-website-ca.pem
WireShark tags the Wolf TLS activity as TLSv1.2 though I see what looks like v1.3 payloads.
I get the same behavior from: client -h 104.28.30.12 -p 443 -d -b 40 -v 4 -g -l TLS13-AES128-GCM-SHA256
(This may just be a WireShark issue, but something seems to be missing.)
Using FFox I can connect w/ TLSv1.3 to istlsfastyet.com and WireShark does tag the TLS traffic as v1.3.
Would you have any idea what I may be doing wrong?
Thanks for the settings.
In addition to your settings, I still need #define HAVE_AEAD to get a successful build.
client.exe does support -v 4
WOLFSSL_LIB needs to be defined for the client build to pull in user_settings.h
Added this to user-settings.h
// Add TLSv1.3 support to lib
#define WOLFSSL_TLS13
#define HAVE_AEAD
// Add TLSv1.3 support to examples
#define HAVE_HKDF
#define WC_RSA_PSS
The Lib & most examples build. I'm unable to send the TLS1.3 traffic as the client doesn't appear to support -v 4
Thank you for reviewing this.
I must conclude the same,.. hitting a timeout for the server.
Gmail fails the handshake.
Yahoo fails the handshake.
Outlook works reliably.
I'm not able to get the benchmark built.
I have run the client benchmark on the HTTP sites. It appears -b does not support SMTP (-M smtp).
client -h 13.107.21.200 -p 443 -d -b 40
(bing.com)
wolfSSL_connect avg took: 48135.322 milliseconds
Others have suggested that TLS will add 45-60 SECONDS of overhead.
I will add TLSv1.3 to the Wolf lib. There doesn't seem to be an easy way to add this for a VStudio build. i.e Something more than: #define WOLFSSL_TLS13 The manual say's the code is supported but fails to say how to include it.
Is there a single #def that adds TLSv1.3?
I'm building WolfSSL for WinCE6. See this:https://www.wolfssl.com/forums/topic119 … tings.html Building the static lib is pretty straight forward. Getting the example apps working takes some effort.
WinCE5 is not much different.
There is not attached file.
308 is a general socket failure error. I say general because there are many things that can cause the socket to close.
If you sniff the Enet traffic you will get a better understanding of why the socket is closing.
Have you tried just building it?
Client and server are both under 256K for my build.
If I wanted to decrease the size I would play with the build switches in settings.h
I doubt you can drop the size considerably.
To get the example utilities working (server, client, echo,..) you will need to fix the path to the certificates in test.h. Then copy the wolf /cert/ folder to the device.
Change the #def's for the certificate files:
#define caCertFile "./certs/ca-cert.pem"
to something like:
#define caCertFile "/Program Files/certs/ca-cert.pem"
(There is no concept of a relative path in WinCE.)
I've got Wolf ver3.14 running on a WinCE6 device. It is running an SMTP client. I'm not having much success getting through the TLSv1.2 handshake. If I try to connect to my own PostFix server I have consistent success. If I try to connect to Gmail or Yahoomail I have a 98% failure rate. I suspect the server is closing the TCP session due to an improper handshake. I'm unable to prove this. The only feedback I get is the server closing the session [FIN, ACK].
I have attached a *.CAP of the traffic. There are a few TCP issues. (This is a high latency [many seconds], low bandwidth [modem] use case.) I'm thinking the latency is not an issue for the handshake as TCP will address these issues.
Is there anything that jumps out as a TLS issue? As in, why does the handshake die?
I can't tell if I am chasing a TLS, TCP, or firewall issue.
Thanks
Thank you, the wall of text is what I was looking for.
Your root CA works with: client.exe -M smtp -h 67.195.228.95 -p 587 -A .\certs\external\otherRootCA.pem
The CA root I was using came from a Win machine. It matches an intermediate CA this is also posted here: https://www.symantec.com/theme/roots
It appears I was using an intermediate certificate. Using DigiCert's Certificate Installation Checker the servers certificate chain is:
0) CN=smtp.mailyahoo.com
1) CN=Symantic Class 3 Secure Server CA - G4
2) CN=VeriSign Class 3 Plublic Primary Certification Authority - G5
3) OU=Class 3 Public Primary Certification Authority
I found #2 in the chain on a Win machine. It appeared to be a root as the "issuer" and "subject" strings were indentical.
The cert that does work (the posted one) looks like the root of the chain (#3).
So now I'm left with, how do I know which cert I need to authenitcate the server with?
i.e. I thought I had the right one. It looked like a match. But it was wrong. So me looking at strings, date windows is not a good approach.
Why didn't #2 in the chain work?
i.e. It is a valid intermediate cert, but it doesn't work.
I'm not sure if these are easy Q's to address. I've been looking for answers on the web and not having much success.
Thanks for the support.
I'm chasing a certificate issue.
Using: #define LIBWOLFSSL_VERSION_STRING "3.14.0"
Building the client.exe example for win32
Works with this cmd: client.exe -M smtp -h 67.195.228.95 -p 587 -d
Does not work with this cmd: client.exe -M smtp -h 67.195.228.95 -p 587 -A .\certs\external\verisignPublicCls3.pem -c .\certs\external\mailyahoocom.pem
Using smtp.mail.yahoo.com (67.195.228.95) as my test site.
Both the server certificate and the root appear to be valid (thumbprint) and current (dates).
There is another cert in the server-cert chain from symantec, but that is identical to the verisign CA.
The only issue I can see is the serial# of the verisign CA is different from the serial in the server-cert.
(Does that matter?)
I could use some guidance as to why peer cert is failing.
wolfSSL_connect error -188, ASN no signer error to confirm failure
My root CA (verisignPublicCls3.pem from verisign) is:
-----BEGIN CERTIFICATE-----
MIIE0zCCA7ugAwIBAgIQGNrRniZ96LtKIVjNzGs7SjANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMDYxMTA4MDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJpU2ln
biwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJp
U2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y
aXR5IC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCvJAgIKXo1
nmAMqudLO07cfLw8RRy7K+D+KQL5VwijZIUVJ/XxrcgxiV0i6CqqpkKzj/i5Vbex
t0uz/o9+B1fs70PbZmIVYc9gDaTY3vjgw2IIPVQT60nKWVSFJuUrjxuf6/WhkcIz
SdhDY2pSS9KP6HBRTdGJaXvHcPaz3BJ023tdS1bTlr8Vd6Gw9KIl8q8ckmcY5fQG
BO+QueQA5N06tRn/Arr0PO7gi+s3i+z016zy9vA9r911kTMZHRxAy3QkGSGT2RT+
rCpSx4/VBEnkjWNHiDxpg8v+R70rfk/Fla4OndTRQ8Bnc+MUCH7lP59zuDMKz10/
NIeWiu5T6CUVAgMBAAGjgbIwga8wDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E
BAMCAQYwbQYIKwYBBQUHAQwEYTBfoV2gWzBZMFcwVRYJaW1hZ2UvZ2lmMCEwHzAH
BgUrDgMCGgQUj+XTGoasjY5rw8+AatRIGCx7GS4wJRYjaHR0cDovL2xvZ28udmVy
aXNpZ24uY29tL3ZzbG9nby5naWYwHQYDVR0OBBYEFH/TZafC3ey78DAJ80M5+gKv
MzEzMA0GCSqGSIb3DQEBBQUAA4IBAQCTJEowX2LP2BqYLz3q3JktvXf2pXkiOOzE
p6B4Eq1iDkVwZMXnl2YtmAl+X6/WzChl8gGqCBpH3vn5fJJaCGkgDdk+bW48DW7Y
5gaRQBi5+MHt39tBquCWIMnNZBU4gcmU7qKEKQsTb47bDN0lAtukixlE0kF6BWlK
WE9gyn6CagsCqiUXObXbf+eEZSqVir2G3l6BFoMtEMze/aiCKm0oHw0LxOXnGiYZ
4fQRbxC1lfznQgUy286dUV4otp6F01vvpX1FQHKOtw5rDgb7MzVIcbidJ4vEZV8N
hnacRHr2lVz2XTIIM6RUthg/aFzyQkqFOFSDX9HoLPKsEdao7WNq
-----END CERTIFICATE-----
My cert (mailyahoocom.pem from smtp.mail.yahoo.com) is:
-----BEGIN CERTIFICATE-----
MIIJsTCCCJmgAwIBAgIQCXfyB0NZxfGNjChPcUhC1DANBgkqhkiG9w0BAQsFADBw
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMS8wLQYDVQQDEyZEaWdpQ2VydCBTSEEyIEhpZ2ggQXNz
dXJhbmNlIFNlcnZlciBDQTAeFw0xODAzMTMwMDAwMDBaFw0xODA5MTQxMjAwMDBa
MIGSMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTESMBAGA1UEBxMJ
U3Vubnl2YWxlMR0wGwYDVQQKExRZYWhvbyBIb2xkaW5ncywgSW5jLjEfMB0GA1UE
CxMWSW5mb3JtYXRpb24gVGVjaG5vbG9neTEaMBgGA1UEAwwRKi5sb2dpbi55YWhv
by5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCxEWtJYgC+mmzd
YzBmloExi8Cm45j6GHBn5nXrZQ7qkeEPvgGIvPw11S0rpVKhK6q2Cb1p85fQJn/Y
iY3pOrNcRACbr+rCNZodDwBh1J10ztMtjwDSiLmu7Qpr4zi80b54lGCaS9Th7PuY
eYCxCeszbv0aHZzily5KMtRsBJf6OFfqmdrpMGpR9txlB7MT65OnZFK2zM+SeACS
7GUzC/4niDv4Uq0Obi/iIayRiWMQLCal08Ec/9T8U1SxDKPwBOhYcCMwuaEhsunx
NPH6lemYT0iJYOTKkgoRciN+b3tFV72NBpQ7QE3Zzvc7cYHVsNnqfLp9nkLEOv2u
ZpDwYYynAgMBAAGjggYiMIIGHjAfBgNVHSMEGDAWgBRRaP+QrwIHdTzM2WVkYqIS
uFlyOzAdBgNVHQ4EFgQURRWvcE1clbMr1PbnOqdQErAL7a0wggNJBgNVHREEggNA
MIIDPIIRKi5sb2dpbi55YWhvby5jb22CD2xvZ2luLnlhaG9vLmNvbYIObWFpbC55
YWhvby5jb22CEm1haWwueWFob28taW5jLmNvbYITZmIubWVtYmVyLnlhaG9vLmNv
bYIOZWRpdC55YWhvby5jb22CDG1lLnlhaG9vLmNvbYIYb3Blbi5sb2dpbi55YWhv
b2FwaXMuY29tghhidC5lZGl0LmNsaWVudC55YWhvby5jb22CHXZlcml6b24uZWRp
dC5jbGllbnQueWFob28uY29tghBvcGVuaWQueWFob28uY29tgiBub3RpZnkuc2Jj
LmVkaXQuY2xpZW50LnlhaG9vLmNvbYIkbm90aWZ5LnZlcml6b24uZWRpdC5jbGll
bnQueWFob28uY29tgg9jNS5haC55YWhvby5jb22CEGM1YS5haC55YWhvby5jb22C
EG1sb2dpbi55YWhvby5jb22CD2xvZ2luLnlhaG9vLm5ldIIUYWNjb3VudGtleS55
YWhvby5jb22CECouZWRpdC55YWhvby5jb22CECoubWFpbC55YWhvby5jb22CEWFw
aS5yZWcueWFob28uY29tghVlZGl0LmNsaWVudC55YWhvby5jb22CDWxvZ2luLmFv
bC5jb22CEmxvZ2luLmVuZ2FkZ2V0LmNvbYISbG9naW4uYXV0b2Jsb2cuY29tghNs
b2dpbi5tb3ZpZWZvbmUuY29tghFhcGkubG9naW4uYW9sLmNvbYIWYXBpLmxvZ2lu
LmVuZ2FkZ2V0LmNvbYIWYXBpLmxvZ2luLmF1dG9ibG9nLmNvbYIXYXBpLmxvZ2lu
Lm1vdmllZm9uZS5jb22CFGxvZ2luLnRlY2hjcnVuY2guY29tghhhcGkubG9naW4u
dGVjaGNydW5jaC5jb22CEGxvZ2luLnR1bWJsci5jb22CFGFwaS5sb2dpbi50dW1i
bHIuY29tghJsb2dpbi5tYXBxdWVzdC5jb22CFmFwaS5sb2dpbi5tYXBxdWVzdC5j
b22CECoubG9naW4ub2F0aC5jb22CFmFwaS5zY3JlZW5uYW1lLmFvbC5jb22CEmFw
aS5sb2dpbi5vYXRoLmNvbTAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYB
BQUHAwEGCCsGAQUFBwMCMHUGA1UdHwRuMGwwNKAyoDCGLmh0dHA6Ly9jcmwzLmRp
Z2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNi5jcmwwNKAyoDCGLmh0dHA6Ly9j
cmw0LmRpZ2ljZXJ0LmNvbS9zaGEyLWhhLXNlcnZlci1nNi5jcmwwTAYDVR0gBEUw
QzA3BglghkgBhv1sAQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNl
cnQuY29tL0NQUzAIBgZngQwBAgIwgYMGCCsGAQUFBwEBBHcwdTAkBggrBgEFBQcw
AYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tME0GCCsGAQUFBzAChkFodHRwOi8v
Y2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEySGlnaEFzc3VyYW5jZVNl
cnZlckNBLmNydDAMBgNVHRMBAf8EAjAAMIIBBQYKKwYBBAHWeQIEAgSB9gSB8wDx
AHcAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFiIaK2AAAABAMA
SDBGAiEAlsfgpNcCREnDH6/MnbMNYeGxdyb7uc+kn1HcXl7WMYUCIQC9x4+m5SMu
slAkxqwP1cCwrEg9sFnPEQ4SYzlUZ3kstwB2AG9Tdqwx8DEZ2JkApFEV/3cVHBHZ
AsEAKQaNsgiaN9kTAAABYiGito8AAAQDAEcwRQIhALYPeOheGlCNLCAQGdQFBjA0
Dzm4n6vi6x6zWbaXYKWCAiAu0vMF6LaTo/2jec6f8McdyAyvRW3RR08lWiWlmNSX
jzANBgkqhkiG9w0BAQsFAAOCAQEAkuJwnopHe9UxQOzyknxOWn9egJ+Kx52ipGnl
QJVrBudA9agxPTMsJGkdwcd60hDlxR2++rd8hA25fdSVl24tq+5ReKvww0u5K64O
A6HJkAjsNS/Zn/F5nf93DIlHCPGL4wyriE5GzRQFbxjJ1xcEZ8vrQmGjN+2YmNjI
iGkelgKY7dYx/XCNYmIDz4bWj5oNjCrNqjKDUWkwI+kTagbHpLUTEcoNi8dXCnVE
JWy6xzQHMcTAlnPe64fharTDOxG37O8/6rJGWKJqlbiYJS555C1M3yDMjA8DzfNg
WfnUU36Eizi1oSKElQ/5oho4wi9fXL8s/X1ZYapQzhVewPjR9Q==
-----END CERTIFICATE-----
From the README file:
wolfSSL takes a different approach to certificate verification than OpenSSL
does. The default policy for the client is to verify the server, this means
that if you don't load CAs to verify the server you'll get a connect error,
no signer error to confirm failure (-188).
In the wolfSSL root directory you will find a solution file called "wolfssl64.sln". By default this is set for VS 2008.
wolfssl64.sln is for VS2010
wolfssl.sln is for VS2008
Other issues (and my fixes) I had:
wolfssl.lib
Not found: windows_time() #include <time> time_t windows_time(time_t* x);
Not found: rewind() #define rewind(x) fseek(x,0,0)
Not found: getenv() #undef OPENSSL_EXTRA
client.exe (and the other extras)
Missing windows APIs: SetCurrentDirectory(), FindFirstFileA(), FindNextFileA() - mine is a UNICODE build
WINBASEAPI
BOOL
WINAPI
SetCurrentDirectoryA(__in LPCSTR lpPathName) {return 0;} //a hack
WINBASEAPI
HANDLE
WINAPI
FindFirstFileA(LPCSTR lpFileName, LPWIN32_FIND_DATAA lpFindFileData) {
struct _WIN32_FIND_DATAW findFileDataW;
wchar_t fileNameW[MAX_PATH];
swprintf(fileNameW, L"%s",lpFileName); // or MultiByteToWideChar
findFileDataW.dwFileAttributes = lpFindFileData->dwFileAttributes;
findFileDataW.ftCreationTime = lpFindFileData->ftCreationTime;
findFileDataW.ftLastAccessTime = lpFindFileData->ftLastAccessTime;
findFileDataW.ftLastWriteTime = lpFindFileData->ftLastWriteTime;
findFileDataW.nFileSizeHigh = lpFindFileData->nFileSizeHigh;
findFileDataW.nFileSizeLow = lpFindFileData->nFileSizeLow;
findFileDataW.dwOID = 0; // CE object identifier
// reserved0 - used by file Attributes if reparse is supported
// reserved1 - for future use
swprintf(findFileDataW.cFileName,L"%s", lpFindFileData->cFileName);
// alternatFileName - the old 8.3 filename format
return FindFirstFileW(fileNameW, &findFileDataW);
}
WINBASEAPI
BOOL
WINAPI
FindNextFileA(HANDLE hFindFile, LPWIN32_FIND_DATAA lpFindFileData) {
struct _WIN32_FIND_DATAW findFileDataW;
findFileDataW.dwFileAttributes = lpFindFileData->dwFileAttributes;
findFileDataW.ftCreationTime = lpFindFileData->ftCreationTime;
findFileDataW.ftLastAccessTime = lpFindFileData->ftLastAccessTime;
findFileDataW.ftLastWriteTime = lpFindFileData->ftLastWriteTime;
findFileDataW.nFileSizeHigh = lpFindFileData->nFileSizeHigh;
findFileDataW.nFileSizeLow = lpFindFileData->nFileSizeLow;
findFileDataW.dwOID = 0; // CE object identifier
// reserved0 - used by file Attributes if reparse is supported
// reserved1 - for future use
swprintf(findFileDataW.cFileName,L"%s", lpFindFileData->cFileName);
// alternatFileName - the old 8.3 filename format
return FindNextFileW(hFindFile, &findFileDataW);
}
The answer to my question: What mechanism do you have to find the outside/SDK code?
Per the user manual, customizing and porting section, user_settings.h
The preprocessor define "WOLFSSL_USER_SETTINGS" is needed to include the file.
Attempting to build WolfSSL using the wolfssl.sln (VS2008, WEC6)
It is failing to find my time.h. This would typically be found in my precompiled header.
I am wondering where to add this so it seen by the whole project. (Rather than modify each file: wc_port.c, ssl.c,..)
I have found the settings.h file but I am unsure if this is the best place to put this for your build.
What mechanism do you have to find the outside/SDK code?
Thanks
Pages 1
wolfSSL - Embedded SSL Library → Posts by Frank42
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.021 seconds (95% PHP - 5% DB) with 4 queries