Socket does not receive UDP packet with source address 255.255.255.255

My problem is that I want a socket in my application to receive an UDP packet whose source address is 255.255.255.255 or 192.168.0.255 (subnet mask 255.255.255.0). I've tried both with the MFC CAsyncSocket and with the SOCKET of the API.
A sniffer application (Ethereal, see gif attached) shows that packet arrives to my machine but it does not trigger the CAsyncSocket::OnReceive event function on my program (MFC version), nor the recvfrom function (sockets API version).

Somehow the system is not passing that packet to the application level, although it arrives to the correct port; apparently because of its extrange source address.

If the source address is any other (for example, 192.168.0.80) I receive the packet.

Does any guru know what is happening? Any explanations?
Is there any way to set the operating system or to set my socket so that it receives the packet?

Thank you in advanced,

Ricardo Vázquez.
Madrid, Spain.


Code below (sockets API version), just in case someone needs it to answer my question:
-------------------------------------------------------------------

Code:

---

int nRet;
CString msg, err;

// Create an UDP socket, set to send broadcast
//
if (!AfxSocketInit())
 {
 AfxMessageBox("Windows Sockets initialization failed.");
 return;
 }

m_listenSocket = socket(AF_INET, SOCK_DGRAM, 0);
if (m_listenSocket == INVALID_SOCKET)
{
 err.Format("Could not create listen socket: %ld", WSAGetLastError());
 AfxMessageBox(msg);
 return;
}

int nVal = 1;
nRet = setsockopt (m_listenSocket, SOL_SOCKET, SO_BROADCAST, (char*)&nVal,
sizeof(nVal));
if (nRet == SOCKET_ERROR)
 {
 err.Format("setsockopt(SO_BROADCAST) error: %ld", WSAGetLastError());
 AfxMessageBox(err);
 }

// Bind our name to the socket
//
SOCKADDR_IN saServer;
saServer.sin_addr.s_addr = INADDR_ANY;
saServer.sin_port = htons(23000);
saServer.sin_family = AF_INET;

nRet = bind(m_listenSocket, (sockaddr*)&saServer, sizeof(saServer));
if (nRet == SOCKET_ERROR)
{
 err.Format("bind() error: %ld", WSAGetLastError());
 AfxMessageBox(msg);
 closesocket(m_listenSocket);
 return;
}

// Broadcast message
//
msg = "$(FF FF FF FF FF FF) MAC";

SOCKADDR_IN saServer2;
char szAdd [] = "192.168.0.255";
saServer2.sin_addr.s_addr = inet_addr(szAdd);
saServer2.sin_port = htons(23081);
saServer2.sin_family = AF_INET;

if (sendto (m_listenSocket, msg, msg.GetLength(), 0, (LPSOCKADDR)&saServer2,
sizeof(struct sockaddr)) != msg.GetLength())
 {
 err.Format("sendto() error: %ld", WSAGetLastError());
 AfxMessageBox(msg);
 return;
 }

// Receive (on port 23000)
//
char szBuffer [2048];
int nBytesRead;
struct sockaddr_in from;
int fromlen = sizeof(from);

nBytesRead = recvfrom(m_listenSocket, szBuffer, sizeof(szBuffer), 0, (struct
sockaddr*)&from, &fromlen); // <-- app stops here forever: it never receives

if (nBytesRead  == SOCKET_ERROR)
 {
 err.Format("recvfrom() error: %ld", WSAGetLastError());
 AfxMessageBox(msg);
 return;
 }

szBuffer[nBytesRead] = 0;
AfxMessageBox(szBuffer);

---

To my knowledge broadcast address does not come as the source address. Out of curiosity (because of your attached ethreal image) a little search revealed that some buggy ICMP implementation will cause such packets. The stack on your machine might have dropped such packet, because such address cannot be the source. Why do you need to receive such packets anyway? Your source code seems to be OK.

Hi Mathew!

Thank you for your interest.
This is all about auto-configuration of the IP address of a device made by the company I work for: When you first connect it to a subnet, that device has no IP assigned. So I'm trying to develop a service that will talk to that device and assign it a correct IP.
That's why at first its source address is that weird one.
We could give it any other one, maybe just for the first communication from device to PC, assuming risks about another machine in that subnet with the same IP address. I suppose this is the solution we will implement.

Yours,

Ricardo Vazquez.

There are some IP address that are used exclusive for testing purpose. Not sure but I think they belong to the class E category (240.0.0.0 - 247.255.255.255). You can use those address for the initial ones.