snx_CCC_browser::getMessageSize: header length is 279, content length found - 128 talkssl::client_handler: calling recv with dlen 411 talkssl::client_handler: got 411 bytes, wanted 512 bytes talkssl::client_handler: state: SSL_RECV - entering fwasync_mux_in: 6: managed to read 411 of 512 bytes
fwasync_mux_in: 6: got 0 of 512 bytes = 512 bytes required talkssl::client_handler: after sending packet fwasync_mux_out: 6: call: 80f2060 with 3 fwasync_mux_out: 6: managed to send 281 of 281 bytes fwasync_mux_out: 6: sent 0 of 281 bytes = 281 bytes to send fwasync_connbuf_realloc: reallocating 0 from 0 to 1305 talkssl::send_data: Entering for 281 bytes When looking into the debug log (-g option from command line) I see, that all is ok, but the communication on the end is not wrong, looks like a wrong format: =snx_CCC_browser::send_auth_message= From "connection aborted" I have shifted to "authentication failed". I am playing now with 800010003 from Checkpoint's site (link given by thanks), but no success. Looks like older versions of SNX are not able to work with TLS 1.1. proxy_user username for proxy authentication reauth enable automatic reauthentication. sslport The SNX SSL port (if not default) Snx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.2.5, stripped Snx snx_install.sh snx.n snx_uninstall.sh Snx.n: bzip2 compressed data, block size = 900k You can extract the snx binary: $ tail -n +78 snx_install.sh > snx.n it's very common on proprietary software for Linux. It's a compressed tar archive located at the end of the script.
0 kommentar(er)
