I'm developping a HTTP serveur as a Chrome App but I don't know how to interpret error codes caught in:
chrome.sockets.tcp.onReceiveError.addListener( (info) =>
console.error( "Error on Receive: socket=%s, resultCode=%s", info.socketId, info.resultCode )
)
Sometimes I get the following error with info.resultCode = -100 (when the connection is timed out).
I've found some Unix/Sockets codes but they don't seem to match, and I found nothing on Google's Chrome App Dev website.
This one and this one could match but I'm not sure.
For example, with that commented error list, I can guess the error 10064 is corresponding to my -100 resultCode.
Can someone direct me to the right documentation?
It looks like there is a list of them defined in net_error_list.h
Related
I'm trying to send a SMS using AT commands and after typing the cellphone number it show the CMS: ERROR 302.
What I'm doing:
AT
OK
AT+CMGF=1
OK
AT+CMGS="<3 digit local area code><7 digit cellphone number>"<Enter>
+CMS: ERROR 302
I've found this post: AT+CMGS returns ERROR but couldn't find a solution. Am I typing something wrong? I've changed SMS-encoding to GMS as the post describes.
Try this:
AT
AT+CMGF=1
AT+CSCA="sms tel. service",145
AT+CMGS="tel. number"
text message here
^Z
Some modems need set CSCA (SMS Service Center Address) always.
And look here for a examples and descriptions.
I found out that sending exactly the same AT commands by hand worked, but sending them from a controller did not (with waiting for the correct answers). Getting the 302 error. But then doing all commands a lot slower with waits of 2 secs in between it suddenly started to work. Apparantly the SIM900 needs more time after it answers, or something.
I'm writing a gstreamer plugin that uses a uridecodebin. I'd like to be able to intercept the error that occurs when the uridecodebin is unable to open a file (either because of a malformed URI, an unknown file format, or a non-existent file) before it's reported to the application using the pipeline. When I try to add a watch to the uridecodebin's bus myself, it fails (gst_bus_create_watch: assertion bus->priv->poll != NULL) and I get a segfault.
How can I intercept the error before it's reported to the application so that I can gracefully fail internally? It isn't a critical error for the plugin as a whole if the file isn't loaded, and I'd like to be able to do some cleanup work when that happens.
You need to read this page:
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/manual/html/chapter-bus.html
Using wxpython, I do the following:
# Create the bus to listen for messages
bus = Gplayer.get_bus()
bus.add_signal_watch()
bus.enable_sync_message_emission()
bus.connect('message', self.OnBusMessage)
# Listen for gstreamer bus messages
def OnBusMessage(self, bus, message):
t = message.type
if t == Gst.MessageType.ERROR:
Gplayer.set_state(Gst.State.NULL)
self.OnStop(None)
wx.MessageBox('Gstreamer Error - Unsupported file type, Corrupt file,\
Unable to access or Invalid Output Device', 'Error', wx.OK | wx.ICON_INFORMATION)
Or in your case, don't report anything.
EDIT:
You can parse the message to see part 1 which will be the error and part 2 which will be a more verbose explanation.
# Listen for gstreamer bus messages
def OnBusMessage(self, bus, message):
t = message.type
if t == Gst.MessageType.ERROR:
print "Part 1",Gst.Message.parse_error (message)[0]
print "part 2",Gst.Message.parse_error (message)[1]
This is what I get from the above for a missing file:
Part 1 Not Found
part 2 gstsouphttpsrc.c(1192): gst_soup_http_src_parse_status (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:
Not Found (404), URL: http://localhost/vvvv.mp3
Note: This assumes that you will add code to the existing watch
Edit 2:
With regard to your second comment, have you investigated gst_bus_new().
It appears at first glance, that it may help you.
Given the following code.
PGconn* const conn=PQconnectdbParams(keywords, values, false);
if(! conn || PQstatus(conn)!=CONNECTION_OK){ /* error code? */ }
In case of a failed connection is there a way to get the error code to be able to
distinguish between a bad password and the server being down.
(I know I can get the error message, but I want to be able to react to the cause of the
error according to its cause).
Thanks.
So after doing some more research and asking postgres developers it seems that it is not currently possible to get the error code from PQconnectdbParams().
This seems to be a shortcoming of libpq itself which doesn't try to assign SQLState error codes for errors it detects internally (like an unknown hostname).
This seems to be on the postgres dev todo list but it's not a priority.
TL;DR: If you are going to use libpq, learn to live with the text error message (whatever language it is localized in).
Try...
cout << PQerrorMessage(conn) << endl;
Try to call getpeername() on PQsocket(conn).
In case of server being down getpeername return error, but in case of wrong password tcp connection was successfully established, and getpeername return server address.
I'm attempting to synchronously read from a CFReadStream objected created by CFStreamCreatePairWithSocketToHost. The stream opened fine but when I attempt to invoke CFReadStreamRead on it in a loop, CFReadStreamRead() returns -1 and the resulting error is:
Error Domain=kCFErrorDomainCFNetwork Code=2 "The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.)" UserInfo=0x14a920 {kCFGetAddrInfoFailureKey=8}
I'm also receiving this same exact error when using this ReadStream asynchronously- the first callback I receive is this error.
The short story: Probably a DNS resolution failure.
The docs say "The streams do not open a connection to the specified host until one of the streams is opened", and for kCFGetAddrInfoFailureKey,
Querying this key returns the last error code returned by getaddrinfo(3) in response to a DNS lookup. To interpret the results, look up the error code in /usr/include/netdb.h.
netdb.h says
#define EAI_NONAME 8 /* hostname nor servname provided, or not known */
I was able to fix this by putting in Google's DNS servers (8.8.8.8,8.8.4.4) in the wifi connection in the Settings app. The issue was that our devices were on a network that first required you to agree to some terms of service on a proxy login web page, much like hotels and coffee shops do. Safari worked fine after agreeing, but the app didn't, even after agreeing in Safari. Switching to alternate DNS worked (so did putting in the IP address instead of the DNS entry of our server, but I didn't want to hard-code an IP address).
I was able to eliminate this error by removing https:// from the host String.
NSStream.getStreamsToHostWithName("https://example.com" ...
You may need to set the appropriate security level:
inputStream!.setProperty(NSStreamSocketSecurityLevelTLSv1, forKey: NSStreamSocketSecurityLevelKey)
outputStream!.setProperty(NSStreamSocketSecurityLevelTLSv1, forKey: NSStreamSocketSecurityLevelKey)
I'm using a little code to grab an image given its URL, and it's working for me for all URLs I tried except one:
http://title.mximg.com/img/logo/bizrealty.com.gif
For this URL, I'm getting "The underlying connection was closed: An unexpected error occurred on a receive."
However, if you open that URL with a browser, it loads perfectly.
Apparently that error message means:
"The underlying connection was closed:
An unexpected error occurred on a
receive."
--Seen when the client had sent the request in its entirety and got a TCP
ACK-FIN or RST from server to close
the connection, without a response
from server.
But I have no idea what that means :-(
The code is simply:
Dim req As System.Net.HttpWebRequest = DirectCast(WebRequest.Create(ImageURL), HttpWebRequest)
req.Method = "GET"
Dim resp As Net.HttpWebResponse = DirectCast(req.GetResponse(), Net.HttpWebResponse)
UPDATE: Setting KeepAlive to false doesn't help it. Also, it's not a timeout issue, I'm getting the error quite fast.
Any idea what could be going on?
Thanks!
I'd try updating your request settings like UserAgent or Accept. It's possible they're serving images dynamically and reject requests that don't look like normal traffic.