Attempt to send a message through a socket failed with WinSock error 10038. After around 40 seconds, messages are received successfully from the same socket and subsequently the send() is also succeeding in the same socket. This behaviour has been witnessed in Windows Server 2003. Is this any known behaviour with WinSock and Windows Server 2003?
Winsock error 10038 means "An operation was attempted on something that is not a socket".
Little trick to find info about error codes (usefull for all sorts of windows error codes):
Open a command prompt
Type "net helpmsg 10038"
What language is your application written in? If it's C/C++, could it be that you are using an invalid socket handle?
Thanks so much to a_mole for the idea of checking for layered winsock providers. We are having problems with some of our PC's and TimesTen DB. When we try to setup and ODBC Client DSN, we get a 10038 error. On examining the netsh output from the affected PC's, we found that they have Embassy Trust Suite by Wave Systems installed. Evidently Dell pre-installed this on some of their PC's. Anyway, on uninstalling this software, the problem has been solved.
Thanks again
Lou
Not a platform issue, I can guarantee that. Most likely, whatever variable you are using to access the socket handle is not thread-safe and is being used in the send() call before the actual socket is created.
Another possible cause is the presence of layered winsock providers. "netsh winsock show" at a cmd prompt will show you the installed providers and you can try removing any non-microsoft ones.
Related
I tried to install a hardware I've installed in my previous computer under Windows 7, basically an external network card with antenna, but when I try to use it, after installed it I get this bluescreen error:
BUGCODE_NDIS_DRIVER
I don't know if it's possible to fix it, any useful information?
PS: If this isn't the best Stack forum, please guide me to the right one.
There is some technical information on Windows Dev Center - Hardware on this bugcheck. Driver developers can find the cause from the bugcheck code and parameters.
I can duplicate the BUGCODE_NDIS_DRIVER blue screen on my Windows 8.1 developer box fairly easily by opening two different VPN tunnels. Luckily, I don't need both running at the same time, so my solution is "don't do that".
For example, I open SonicWALL Global VPN Client to connect to one network. Then, I open the Cisco VPN client to connect to another. The crash happens almost immediately.
If you have two active network card, deactivate one, that is all.
I using socket in java. the data is coming from server which is on linux machine and i want to get that data to window using socket. on same linux to linux socket connect but linux to window connection is getting. so please tell me the solution.... is there any other library required or something else?
Also how to solve pragma pack issue in java?
This question is a bit tricky and I don't really think I'll find an answer but I'll try anyway.
I'm writing a C++ program using gloox for XMPP transfers. My problem , which is happening only on my computer, (Linux Mint 13 MATE 32bits) is that the "onConnect()" handler is never called. This was not a problem when we were using the jabber.org server (actually, I didn't even know it was not called...) but problems started occuring when we installed a LAN ejabberd server.
Using jabber.org server, even though "onConnect" was not called the application was able to send/receive messages fine. But not on ejabberd. At first I thought it was a problem with the certificate or something but then we tried on our other Linux boxes (Ubuntu 12.04 x64, Arch x64 and Debian 6.0 32(the server is running on this machine)) and it works fine on any of those computers. Plus, the sister application using Python-Twisted can connect fine on the problematic computer.
The validation function, onTLSConnect() is called everytime and it returns true. On the problematic computer, when using our ejabberd server, the connection isn't established after that and the socket closes it self after about 25 seconds ( and onDisconnect() is called...)
So, my question: Could there be an internet setting (like a firewall?) that is preventing Gloox to terminate the connection. OR has anyone experienced a similar issue?
Thanks!
EDIT: I made a VM of Mint 13 MATE 32bits on my laptop and the same problem arises. I can now conclude it's bug somewhere in mint.
EDIT2: Works fine on Mint 64 bits....I opened a ticket on Mint's bug page
i meet this problem last week, it seems a bug of gloox.
it happened on 32 bit linux.
see this https://bugs.launchpad.net/linuxmint/+bug/1071416
in fact.you are "online" on the server, but your "presence" state is unknown. you can simply send a "Chat" state to the server to continute your work.
like this
#ifdef GLOOX_ON_CONNECT_BUG_PATCH
Poco::Thread::sleep(3000);//休息3秒，然后连接成功,哎，该死的bug
this->is_connected = true;
client->setPresence(Presence::Chat, 0);
#endif
I have a new tomcat application server running on tomcat 6, java 6 (openjdk), centos 6.2. The server is a virtual machine running under qemu-kvm on a centos 6.2 host. Both host and guest are 64-bit.
I have a case where a connection is opened, (from a connection pool) then a "long computation" occurs for about 4 hours, during which the connection is not used. Finally, a "commit" is issued, and the server gives a "connection reset" exception, specifically:
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:185)
at oracle.net.ns.Packet.receive(Packet.java:282)
at oracle.net.ns.DataPacket.receive(DataPacket.java:103)
at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:230)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:175)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:100)
at oracle.net.ns.NetInputStream.read(NetInputStream.java:85)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:122)
at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:78)
at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1179)
at oracle.jdbc.driver.T4CMAREngine.unmarshalSB1(T4CMAREngine.java:1155)
at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:279)
at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:186)
at oracle.jdbc.driver.T4C7Ocommoncall.doOCOMMIT(T4C7Ocommoncall.java:75)
at oracle.jdbc.driver.T4CConnection.doCommit(T4CConnection.java:558)
The database server and the client are on the same subnet, except the server is a real physical host, and obviously the app-server is a guest running inside a physical machine on the same subnet.
The host used "bridged" networking.
This may not be a software problem at all but rather a linux os configuration (iptables?) issue, but I really don't know.
I have run into this a couple of times. Almost always caused by a network timeout (load balancer or firewall). But you have clearly mentioned that your servers are on the same subnet, so not really sure what is going on. Since you suspect iptables, can you turn it off, run the test and see if it works (too easy huh :)
Regardless, assuming you are connecting to an Oracle db, the following tweak helps
http://raibledesigns.com/rd/entry/tomcat_oracle_connectivity_problems
If you use a different db (say mysql) the setting might be different but the logic is the same. Setup a keepalive value to prevent the connection from being idle for too long. This way the firewal/load balancer/iptables software will not terminate it.
As you can see in this post in Oracle Forums, this can have more than one problem / solution.
Check if your JDBC driver version is correct
Check your ORACLE_HOME environment variable
try add the argument -Djava.security.egd=file:///dev/urandom
Your logic use a singleton to get the connection? In the post this are mentioned too
Hope this helps you.
#user is referring to a good workaround, by configuring "SQLNET.EXPIRE_TIME=10" in sqlnet.ora.
However, this workaround is only applicable if your application is using thick OCI (jdbc:oci), not thin (jdbc:thin) driver.
Linux has software firewall, i.e. iptables, which can drop idle network connection, so even you are in the same subnet, you have iptables software firewall. This is activated by default in all modern Linux, and up to Linux administrator to disable it.
By default, Linux iptables does not drop idle TCP/IP connections (jdbc belongs to TCP/IP protocol), so the Linux administrator must configured iptables to do so. Following is the detail explanation for any reader who are interested to know more:
http://www.digitage.co.uk/digitage/software/linux-security/cutter
Business users, security team, or architect often suggest network/OS admin to abort idle connection using firewall, as well as router. This is always a "recommendation" in the anti-hacking community, but it is not properly discussed, and causing application instability. Eventually, you should discuss with the team to find a balance
We are developing a RPC system with client in ubuntu system and server in Solaris system.
Currently we are struck at this error: "RPC: Unknown Protocol"
can some one help us with this?
Change "visible" to "tcp" in clnt_create() call.
Run your program with strace to see if you are missing any critical files. In my case, it made me realize that I was missing libnss_files and libnss_dns libraries, and the problem went away once I added them.