See our wiki page.
netty / netty-tcnative Goto Github PK
View Code? Open in Web Editor NEWA fork of Apache Tomcat Native, based on finagle-native
License: Apache License 2.0
A fork of Apache Tomcat Native, based on finagle-native
License: Apache License 2.0
See our wiki page.
My build of netty-tcnative fails because it tries to download
https://oss.sonatype.org/content/repositories/snapshots/io/netty/netty-tcnative/1.1.32.Fork1-SNAPSHOT/netty-tcnative-1.1.32.Fork1-SNAPSHOT-native-src.zip
which is a 404 (I guess you have it cached or it is in some other repo?).
(I do not know if it would succeed on Solaris, but I can't even find out...)
This in turn causes netty issue 2668 and my netty build fails.
And that in turn causes my build of Scamper to fail because Jenkins local repo contains a mix of downloaded and locally built JARs.
I think if netty-tcnative gets fixed, the rest of the problems will solve themselves. Anything we can do here?
I am trying to use the netty-tcnative libraries for my grpc application in a docker container. When i use the prebuilt binary I get the following error:
Inconsistency detected by ld.so: dl-lookup.c: 128: check_match: Assertion `version->filename == ((void *)0) || ! _dl_name_match_p (version->filename, map)' failed!
In the transition from 1.1.33.Fork12
to 1.1.33.Fork13
, the native implementation of SSLContext.make
in sslcontext.c
was restructured to use a switch
statement, rather than a series of if .. else if
statements. In the process, the default case when not finding an exact match for protocol
changed from SSLv23_method
to TLSv1_2_method
.
This is coupled with the fact that netty-4.0.35.Final
was compiled against netty-tcnative-1.1.33.Fork11
means that protocol
will not be correct by default. The value in Fork11
was 28
(SSL_PROTOCOL_TLSV1 | SSL_PROTOCOL_TLSV1_1 | SSL_PROTOCOL_TLSV1_2
), and this is compiled into the .class
file for OpenSslContext
in netty-all
.
Unfortunately, this is not the correct value, and with the restructuring to a switch
statement, this value doesn't match any particular case and falls through to the new default: TLSv1_2_method
. Client versions < TLSv1.2 then stop working, because the server no longer supports them.
Don't know if this is netty or netty-tcnative related: netty/netty#4722
we need to get at least boringssl-static building on windows, but it would be nice to get all variants building on mac, linux, and windows.
Gradle seems to be a little stricter than maven when resolving artifacts that use classifiers. In particular it doesn't like the fact that the artifact name in the pom being simply 'netty-tcnative' when it has to resolve it in the repo in separate location
Could not resolve all dependencies for configuration ':grpc-benchmarks:compile'.
Could not resolve io.netty:netty-tcnative-boringssl-static:1.1.33.Fork12-SNAPSHOT.
Required by:
io.grpc:grpc-benchmarks:0.13.0-SNAPSHOT
Could not resolve io.netty:netty-tcnative-boringssl-static:1.1.33.Fork12-SNAPSHOT.
> inconsistent module metadata found. Descriptor: io.netty:netty-tcnative:1.1.33.Fork12-SNAPSHOT Errors: bad module name: expected='netty-tcnative-boringssl-static' found='netty-tcnative'
Will take a look at fixing....
From @fsiegrist netty/netty#5150:
The MANIFEST.MF of netty-tcnative-1.1.33.Fork15-[os-classifier].jar does not contain the Bundle-NativeCode
header. Thus when running in an OSGi context (e.g. apache-felix), the bundle does not know the path to its native library (META-INF/native/...). As a result, the NativeLibraryLoader
(in netty-common) cannot load the native library, because the call to loader.getResource("META-INF/native/lib" + name + ".jnilib")
returns null.
After having manually added the following entry to the MANIFEST.MF (of the osx specific version of the netty-tcnative jar), the resource can be found:
Bundle-NativeCode: META-INF/native/libnetty-tcnative.jnilib;osname=macosx; processor=x86; processor=x86_64
A recent discovery (#68 (diff)) has brought up a passing an invalid pointer type is flagged as a warning and still compiles. It turned out this pointer was not used in the method, but if it was undefined results would have followed. We should analyze warnings, and consider turning some (all?) warning into errors to ensure code quality.
Get the following warning when VM (Oracle 7 64 bit) starts
Java HotSpot(TM) 64-Bit Server VM warning: You have loaded library /tmp/libnetty-tcnative9180597608360647425.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c ', or link it with '-z noexecstack'.
Since we have started supporting the static library builds the directory structure is no longer following the standard maven directory structure. This can make discovery and IDE interop more difficult. Is it possible to put the java/c code back to the "top" level so maven can correctly generate IDE project files?
I was trying to enable SSL_MODE_RELEASE_BUFFERS
mode on my context pointer, in order to reduce memory usage of my application.
This is done by:
(SSLExt/sslCtxSetMode (.sslCtxPointer context) SSLExt/SSL_MODE_RELEASE_BUFFERS)
However, I am always getting error:
UnsatisfiedLinkError org.apache.tomcat.jni.SSLExt.sslCtxSetMode(JJ)J org.apache.tomcat.jni.SSLExt.sslCtxSetMode (SSLExt.java:-2)
This has been tested on Ubuntu with self-compiled openssl 1.0.1p and 1.0.2d, and ArchLinux with latest 1.0.2d.
The ldd result on my ubuntu box:
linux-vdso.so.1 => (0x00007fffc8ebf000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fa17e5c2000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fa17e1e7000)
libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fa17dfb5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fa17dd98000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa17d9d8000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa17d7d3000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fa17d5bc000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fa17d3b7000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa17ea56000)
and my archlinux
linux-vdso.so.1 (0x00007ffc2e9dd000)
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007fc6c5291000)
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007fc6c4e1a000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00007fc6c4be5000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fc6c49c7000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fc6c4623000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fc6c441f000)
libz.so.1 => /usr/lib/libz.so.1 (0x00007fc6c4208000)
libuuid.so.1 => /usr/lib/libuuid.so.1 (0x00007fc6c4003000)
librt.so.1 => /usr/lib/librt.so.1 (0x00007fc6c3dfb000)
libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007fc6c3bc2000)
/usr/lib64/ld-linux-x86-64.so.2 (0x0000555797123000)
Just got no idea about this issue, so any question/help is welcomed. Thanks!
Hello,
Why EpollChannelOption.TCP_QUICKACK is an Integer option ?
In the code, it seems to me that it should be a Boolean, as can be seen in EpollSocketChannelConfig#getOption(ChannelOption), L.105.
Cheers,
Frรฉdรฉric.
[INFO] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/pool.c -fno-common -DPIC -o src/.libs/pool.o
[INFO] /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/proc.lo src/proc.c
[INFO] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/proc.c -fno-common -DPIC -o src/.libs/proc.o
[INFO] /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/shm.lo src/shm.c
[INFO] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/shm.c -fno-common -DPIC -o src/.libs/shm.o
[INFO] /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c -o src/ssl.lo src/ssl.c
[INFO] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./src -I/usr/local/opt/openssl/include -I/usr/local/opt/openssl/include/openssl -I/usr/local/opt/openssl/include -O3 -Werror -I/usr/include/apr-1 -D_LARGEFILE64_SOURCE -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/Home/include/darwin -c src/ssl.c -fno-common -DPIC -o src/.libs/ssl.o
[INFO] src/ssl.c:2085:2: error: OpenSSL is required!
[INFO] #error OpenSSL is required!
[INFO] ^
[INFO] 1 error generated.
[INFO] make: *** [src/ssl.lo] Error 1
[INFO] rc: 2
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Netty/TomcatNative [Parent] ........................ SUCCESS [ 3.078 s]
[INFO] Netty/TomcatNative [OpenSSL - Dynamic] ............. FAILURE [ 25.502 s]
[INFO] Netty/TomcatNative [OpenSSL - Static] .............. SKIPPED
[INFO] Netty/TomcatNative [BoringSSL - Static] ............ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 28.886 s
[INFO] Finished at: 2016-04-04T14:22:18-04:00
[INFO] Final Memory: 19M/298M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.fusesource.hawtjni:maven-hawtjni-plugin:1.11:build (build-native-lib) on project netty-tcnative: build failed: org.apache.maven.plugin.MojoExecutionException: make based build failed with exit code: 2 -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
[ERROR]
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR] mvn <goals> -rf :netty-tcnative
$ env | grep C*FLAGS
LDFLAGS=-L/usr/local/opt/openssl/lib
CPPFLAGS=-I/usr/local/opt/openssl/include
$ brew install openssl
Warning: openssl-1.0.2g already installed
It is common practice whenever tcn_ssl_ctxt_t->cb_data
is used to check for NULL
, and if NULL
to then use a temporary variable which is set to tcn_password_callback
. It seems like tcn_ssl_ctxt_t->cb_data
should be set in sslcontext.c
's make
method by the SSL_CTX_set_default_passwd_cb_userdata
method. Are these NULL
checks and temporary variables necessary?
netty-tcnative-1.1.33.Fork2-linux-x86_64.jar is 422.7K, whereas osx-x86_64 and windows-x86_64 are ~125K.
libnetty-tcnative.so is actually 996K in size. Stripping it reduced it to 163K and the JAR itself to 129K.
I would like to propose removing all code that we not need for netty (like Socket
, Multicast
and many more). We are only interested in the parts that are needed for our OpenSslEngine anyway. This will help us to focus on things we care about and not ship things that we are not using.
@nmittler @Scottmitch @trustin WDYT ?
From @junjiemars:
@trustin I resolved the issue: io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 can not be found on 32-bit Linux,
- git clone netty-tcnative.git
- run
mvn -X compile
, it will be failed on 32-bit Linux- found the Makefile under the ./target/native-build, insert
-DLARGEFILE64_SOURCE
intoCFLAGS
section nearly 262 line- comment 2
<forceAutogen .../>
and<forceConfigure .../>
sections in pom.xml- run
mvn -X install
to install io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 into local repository- now, io.netty:netty-tcnative:jar:linux-x86_32:1.1.32.Fork1 can be found by maven, done.
Seems like the user experienced a build problem when building on 32-bit Linux
Are the builds for the static libraries "cleaned" every time? It seems the following commands will run through 2 complete builds of the static libraries:
mvn clean install
mvn install
Is it possible to avoid "cleaning" everything and "rebuilding" every time?
Currently, sslutils.c has the following code:
#ifdef WIN32
rv = WIN32_SSL_password_prompt(data);
#elif !defined(OPENSSL_IS_BORINGSSL)
EVP_read_pw_string(data->password, SSL_MAX_PASSWORD_LEN,
data->prompt, 0);
#else
des_read_pw_string(data->password, SSL_MAX_PASSWORD_LEN,
data->prompt, 0);
#endif
This would have des_read_pw_string
called in the BoringSSL case, which does not exist. I suspect that this builds for some developers because the include may be getting pulled in from openssl. Not entirely sure.
Not a bug deal but I had to do
export CFLAGS=-fPIC
to get the profile to work correctly
@Scottmitch I'm assigning to you for now, since you mentioned you'd take a look.
Hi,
I followed the link http://netty.io/wiki/forked-tomcat-native.html#wiki-h2-5 to find 64-bit windows APR DLLs, but the links are broken, due to maybe CI Server changes (jenkins => TeamCity).
Further more, I scanned https://garage.netty.io/teamcity/, but it does seem not build for Windows at all.
Am ideas?
Hi,
Do you plan to support SSL_CTX_set_mode operation? In some cases enabling SSL_MODE_ENABLE_PARTIAL_WRITE and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER modes is necessary but as you pointed out in #81 SSLExt is not supported and there is not any other way to set them.
https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_mode.html
Seems related to #46 / #44... anyhow, we're getting:
java.lang.UnsatisfiedLinkError: /tmp/libnetty-tcnative3858998603798039886.so: libssl.so.1.0.0: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_20]
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1929) ~[na:1.8.0_20]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1814) ~[na:1.8.0_20]
at java.lang.Runtime.load0(Runtime.java:809) ~[na:1.8.0_20]
at java.lang.System.load(System.java:1083) ~[na:1.8.0_20]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:193) ~[netty-common-4.1.0.Beta8.jar:4.1.0.Beta8]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:58) ~[netty-handler-4.1.0.Beta8.jar:4.1.0.Beta8]
... 54 common frames omitted
with 1.1.33 Fork 9 and 1.1.33 Fork 10.
It seems fork 6 used to work well.
hi! I'm wondering why netty-tcnative is laoding normal tomcat libraries, and not the library it is building.
The patch to fix it is:
# this patch is suspicious
# why netty-tcnative is building its own .so library, and still loading tomcat's one?
--- netty-tcnative-netty-tcnative-1.1.30.Fork2/src/main/java/org/apache/tomcat/jni/Library.java
+++ netty-tcnative-netty-tcnative-1.1.30.Fork2/src/main/java/org/apache/tomcat/jni/Library.java
@@ -24,7 +24,7 @@
public final class Library {
/* Default library names */
- private static final String [] NAMES = {"tcnative-1", "libtcnative-1"};
+ private static final String [] NAMES = {"netty-tcnative", "libnetty-tcnative", "netty-tcnative-1", "libnetty-tcnative-1"};
/*
* A handle to the unique Library singleton instance.
*/
Or remove native sources and build from the fork.
Thank you!
Just initializing the project files for the IDE mvn eclipse:eclipse
seems to build all of the static libraries. Is this necessary just for setting up the IDE project files (building the static libraries can take some time).
This is effectively a repeat of #45, but for boring and MB involved instead of KB. OS X's native library is 1.9 MB uncompressed, whereas Linux's is 7.1 MB. Running strip on the Linux .so reduces its size to 1.9 MB. I think that will change the compressed size from 2.5 MB to ~900 KB.
Hi,
I was following instructions from wiki
sudo apt-get install autoconf automake libtool make tar libapr1-dev libssl-dev
git clone https://github.com/netty/netty-tcnative.git
cd netty-tcnative
git checkout netty-tcnative-1.1.32.Fork1
mvn clean install
And getting :
[INFO] os.detected.name: linux
[INFO] os.detected.arch: x86_64
[INFO] os.detected.classifier: linux-x86_64
Exception in thread "main" java.lang.NoClassDefFoundError: org/eclipse/aether/RepositorySystemSession
at kr.motd.maven.os.DetectExtension.injectSession(DetectExtension.java:115)
at kr.motd.maven.os.DetectExtension.afterProjectsRead(DetectExtension.java:92)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:274)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: java.lang.ClassNotFoundException: org.eclipse.aether.RepositorySystemSession
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
... 15 more
netty/netty@2056aed#diff-6ba8edb6d8a5a127eba9cf97911c6f14R664
Currently, there's no way to get the detailed information about a cipher suite.
Hello. Documentation points to 1.1.33.Fork15
but it is not available in maven central.
Could you please advise which version I could use for 4.0.35.Final netty?
Given recent refactoring into multi-modules and added support for linking statically to OpenSSL libraries, we need to update the docs on the wiki for building netty-tcnative.
Some things that should be made clear (from #115):
Hi,
I was trying to use netty-tcnative for openssl functionality.
On my dev machine ubuntu 14.04 x86_64. I have libssl1.0.0-1.0.1f installed and softlinked to /lib/x86_64-linux-gnu/libssl.so.1.0.0 to /lib/x86_64-linux-gnu/libssl.so.10
I faced around symbol issues with openssl. here is ldd
output from so file.
ldd ~/Downloads/libnetty-tcnative.so
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libssl.so.10: version `libssl.so.10' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libcrypto.so.10: version `OPENSSL_1.0.1_EC' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
/home/paggarwal/Downloads/libnetty-tcnative.so: /lib/x86_64-linux-gnu/libcrypto.so.10: version `libcrypto.so.10' not found (required by /home/paggarwal/Downloads/libnetty-tcnative.so)
linux-vdso.so.1 => (0x00007ffd074fb000)
libssl.so.10 => /lib/x86_64-linux-gnu/libssl.so.10 (0x00007fe296160000)
libcrypto.so.10 => /lib/x86_64-linux-gnu/libcrypto.so.10 (0x00007fe295d85000)
libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007fe295b53000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe295935000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe295570000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe29536b000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fe295166000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe29660d000)
When I built netty-tcnative locally then I was able to use it.
here is another ldd
output
linux-vdso.so.1 => (0x00007ffe6cbf1000)
libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f7e41012000)
libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f7e40c37000)
libapr-1.so.0 => /usr/lib/x86_64-linux-gnu/libapr-1.so.0 (0x00007f7e40a05000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7e407e7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7e40422000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7e4021d000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f7e40018000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7e414c0000)
For further debugging I took a look at output of objdump -p
of local so file and so file downloaded via maven.
local
.
.
Version References:
required from libpthread.so.0:
0x09691a75 0x00 06 GLIBC_2.2.5
required from libc.so.6:
0x06969194 0x00 10 GLIBC_2.14
0x0d696914 0x00 09 GLIBC_2.4
0x09691974 0x00 08 GLIBC_2.3.4
0x0d696917 0x00 07 GLIBC_2.7
0x09691a75 0x00 04 GLIBC_2.2.5
required from libcrypto.so.1.0.0:
0x066a2b20 0x00 03 OPENSSL_1.0.0
required from libssl.so.1.0.0:
0x066a2b20 0x00 05 OPENSSL_1.0.0
0x066a2b21 0x00 02 OPENSSL_1.0.1
from mavencentral
.
.
.
.
Version References:
required from libpthread.so.0:
0x09691a75 0x00 05 GLIBC_2.2.5
required from libc.so.6:
0x0d696917 0x00 06 GLIBC_2.7
0x09691a75 0x00 04 GLIBC_2.2.5
required from libssl.so.10:
0x0a779bd0 0x00 03 libssl.so.10
required from libcrypto.so.10:
0x02b21533 0x00 08 OPENSSL_1.0.1_EC
0x066a2b21 0x00 07 OPENSSL_1.0.1
0x0af47420 0x00 02 libcrypto.so.10
Following dependency versions seems to be the cause of issue. any way to strip them from the build?
0x02b21533 0x00 08 OPENSSL_1.0.1_EC
0x0af47420 0x00 02 libcrypto.so.10
0x0a779bd0 0x00 03 libssl.so.10
We should review the usage of malloc and if we check if allocation failed.
java.lang.UnsatisfiedLinkError: /private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib: dlopen(/private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib, 1): Library not loaded: /usr/local/lib/libssl.1.0.0.dylib
Referenced from: /private/var/folders/5f/jc_d179x0qlbhm0kzxlssyl00000gn/T/libnetty-tcnative4749163000461898953.dylib
Reason: image not found
at java.lang.ClassLoader$NativeLibrary.load(Native Method) ~[na:1.8.0_45]
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1937) ~[na:1.8.0_45]
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1822) ~[na:1.8.0_45]
at java.lang.Runtime.load0(Runtime.java:809) ~[na:1.8.0_45]
at java.lang.System.load(System.java:1086) ~[na:1.8.0_45]
at io.netty.util.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:193) ~[netty-all-4.1.0.Beta6-20150726.163256-175.jar:4.1.0.Beta6-SNAPSHOT]
at io.netty.handler.ssl.OpenSsl.<clinit>(OpenSsl.java:58) ~[netty-all-4.1.0.Beta6-20150726.163256-175.jar:4.1.0.Beta6-SNAPSHOT]
When using 1.1.33.Fork3
with netty 4.1.0.Beta6-SNAPSHOT
on OS X. there is no exception thrown.
openssl version: 1.0.2d_1
(installed by homebrew)
openssl path: /usr/local/opt/openssl/lib
PKCS12_verify_mac (sslcontext.c)
CONF_modules_unload (ssl.c)
@nmittler asked me to file a bug here when we were ready to switch BoringSSL's MSVC version. BoringSSL tracks Chromium's MSVC version which has since switched to MSVC 2015. It should currently build with either, but I'll be switching our bots to 2015 soonish and it'll likely (accidentally or intentionally) break with 2013 when we're no longer regularly testing against it.
The DefaultHttp2ConnectionEncoder
does not handle integer overflow when merging frames. Merge attempts should fail when integer overflow of the total size will occur: https://github.com/netty/netty/blob/4.1/codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2ConnectionEncoder.java#L360
It seems like one or more of 02fd410, c8a6e7c, and ef7cd7e broke the windows build.
@normanmaurer and @fondemen, could you please take a look and fix it?
We may want to consider init the constants via a JNI call so we are sure these are correct.
#71 (comment)
I'm really excited about the statically-linked packages that have just gone out, and also what might come out of #113. I've been trying to figure out whether I can use statically-linked tcnative across the board for a project, and am realizing that some information about system requirements is a little tricky to come by. As recently as ca90f9e, it's not immediately obvious from the README which operating systems/JDKs are supported by netty-tcnative. Some questions I had that didn't have immediate answers:
Thanks!
The load_pem_key method in sslcontext.c has a loop to call PEM_read_bio_PrivateKey
3 times (or until success). Why is this loop necessary, and why 3 iterations? We should at least clarify this situation with comments.
Calling OpenSsl.version()
seems to result in the version that it was compiled against. I tried building openssl and setting LD_LIBRARY_PATH
, but it kept returning the same version (1.1.33.Fork6 seems to be built against 1.0.1e). The logic for OpenSsl.isAlpnSupported()
is based on version, so if it's broken, ALPN support is broken as well.
It seems that tc_native is using a macro to get the value:
netty-tcnative/src/main/c/ssl.c
Line 273 in be811ae
// From my local ssl.c...
TCN_IMPLEMENT_CALL(jint, SSL, version)(TCN_STDARGS)
{
UNREFERENCED_STDARGS;
fprintf(stderr, "NM: in new code");
return (jint) SSLeay();
}
TCN_IMPLEMENT_CALL(jstring, SSL, versionString)(TCN_STDARGS)
{
UNREFERENCED(o);
fprintf(stderr, "NM: in new code");
return AJP_TO_JSTRING(SSLeay_version(SSLEAY_VERSION));
}
However I still see the same problem. I had considered that the method may have been inlined, but it appears that the definition is in a c file (https://github.com/openssl/openssl/blob/6218a1f57e7e25a6b9a798f00cf5f0e56a02ff31/crypto/cversion.c#L104), so that should work.
Any ideas?
We should investigate what the purpose/value of the UNREFERENCED
and UNREFERENCED_STDARGS
macros are. We should clarify with comments what their purpose are if they are necessary. We should also consistently use them w.r.t to function pre-condition checks. For example some times we call UNREFERENCED
before a precondition check and return, and sometime we only call it if the preconditions are satisfied.
@normanmaurer
@gregw (for Jetty)
@kruton (for Conscrypt)
Conscrypt is an Apache 2 Licensed JSSE provider built on top of boringssl that has been developed by the Android team. It has had a non-trivial amount of tire-kicking and is used with OpenJDK on the server side at Google.
Merging efforts here would offer some major upside to the Java development community.
https://android.googlesource.com/platform/external/conscrypt/+/master
Even if they don't merge, having a solid alternative JSSE provider easily available would benefit lots of folks
Following up on netty/netty#5052, the wiki gives instructions for using an uber jar with fork15, but there won't be an uber jar until fork16.
For gRPC, we're interested in encouraging users to use tcnative instead of jetty-apln. This would work pretty well, except that lots of our users would be Debian/Ubuntu users. Having a pre-built binary for Debian is a prerequisite for us encouraging our users to use tcnative.
We would have little problem making our own builds of tcnative, but it seems that solving the "Debian vs Red Hat" problem would help tcnative in general.
The main problem I see is what to specify as the classifier for any Debian binary. The OS detector doesn't vary based on RHEL/Debian. We could just add "-debian" to the end and force users to hard-code when they are running on Debian. Not great, but better than nothing.
If combined with #24, we could solve it more cleanly as both variants of the Linux .so could be included in the JAR.
Rather than try to detect the OS at build time to determine which JNI library to place in META-INF/native, it would be better to package all of them and then let the NativeResourceLoader detect the OS/arch at runtime in order to load the appropriate library.
Detecting at build time is problematic because the build machine may not share the same OS/arch as the production environment. Also, this allows one artifact to be shared across multiple architectures.
What do you think?
The selection preference for the ALPN/NPN protocol negotiation process done by selectProtocols should be select the first local "supported" protocols that the peer advertises per alpn spec and npn tech spec - Protocol Negotiation Section. The iteration order is currently reversed.
Hello,
I am encountering this error:
Caused by: java.lang.AbstractMethodError: null
at org.apache.tomcat.jni.SSL.readFromSSL(Native Method) ~[netty-tcnative-1.1.33.Fork14-osx-x86_64.jar:1.1.33.Fork14]
at io.netty.handler.ssl.OpenSslEngine.readPlaintextData(OpenSslEngine.java:358) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:703) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:809) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1092) ~[netty-all-4.1.0.CR2.jar:4.1.0.CR2]
I am not sure exactly what it means, so any help is appreciated.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.