I run a web socket server that requires clients to present a certificate.
context_ssl_ = libwebsocket_create_context(wssPort_, wssIpAddr_.c_str(), protocols_ssl,
libwebsocket_internal_extensions,
cert_path.c_str(), key_path.c_str(), -1, -1,
LWS_SERVER_OPTION_REQUIRE_VALID_OPENSSL_CLIENT_CERT);
I am getting a crash in the OpenSSL_verify_callback().
The SSL_get_ex_data() call is returning NULL
I could not find a call to SSL_set_ex_data() for server mode operation.
Has anyone seen this crash in the newer versions?
Signed-off-by: Larry Hayes <larry.hayes@prodeasystems.com>
This patch allows control of the main compiletime constants in libwebsockets
from the configure commandline.
README is updated with documentation on what's available, how to set them
and the defaults.
The constants are logged with "info" severity (not visible by default) at
context create time.
The zlib constant previously exposed like this is moved to private-libwebsockets.h
so it can be printed along with the rest.
Signed-off-by: Andy Green <andy.green@linaro.org>
David found that uclibc did not provide this slightly esoteric api
and provided one from BSD that can be built by the library internally.
AG: Made contingent on configure option --enable-builtin-getifaddrs
Signed-off-by: David <cymerio@gmail.com>
Signed-off-by: Andy Green <andy.green@linaro.org>
- multiple debug context calls lwsl_ err, warn, debug, parser, ext, client
- api added to set which contexts output to stderr using a bitfield log_level
- --disable-debug on configure removes all code that is not err or warn severity
- err and warn contexts always output to stderr unless disabled by log_level
- err and warn enabled by default in log_level
Signed-off-by: Andy Green <andy@warmcat.com>
Shay noticed we're no longer initializing the initial lookup of
server canonical hostname correctly
Reported-by: Shay Zuker <shay@boxee.tv>
Signed-off-by: Andy Green <andy.green@linaro.org>
When creating a context with NULL extensions list,
a segmentation fault was yelled when trying to
destroy the context. This checks if the
extension list is NULL before go through the list.
Signed-off-by: Paulo Roberto Urio <paulourio@gmail.com>
I was under the impression extensions could be null, so heres a patch to fix this error in libwebsockets. Cheers!
Signed-off-by: Andrew Chambers <andrewchamberss@gmail.com>
--
Ken found over the internet with real delays, SSL_connect can
fail to work. This patch adapts his workaround to stay in the
connect state until we either run out of time for the connect
or succeed.
Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Ken Atherton <katherton@echofirst.com>
Found an issue in libwebsockets - if a server sends a message within its "onopen" context then the message is getting swallowed and not passed to calling client (means LWS_CALLBACK_CLIENT_RECEIVE is never getting called).
I've fixed the bug - pls find attached patch.
Signed-off-by: Yonathan Yusim <yonathan@boxee.tv>
Signed-off-by: Andy Green <andy@warmcat.com>
This prevents a problem observed on Windows whereby a client that
disconnects before fully establishing the WebSocket would cause the
server to use 100% CPU since recv() would continually return -1 for that
socket.
Signed-off-by: Nick Dowell <nick@nickdowell.com>
While the protocol specification gives example of the
human-readable message associated with a 101-code reply,
nowhere does it actually enforce it. Ws4py gevent middleware
is known to have a message other than "Switching Protocols".
This quietens the spew so all typical debug info now is coming from
the user code (mirror protocol in the sample server / client case).
Signed-off-by: Andy Green <andy@warmcat.com>
