   SDLNet_UDP_Recv problem...
  Probably there's an easy explanation that eludes me...I tried writing some UDP LAN server discovery code today for an old game using SDL_net.I simply let each "server" broadcast UDP packets (I'm aware this is better done with multicasts on modern systems, one step at a time though) with a certain frequency to a specific port.Sending works fine; one would expect SDLNet_UDP_Receive to work as well. Turns out it doesn't catch a single packet.//Method has to be static because it is an argument to SDL_CreateThreadint UDPServiceProvider::listenForSessions(UDPServiceProvider * sp){   // Create UDP socket.   unsigned short port;   SDLNet_Write16(BROADCAST_PORT_NUMBER, &port);   UDPsocket socket = SDLNet_UDP_Open(port);   if (socket == NULL) { NETMSG("Failed to open UDP socket: %s", SDLNet_GetError()); return Lb_FAIL;   }   // Create packet.   UDPpacket * const packet = SDLNet_AllocPacket(MAX_BROADCAST_PACKET_SIZE);   if (packet == NULL) { NETMSG("Failed to create UDP packet: %s", SDLNet_GetError()); SDLNet_UDP_Close(socket); return Lb_FAIL;   }   // Listen.   sp->sessionListenCond.lock();   while (!sp->sessionListenCond.shouldExit()) { SYNCDBG(7, "Attempting receive"); int result = SDLNet_UDP_Recv(socket, packet); if (result == 1) {    SYNCDBG(7, "Received packet of length %d", packet->len);    packet handling cut out for clarity... } else {    if (result == -1) {   NETMSG("Error on packet reception");    }    sp->sessionListenCond.waitMs(SESSION_IDLE_LISTEN_PERIOD); }   }   sp->sessionListenCond.unlock();   SDLNet_FreePacket(packet);   SDLNet_UDP_Close(socket);   return 0;}//Don't bother criticizing mix of C and C++, it has to interface with tens of thousands of lines of legacy code.Eliminating some suspects:- Packet size should be enough (200 bytes max length vs. 30-40 actually used). I also tried with 0xFFFF for max length and it made no difference.- Made sure antivirus/firewalls were off. I have a router which can not completely be disabled though and I'm guessing 255.255.255.255 will not work under any circumstances. 192.168.0.255 should though AFAIK.- Sending works fine, and I can verify via Wireshark that packets get sent from my machine to 255.255.255.255, 192.168.0.255, etc. at regular intervals containing correct data. I'm not sure any these actually bounce back to my source computer though. (Should they?)- "Attempting receive" is printed often enough as you'd expect, so it's definitely executing the correct code. Result of SDLNet_UDP_Recv never equals 1 though.More relevant issues:- I have another computer on this LAN to test this on over remote control but it doesn't like 8 bit DirectDraw full screen games from the 90s. Thus, I only tested over loop back and broadcast addresses yet.- What makes me worried is not even loop back works (i.e. sending to 127.0.0.1).- Can it be something regarding threading? I'm fairly certain my own threading is correct (main thread remains reponsive at all times), but perhaps SDLNet has some issue with using a different thread than the one calling SDLNet_Init for SDLNet_UDP_Recv?My next step unless someone has a better idea will be to build a trivial console test app (I should've done this first instead of assuming this would be trivial ;-) ), to see if I can receive UDP packets at normal A to B sending on my LAN with same API and threading scheme...I'm not expecting miracles here, but I feel it's better to post if someone has a good idea; might save me a work day of debugging (a spare time project = up to 1 week less dev time).   
  You need to turn on SO_BROADCAST at the socket layer. No idea what SDL would call that option, or if it supports it.;  Edit: Never mind, got it work. Turns out I swapped byte order on receive port where SDL already did it for me, which effectively meant listening on thw wrong port anyway. (Stupidly enough, SDL doesn't do this when one fills in an address struct himself for sending an UDP packet.)[Edited by - Beyond_Repair on April 20, 2010 11:15:15 AM]