I'm using OpenIMPI library for managing Shelf Manager (Pigeon Point ShMM-500)
After creatinf domain and verifying all connection arguments setup_done_handler returns an error
33554450
I'm using OpenIPMI macroses for decoding error. This error is RMCP+ error, and real error code is
18
That error occures after sending RMCP+ Open Session Request and getting RMCP+ Open Session Response
This error occures not permanent and the multiple rebooting of Shelf Manager can solve this problem, but sometimes I need 10 or 15 reboots before I will be succesfully connected to ShMM.
Does somebody know, what that error means?
Thanks in advance.
The connection can be established only by proper using of connection method.
Early, I used a method
ipmi_args_setup_con();
with specific setup args.
Now I'm using the concreate method
ipmi_ip_setup_con();
And it works all time.
Hope, that it will be helpfully for someone.
Related
I've set up the sample program from here: https://github.com/GoogleCloudPlatform/cpp-docs-samples/tree/master/iot/mqtt-ciotc
When I try to run the example, the only error message that I get is:
'Failed to connect, return code 1'
I then moved on and tried the NodeJs version https://github.com/GoogleCloudPlatform/nodejs-docs-samples/tree/master/iot/mqtt_example
Using the same roots.pem, private and public keys, the NodeJs example works perfectly. I can view the incoming messages on Google Console.
Is there any tools available to help me debug what the issue is with the C example? Or any suggestions on what the problem could be?
Thanks,
A
There is a wide range of reasons to why this could be happening, including unsupported versions. The Documentation for Cloud IoT provides some steps that you should verify first, but since you connected from the NodeJS code, we can discard some suggestions. What you could do to check errors is to use gcloud:
gcloud iot devices describe DEVICE_ID --project=PROJECT_ID --region=REGION --registry=REGISTRY_ID
The devices describe command may show additional error messages that can be used to help debug, including to verify that your device's credentials are not expired. Although some errors may not show up, my impression is that bad username or password errors would appear.
I am trying to connect to remote socket server and i get an error: "Socket connection failed for unknown reasons"
spent a lot of time, and I could not find a solution (
Please, helpe me/ thanks
My client dep:
socketcluster-client 9.0.2,
angularjs 1.5.7
You can try another system which has similar system, check ClusterWS
https://github.com/ClusterWS/ClusterWS
I had this exact same error and I was trying to connect to a third party external API that was providing data through websockets. If this is what you are trying to do, socketcluster may not work because it only enables connection with a socketcluster client and a socketcluster server regardless of whether they are in the same domain or different domain. Hope that helps
I just started with the beaglebone and I have no prior knowledge of
programming. I tried to follow this link" http://beagleboard.org/Getting%20Started". In the initial steps after installing the drivers, i fail in the STEP 3 : when i try to connect to 192.168.7.2( i typed the same in the url) , I get the following error The following error was encountered while trying to retrieve the URL: "http ://192.168.7.2/ " Access Denied. Access control configuration prevents your request from being allowed at this time. Please contact your service provider if you feel this is incorrect. Your cache administrator is .......
I read that this step is important to get access to the browser on the board ? if so what should i do? kindly help!!
regards
Try cleaning your browser cache. By the message you've received, it can be a problem with your firewall also, you should disable it and try to reconnect to the bbb.
Regards,
My Google App Engine app, which uses the Channel API works well some of the time. Intermittently, though, the js code connecting to the channel generates an error. In socket.onError, the error code is set to 400 and the description is set to an empty string. I have checked that the token being used to connect is valid. I also tried recreating the channel in socket.onError, by first calling socket.close() but that does not seem to work. Often there is a series of failures before a success. The client js is running on Safari on iOS. Any ideas on how to fix or work around the problem will be welcome. Right now, my best workaround is to keep trying till I succeed, increasing the interval between attempts on each failure. The server side presence API does not help, since the 'connected' hook is not called reliably.
It is known issue http://code.google.com/p/googleappengine/issues/detail?id=4940 and it was accepted. As you see the status of issue is not fixed. Feel free to star it.
I know double posting is bad (issue starred & comment posted)... but I suspect this thread might get more attention than the issue comments ^^
As far as we are concerned, it's at the very least a documentation issue:
https://developers.google.com/appengine/docs/java/channel/javascript still
states " An onerror call is always followed by an onclose call and the channel object will have to be recreated after this event"
It is only true for, as far as we have guessed, error codes 400 and 401 (which are strings, not numbers, btw, so beware of === in the js code).
It is untrue for other error codes (we have logged at least the -1 code).
There should be a documentation covering all error codes and their (expected) management.
Atm, we have a "channel manager" that reuses the same channel token when code is not 400 or 401, and that makes sure onclose is called once and once only per Socket.
Before that, we were trying to close properly, and reopen (new underlying Socket) with a shiny brand new token: usually we got an error 400 followed by an error -1.
FUI we first detected this behavior on iOS, quite recently (regression ftw? Before that iOS was dandy). Reopening the socket after a code -1 is not a panacea: sometimes it will succeed (onopen properly called), and then fail silently (no message received, no onerror called).
Generally, we also noticed more consistent behavior on desktop browsers than mobile ones, across all user agents and platforms (more on that: yay! Other issues incoming! Especially android...)
OK, this post might have been useful after all. Thx!
[EDIT: corrected a mistake... we don't reuse the channel object nor the socket object, only the token]
I contacted Google support about this issue.
When a error 400 happens it's because a timeout (one minute it seems) happened. This timeout generates a disconnection (url disconnected is called and you should remove the client id of the database).
Then, a new channel must be created with a new client id.
But it is not enough. We have to use this jquery command line : $('#wcs-iframe').remove();
Just inside the js onerror function and before to try to recreate the channel.
One of the users of a silverlight app I wrote gets this error message:
[Arg_VersionString] Arguments:
Debugging resource strings are
unavailable. Often the key and
arguments provide sufficient
information to diagnose the problem.
See
http://go.microsoft.com/fwlink/?linkid=106663&Version=4.0.50524.0&File=mscorlib.dll&Key=Arg_VersionString
I checked the log of the asp.net application that is hosting the silverlight plugin and I see no exceptions. The services seem to be working properly, I even witness the trace of this user running the app, and I can confirm that the service successfully returned data.
Something must be happening on the client side, but I don't know where to start. The software is in production already, there are no debugging tools on that server other than DbgView and the problem only seems to be occuring for this particular user.
What would you do?
In order to reduce the size of the Silverlight plugin, The strings of error messages were removed. So if any unhandled exception gets thrown this is the message you will recieve.
In order to get the full version of the exception the user has to have the Silverlight Developer Runtime and not the client runtime installed.
If you have a record of the data returned to the client, you might try using Fiddler to inject that data into the client running on your machine and see if it fails. If it does you should get back the full error message.