Sending broadcast UDP messages on port 5353

Jarrod Roberson <>
Sat Dec 5 06:46:36 CET 2009

My Java, Python and Objective-C, and C code can send on Port 5353 on
the same machine,
I can't figure out how to make Erlang do the same.
There is some kind of magical combination of options I need and I
can't figure out what they are.
I am opening a port like this and it is able to listen and receive messages.


start() ->
   %% start the process listening for mdns messages
  {ok,S} = gen_udp:open(?PORT,[{reuseaddr,true},{ip,?ADDR},binary]),

I appears that {reuseaddr,true} only applies to listening on that
PORT, because I
receive packets with the code in start/0 just fine.
I just get silent failures, nothing comes thru on any of my other
listening clients.
And I don't get any error dumps or anything.
I even tried adding {broadcast,true} to the above options and that
didn't work either.
I can't get it SEND anything using that socket S so . . .

I have tried creating a whole new socket like this


send() ->
   H = #dns_header{qr=1,aa=1},
   {ok,HN} = inet:gethostname(),
   D = "test@" ++ HN ++ "._test._tcp.local",
   R = #dns_rr{domain="_test._tcp.local",type=ptr,ttl=4500,data=D},
   Rec = #dns_rec{header=H,anlist=[R]},

and all I get is this

Eshell V5.7.4  (abort with ^G)
1> inet_mdns:send().
** exception error: no match of right hand side value {error,eaddrinuse}
     in function  inet_mdns:send/0

If I pass in PORT = ZERO then it works but that really doesn't do me any good
because of the way the spec for this service is written.

I REALLY need to be able to SEND on 5353 because of the spec below.
Here is why I can't do the gen_udp with port ZERO.

" If the source UDP port in a received Multicast DNS Query is not port
   5353, this indicates that the client originating the query is a
   simple client that does not fully implement all of Multicast DNS.
   In this case, the Multicast DNS Responder MUST send a UDP response
   directly back to the client, via unicast, to the query packet's
   source IP address and port. This unicast response MUST be a
   conventional unicast response as would be generated by a conventional
   unicast DNS server; for example, it MUST repeat the query ID and the
   question given in the query packet."

More information about the erlang-questions mailing list