It seems that recvfrom() can get in a state where it returns the same information whenever called even though there are no network UDP packets (the socket setup) flowing to the device (IPaddr:port), or anywhere on the LAN for that matter. My assumptions is that recvfrom() blocks till a new packet meeting the sockets setup arrive at the device. Single stepping across the misbehaving recvfrom() call returns the clients info which indicates the source, however my network trace tool, omnipeak, does not confirm a packet from the machine which would have caused the delivery of a packet to the upper layers on the DSP prototype.
Is there an outstanding issue reported about this, or am I the only one to see this behavior?
Rob
