Re: UDP Broadcasts Don't Work
Re: UDP Broadcasts Don't Work
- Subject: Re: UDP Broadcasts Don't Work
- From: "Peter Sichel" <email@hidden>
- Date: Mon, 20 Aug 2007 10:02:31 -0400
The BSD network stack handles broadcasting a little differently than you
might expect.
To send a generic UDP broadcast, you must set the destination address to
the subnet broadcast address (a subnet directed broadcast). That is, if
your IP subnet is 192.168.0.1/24, you would send to 192.168.0.255 to
broadcast to that subnet. The IP destination will read 192.168.0.255
but the Ethernet MAC address will be the hardware broadcast address.
Since the network stack is multi-homed, sending to 255.255.255.255 makes
it potentially ambiguous which network ports you want to broadcast on
(so in BSD land, the behavior is undefined). In Mac OS 9, Open
Transport would simply copy the packet as needed and send it out every
active network port which made things quite a bit easier.
If for some reason you don't know the correct IP subnet to use, it isn't
configured yet, or can change unpredictably, you may wish to use BPF for
broadcasting similar to "bpftransmit" in the Darwin bootp project (but
you'll need to select the data link and build the UDP header yourself).
In my own experience, bpftransmit has been more reliable. The DHCP
Server in IPNetRouterX (and DHCP Test tool in IPNetMonitorX) need to
broadcasts DHCP queries and responses. I initially used directed subnet
broadcast which worked most of the time, but there were certain obscure
cases where it didn't work as expected because you can't predict what IP
subnets the user might have configured on their machine or how other
network clients will respond. Some users for example might have
Ethernet and Airport interfaces on the same IP subnet with both active
at the same time. Some DHCP clients it appears don't like broadcasts
not addressed to the IP broadcast address (255.255.255.255).
In other words, your title is just about right. UDP broadcasts don't
work (reliably :-), so you may wish to send raw packets instead.
Kind Regards,
- Peter Sichel
Sustainable Softworks
www.sustworks.com
On 8/18/07, Brian Barnes wrote:
>This has to be something simple because I know other programs
>successfully do this. I have a server/client, and the client does a
>broadcast of a small message to find servers.
>
>The code is simple, open a UDP datagram socket, set the SO_BROADCAST
>flag, and then use sendto on INADDR_BROADCAST. No machine (including
>itself) on my small network gets the packet. Again, other programs do
>this successfully on my network, so it's got to be my bug instead of
>some network setup issue.
>
>Weird thing -- localhost doesn't work either. BUT, if I use the direct
>IP of the server, everything works perfectly. So the socket code seems
>fine, it's just 255.255.255.255 that's the problem.
>
>Simple code:
>
>bool network_udp_send_broadcast(int port)
>{
> int opt,err;
> d3socket sock;
> struct sockaddr_in addr;
>
> // open socket and allow broadcasting
>
> sock=socket(AF_INET,SOCK_DGRAM,0)
> if (sock==D3_NULL_SOCKET) return(FALSE);
>
> opt=1;
> setsockopt(sock,SOL_SOCKET,SO_BROADCAST,&opt,sizeof(int));
>
> // send broadcast
>
> memset(&addr,0x0,sizeof(struct sockaddr_in));
>
> addr.sin_family=AF_INET;
> addr.sin_port=htons((short)port);
> addr.sin_addr.s_addr=INADDR_BROADCAST; // 255.255.255.255, put the
>direct server IP instead and it works fine
>
> err=sendto(sock,"dim3",4,0,(struct sockaddr*)&addr,sizeof(struct
>sockaddr_in)); // send simple packet, the return IP is the important part
>
> network_close_socket(&sock);
>
> return(err==4);
>}
>
>Note that works WITHOUT error even though no data seems to be
>broadcast. What have I done wrong here? Any ideas?
>
>[>] Brian
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden