...
If no interface is linked to a socket (using NetSock_CfgIF()) and if a UDP datagram is received on this listening socket bound to the “any” address and the application transmits a response back to the peer using the same socket, then the newly transmitted UDP datagram will be transmitted from the default interface. The default interface may or may not be the interface in which the UDP datagram originated.
Detecting if a Socket is Still Connected to a Peer Peer
Applications may call NetSock_IsConn() to determine if a socket is (still) connected to a remote socket (see function NetSock_IsConn()).
Alternatively, applications may make a non-blocking call to recv(), NetSock_RxData(), or NetSock_RxDataFrom() and inspect the return value. If data or a non-fatal, transitory error is returned, then the socket is still connected; otherwise, if ‘0’ or a fatal error is returned, then the socket is disconnected or closed.
Receiving -1 Instead of 0 When Calling recv() for a Closed Socket
When a remote peer closes a socket, and the target application calls one of the receive socket functions, µC/TCP-IP will first report that the receive queue is empty and return a -1 for both BSD and µC/TCP-IP socket API functions. The next call to receive will indicate that the socket has been closed by the remote peer.
This is a known issue and will be corrected in subsequent versions of µC/TCP-IP.
The Application Receives Socket Errors Immediately After Reboot Reboot
Immediately after a network interface is added, the physical layer device is reset and network interface and device initialization begins. However, it may take up to three seconds for the average Ethernet physical layer device to complete auto-negotiation. During this time, the socket layer will return NET_SOCK_ERR_LINK_DOWN for sockets that are bound to the interface in question.
...