Backport upstream alignment fix to correct bus error on platforms
that require strict memory alignment such as SPARC
FS-8783 #resolve
From upstream:
commit 4d8430a504137509f23b5a19f8a06b6df0f651cc
Author: Jaap Keuter <jaap.keuter@xs4all.nl>
Date: Fri Nov 7 00:13:10 2014 +0100
While setting the IV for AES ICM the nonce is simply typecast from
a void * to a v128_t *. This breaches alignment requirements for
v128_t objects on platforms that require it.
Instead make a copy of the nonce to assure proper alignment.
Sofia will unpredictably close a tls transport during call setup. This
occurs when the epoll event loop wakes up the socket reader and SSL_read
returns an error because there is no packet on the socket. Normally
sofia will read the last error using SSL_get_error and return
SSL_ERROR_WANT_READ. Sofia gracefully handles this error and the
transport stays open. Sometimes, however, the worker thread will call
SSL_shutdown for a different transport, which can write an error to the
internal openssl error queue. If that error is not read off the queue,
the next time that SSL_get_error is called, it will read that unrelated
error.
The documentation for SSL_shutdown explains that there are three
possible results -1, 0 and 1 with, oddly, 1 indicating success. The -1
result code occurs when there is no handshake callback registered on the
connection. It can return 0 when there is still work to be done. The
documentation suggest that it is insufficient to call it just once. This
is why I added the do {} while () construct.
Although just the fix to SSL_shutdown was enough to resolve my issue, I
a also audited other calls to SSL_* functions and found a few other
cases where an error may be generated, but was not handled.
Misc code style fixes as well:
* Use static functions everywhere, no need to pollute the global namespace
* Rework some function names and variables to use lower case
Use the new parameter immediate-forwarding-numbers to configure
immediate forwarding logic that emulates hunt groups
The parameter syntax is:
[<span-name>:]<number>
Multiple elements can be specified separated by commas
If the <span-name> is specified, the span will be checked for
availability, if available, its number will be selected for
forwarding, otherwise next number will be checked
Forwarding is enabled as soon as a channel is answered and its
disabled when the channel is hung up
