SSL_Connect API is failing with return value 5 errno=2.
can any one help me in how to trace the same? can any one let me know what could cause this issue?
OS: Windows 2003 Std Sp2 32 bit
You can use following APIs to check the error further as it will store the error as a string in buf.
value = ERR_get_error();
ERR_error_string_n(value,buf,sizeof buf);
Furthermore, I also received this error when I added "SET_MODE_AUTO_RETRY" to CTX object and created an SSL object. I removed it and made changes to retry on my own in case of some error after some delay.
Another check you can do is what port value are you using? If it is not 443 then please try with 443; it may help.
I am also new to this so just sharing what I tried in order to resolve these issues.
Related
I am trying to authenticate user using FormLoginHandler and Postgresql Database with SqlAuthentication.
But I get the following error:
Jun 15, 2022 1:14:34 PM io.vertx.ext.web.RoutingContext
SEVERE: Unhandled exception in router
io.vertx.ext.web.handler.HttpException: Unauthorized
Caused by: io.vertx.core.impl.NoStackTraceThrowable: Invalid username/password
I am providing the right credentials.
The code snippet is:
SqlAuthenticationOptions sauthopts = new SqlAuthenticationOptions();
sauthopts.setAuthenticationQuery(AUTHENTICATE_QUERY);
SqlAuthentication authenticationProvider = SqlAuthentication.create(sqlClient, sauthopts);
router.route("/secure/*").handler(RedirectAuthHandler.create(authenticationProvider, "/login.html"));
FormLoginHandler formLoginHandler = FormLoginHandler.create(authenticationProvider);
router.route("/loginhandler").handler(formLoginHandler);
Please let me know if I am missing something here; or point me to a sample example.
Thanks in Advance.
Your setup doesn't show anything abnormal at first sight. For security reasons, we cannot "just" log the authentication data, as it would be a critical OWASP bug and security vulnerability.
My best guess is that probably is something not totally correct with the query, so this means you have now 2 options:
debug the application and see the query that is being sent + the arguments
prepare a small complete example that shows the bug and open an issue in vert.x so we can debug it further.
If you're upgrading from an older version, be aware that in vert.x 4.2.0 some changes were made to the base64 encoding to keep it consistent across modules. This could be a reason why authentication could fail as the encoded hashes may be slightly different. If you're just doing 4.3.0 from the start, then this would not be a problem.
I have been working with HFC SDK for Node.js and it used to work, but since last night I am having some problems.
When running helloblockchain.js only few times works, most time I get this error when it tries to enroll a new user:
E0113 11:56:05.983919636 5288 handshake.c:128] Security handshake failed: {"created":"#1484304965.983872199","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484304965.983866102","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
Error: Failed to register and enroll JohnDoe: Error
Other times, the enroll works and the failure appears deploying the chaincode:
Enrolled and registered JohnDoe successfully
Deploying chaincode ...
E0113 12:14:27.341527043 5455 handshake.c:128] Security handshake failed: {"created":"#1484306067.341430168","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306067.341421859","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
Failed to deploy chaincode: request={"fcn":"init","args":["a","100","b","200"],"chaincodePath":"chaincode","certificatePath":"/certs/peer/cert.pem"}, error={"error":{"code":14,"metadata":{"_internal_repr":{}}},"msg":"Error"}
Or:
Enrolled and registered JohnDoe successfully
Deploying chaincode ...
E0113 12:15:27.448867739 5483 handshake.c:128] Security handshake failed: {"created":"#1484306127.448692244","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306127.448668047","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
events.js:160
throw er; // Unhandled 'error' event
^
Error
at ClientDuplexStream._emitStatusIfDone (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:189:19)
at ClientDuplexStream._readsDone (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:158:8)
at readCallback (/usr/lib/node_modules/hfc/node_modules/grpc/src/node/src/client.js:217:12)
E0113 12:15:27.563487641 5483 handshake.c:128] Security handshake failed: {"created":"#1484306127.563437122","description":"Handshake read failed","file":"../src/core/lib/security/transport/handshake.c","file_line":237,"referenced_errors":[{"created":"#1484306127.563429661","description":"FD shutdown","file":"../src/core/lib/iomgr/ev_epoll_linux.c","file_line":948}]}
This code worked yesterday, so I don't know what could be happening.
Does anybody know how can I fix it?
Thanks,
Javier.
ibm-bluemix
blockchain
These types of intermittent issues are usually related to GRPC. An initial suggestion is to ensure that you are using at least GRPC version 1.0.0.
If you are using a Mac, then the maximum number of open file descriptors should be checked (using ulimit -n). Sometimes this is initially set to a low value such as 256, so increasing the value could help.
There are a couple of GRPC issues with similar symptoms.
https://github.com/grpc/grpc/issues/8732
https://github.com/grpc/grpc/issues/8839
https://github.com/grpc/grpc/issues/8382
There is a grpc.initial_reconnect_backoff_ms property that is mentioned in some of these issues. Increasing the value past the 1000 ms level might help reduce the frequency of issues. Below are instructions for how the helloblockchain.js file can be modified to set this property to a higher value.
Open the helloblockchain.js file in the Hyperledger Fabric Client example and find the enrollAndRegisterUsers function.
Add “grpc.initial_reconnect_backoff_ms": 5000 to the setMemberServicesUrl call.
chain.setMemberServicesUrl(ca_url, {
pem: cert, "grpc.initial_reconnect_backoff_ms": 5000
});
Add “grpc.initial_reconnect_backoff_ms": 5000 to the addPeer call.
chain.addPeer("grpcs://" + peers[i].discovery_host + ":" + peers[i].discovery_port,
{pem: cert, "grpc.initial_reconnect_backoff_ms": 5000
});
Note that setting the grpc.initial_reconnect_backoff_ms property may reduce the frequency of issues, but it will not necessarily eliminate all issues.
The connection to the eventhub that is made in the helloblockchain.js file can also be a factor. There is an earlier version of the Hyperledger Fabric Client that does not utilize the eventhub. This earlier version could be tried to determine if this makes a difference. After running git clone https://github.com/IBM-Blockchain/SDK-Demo.git, run git checkout b7d5195 to use this prior level. Before running node helloblockchain.js from a Node.js command window, the git status command can be used to check the code level that is being used.
While trying to start my Play app locally I am getting a
java.lang.IllegalArgumentException: port out of range:-1
exception followed by a
(*:playRun) java.lang.reflect.InvocationTargetException
message. I can see in the trace the invalid port arg being sent (..../Scala/launcher/sbt-launch.jar" xsbt.boot.Boot "~run -1") but cannot find where to update this argument. There has to be somewhere to override default values. And... No matter what is in the application.conf (http.port) or what I pass on the command line -Dhttp.port I still get the same error. Any info would be enormously appreciated.
I had the same exception and I was in touch with the IntelliJ support team, and got the message it was a bug, because of the https protocol in the open browser field. The url parser cannot handle https and thus not extract the port number.
Bug report here: https://youtrack.jetbrains.com/issue/SCL-9971
The precedence section in chapter 9.3.1 tells me that I should apply the special cases first and then the general ones.
[General]
*.host[0].waitTime = 5ms # specifics come first
*.host[3].waitTime = 6ms
*.host[*].waitTime = 10ms # catch-all comes last
I have following lines in the omnetpp.ini file:
**.server[*].tcpApp[0].port = 1000
**.pods[0..1].**.server[*].tcpApp[0].port = 80
**.pods[2..3].**.server[*].tcpApp[0].port = 21
This code works, but every server has 1000 when checking the parameter and not the special cases 80 and 21. So I want it to look like that:
**.pods[0..1].**.server[*].tcpApp[0].port = 80
**.pods[2..3].**.server[*].tcpApp[0].port = 21
**.server[*].tcpApp[0].port = 1000
Yet, this creates an error, which consists of a null pointer exception in the TCP module of the StandardHost module my server is build on.
In the ned file, the parameter is declared like this:
int port = default(1000); // port number to listen on
Leaving that catch-all line out causes the error too. Only taking the last line above the other two makes it possible to let the simulation run through.
An example for the port parameter can be found in TCPServerHostApp.ned from INET. I want to assign different ports for different services which should run on the servers.
What is your advice for me, to apply those parameters correctly? Is there an error in the way I set the parameters, or do I need to set the ports somewhere during the initialization process myself (which would make no sense to me)?
Edit:
The karma system does not allow me to answer the question yet, so here is the cause of my problem:
Well, the problem was at another place. When connecting a new socket with connect(ipaddr, port), I got the wrong port from the job request message.
At the traffic generation module, I read the wrong port for connection to the server, which caused an error, as the port being used was always the default = 1000 instead of 80 or 21.
The servers expected 80 or 21, causing a crash when the socket tried to connect with port 1000.
Just want to add this here as well, so everybody sees I found the error.
Well, the problem was at another place. When connecting a new socket with connect(ipaddr, port), I got the wrong port from a job request message.
At the traffic generation module, I read the wrong port for connection to the server, which caused an error, as the port being used was always the default (= 1000) instead of 80 or 21.
The servers expected 80 or 21, causing a crash, when the socket tried to connect with 1000.
We get this error:
[#|2009-08-12T11:38:31.803-0700|SEVERE|sun-appserver9.1|javax.enterprise.system.container.web|_ThreadID=16;_ThreadName=httpSSLWorkerThread-38080-3;_RequestID=8b3571bb-3c36-43f1-9e38-6947ca376436;|WebModule[]Exception while dispatching incoming RPC call
javax.servlet.ServletException: Client did not send 142 bytes as expected
at com.google.gwt.user.server.rpc.RPCServletUtils.readContentAsUtf8(RPCServletUtils.java:148)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.readContent(RemoteServiceServlet.java:335)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:77)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:738)
very rarely and it is not reproducible. I have seen posts earlier but none of them justify the reason for it.
Appreciate if I can get some information:
Is it with some version of GWT or related software, will upgrading help?
How often you get this error?
Any more workaround?
Environment:
Client: ie 6
Server: GlassFish 2, GWT 1.5.3, Java 5
It seems it's not related to GWT: http://code.google.com/p/google-web-toolkit/issues/detail?id=3155. There's also someone there in the comments offering (private) help with this issue.