We have a .NET 2.0 desktop application which sends and receives network
packets over UDP.
Several users have reported an occasional socket error 10052 which happens
when the code calls socket.BeginReceiveFrom on a the UDP socket.
What does this mean?
The official MS documentation for socket error 10052 says - quote:
"WSAENETRESET (10052) Network dropped connection on reset . The connection
has been broken due to keep-alive activity detecting a failure while the
operation was in progress. It can also be returned by setsockopt if an
attempt is made to set SO_KEEPALIVE on a connection that has already
failed."
This just doesn't make much sense for a UDP socket since UDP is a
connectionless protocol.
I know that another close error code 10054 in connection with UDP sockets
means that an ICMP message "Port Unreachable" was received, and I am
wondering if 10052 might map to another ICMP message?
I have googled this for months, read network books, etc. but can't find
anything.
Please help - what does socket error 10052 on a UDP socket mean?
Thanks in advance
See http://msdn.microsoft.com/en-us/library/ms740120%28v=vs.85%29.aspx, which describes the recvfrom function. It says of WSAENETRESET (which is winsock error 10052):
For a datagram socket, this error indicates that the time to live has expired.
Be sure that TTL value is high enough, when sending UDP datagrams.
If you are using UdpClient class.
Then use the following before sending the datagram:
myUdpClient.Ttl = 255;
Note: 255 is the maximum value for TTL.
There is some network problem if that value is not enough.
WSAE NET RESET suggests that it happens due to a reset of the network interface itself. Your program is sitting there bound to a UDP port, so in a sense it is connected, but to the network interface rather than to a remote peer.
Try starting your program, getting it to the point where this BeginReceiveFrom call is about to be made, then disable your NIC in the Device Manager and re-enable it. Or, with Wi-Fi, drop and reestablish the connection to the WAP. It might even happen by just unplugging the Ethernet cable to your machine, as recent versions of Windows default to killing all sockets connected through that NIC when this happens.
It would explain the rare problem reports from the field. This probably only happens when there is some local networking fault at the hardware level.
Related
I have a "Transmit Thread" that manages a socket (#include WinSock2.h) for transmitting all the UDP data my application requires. The application is a c++ Windows app running on Windows 10. I am sending up to 5 or so packets per second to a subnet broadcast address, each packet less than 200 bytes.
The problem is, when I disconnect the Ethernet, there seems to be some un-sent data in the write buffer of the socket than I haven't been able to flush out.
When my application detects the ethernet loss, I close (closesocket) and re-open the socket. Immediately upon re-connection, the socket sends several old messages that were "sent" around when the Ethernet was disconnected.
I think this problem is outside my application. I have disconnected ethernet while the application is running and then closed the application. Immediately upon re-connection, I see that several of the messages get transmitted, despite the application no longer running.
Things I have tried (without luck):
I have tried calling shutdown( m_sock, SD_BOTH ); immediately before closesocket( m_sock );
I tried writing a buffer full of zeroes to the socket immediately before closing
I can't set the SO_DONTLINGER option because my socket is SOCK_DGRAM
When I try WSAIoctl( m_sock, SIO_FLUSH, NULL, 0, NULL, 0, &dwBytesRead, &wsol, NULL ) it returns error 997 (WSA_IO_PENDING)
I don't know how to stop the IO from pending.
Neither WSASendDisconnect( m_sock, NULL ) nor CancelIo( (HANDLE)m_sock ) work, and neither signals error
The problem was not with my software, or with my local NIC, as far as I can tell. My NIC was connected to an Ethernet hub before connecting to other devices on my LAN via a Switch.
The presence of the hub caused the described behavior. Without the hub, I don't experience any "flush" or sending expired packets.
I am using the wifi chip ESP8266 with SMING framework.
I am able to establish a TCP connection as a client to a remote server. The code for initiating client connection to server is simple.
tcpClient.connect(SERVER_HOST, SERVER_PORT);
Unfortunately, the connection will close after idling for some time. I would like to keep this connection open forever permanently. How can this be done?
You will actually need to monitor the connection state and reconnect it if it failed. Your protocol on top of it will need to keep track of what got actually received by the other side and retransmit it.
In any wireless network your link may go down for one reason or another and if you need to maintain a long term connection you will need to have it in a layer above TCP itself.
TCP will continue to be connected as long as both sides allow for it (none of them disconnected) and there are no errors on the link, in this case sending keepalives may actually cause disconnects since the keepalive may fail at one time but the link could recover and if you didn't have the keepalive the link would have stayed up.
I establish a TCP connection between my server and client which runs on the same host. We gather and read from the server or say source in our case continuously.
We read data on say 3 different ports.
Once the source stops publishing data or gets restarted , the server/source is not able to publish data again on the same port saying port is already bind. The reason given is that client still has established connection on those ports.
I wanted to know what could be the probable reasons of this ? Can there be issue since client is already listening on these ports and trying to reconnect again and again because we try this reconnection mechanism. I am more looking for reason on source side as the same code in client sides when source and client are on different host and not the same host works perfectly fine for us.
Edit:-
I found this while going through various article .
On the question of using SO_LINGER to send a RST on close to avoid the TIME_WAIT state: I've been having some problems with router access servers (names withheld to protect the guilty) that have problems dealing with back-to-back connections on a modem dedicated to a specific channel. What they do is let go of the connection, accept another call, attempt to connect to a well-known socket on a host, and the host refuses the connection because there is a connection in TIME_WAIT state involving the well-known socket. (Stevens' book TCP Illustrated, Vol 1 discusses this problem in more detail.) In order to avoid the connection-refused problem, I've had to install an option to do reset-on-close in the server when the server initiates the disconnection.
Link to source:- http://developerweb.net/viewtopic.php?id=2941
I guess i am facing the same problem: 'attempt to connect to a well-known socket on a host, and the host refuses the connection'. Probable fix mention is 'option to do reset-on-close in the server when the server initiates the disconnection'. Now how do I do that ?
Set the SO_REUSEADDR option on the server socket before you bind it and call listen().
EDIT The suggestion to fiddle around with SO_LINGER option is worthless and dangerous to your data in flight. Just use SO_RESUSEADDR.
You need to close the socket bound to that port before you restart/shutdown the server!
http://www.gnu.org/software/libc/manual/html_node/Closing-a-Socket.html
Also, there's a timeout time, which I think is 4 minutes, so if you created a TCP socket and close it, you may still have to wait 4 minutes until it closes.
You can use netstat to see all the bound ports on your system. If you shut down your server, or close your server after forking on connect, you may have zombie processes which are bound to certain ports that do not close and remain active, and thus, you can't rebind to the same port. Show some code.
What is the meaning of the "connection reset by peer" error on a TCP connection? Is it a fatal error or just a notification or related to the network failure?
It's fatal. The remote server has sent you a RST packet, which indicates an immediate dropping of the connection, rather than the usual handshake. This bypasses the normal half-closed state transition. I like this description:
"Connection reset by peer" is the TCP/IP equivalent of slamming the phone back on the hook. It's more polite than merely not replying, leaving one hanging. But it's not the FIN-ACK expected of the truly polite TCP/IP converseur.
This means that a TCP RST was received and the connection is now closed. This occurs when a packet is sent from your end of the connection but the other end does not recognize the connection; it will send back a packet with the RST bit set in order to forcibly close the connection.
This can happen if the other side crashes and then comes back up or if it calls close() on the socket while there is data from you in transit, and is an indication to you that some of the data that you previously sent may not have been received.
It is up to you whether that is an error; if the information you were sending was only for the benefit of the remote client then it may not matter that any final data may have been lost. However you should close the socket and free up any other resources associated with the connection.
one of the reasons for seeing this error and having trouble connecting to the server is that you enabled the firewall in the UNIX machine and forgot to add a rule to accept ssh connection. search in your WPS provider and you will find a way to connect to you machine and add this rules:
ufw allow ssh && ufw allow 22
I have an FPGA device with which my code needs to talk. The protocol is as follows:
I send a single non-zero byte (UDP) to turn on a feature. The FPGA board then begins spewing data on the port from which I sent.
Do you see my dilemma? I know which port I sent the message to, but I do not know from which port I sent (is this port not typically chosen automatically by the OS?).
My best guess for what I'm supposed to do is create a socket with the destination IP and port number and then reuse the socket for receiving. If I do so, will it already be set up to listen on the port from which I sent the original message?
Also, for your information, variations of this code will be written in Python and C#. I can look up specific API's as both follow the BSD socket model.
This is exactly what connect(2) and getsockname(2) are for. As a bonus for connecting the UDP socket you will not have to specify the destination address/port on each send, you will be able to discover unavailable destination port (the ICMP reply from the target will manifest as error on the next send instead of being dropped), and your OS will not have to implicitly connect and disconnect the UDP socket on each send saving some cycles.
You can bind a socket to a specific port, check man bind
you can bind the socket to get the desired port.
The only problem with doing that is that you won't be able to run more then one instance of your program at a time on a computer.
You're using UDP to send/receive data. Simply create a new UDP socket and bind to your desired interface / port. Then instruct your FPGA program to send UDP packets back to the port you bound to. UDP does not require you to listen/set up connections. (only required with TCP)