[zeromq-dev] RFC: zbeacon for dhcp-style discovery
mail17 at mah.priv.at
Sat Nov 30 18:30:43 CET 2013
Am 30.11.2013 um 17:16 schrieb Arnaud Loonstra <arnaud at sphaero.org>:
> On 11/30/2013 03:49 PM, Michael Haberler wrote:
>> I have a seemingly trivial problem where I currently have tunnel vision:
>> if I send a directed UDP packet to the beacon socket, the s_beacon_recv () callback isnt called except if I force the destination address to broadcast (255.255.255.255; in which case tcpdump does display the packet)
>> if I set the sender address to one of the interface addresses, the packet doesnt go out as per tcpdump and s_beacon_recv() isnt called
>> I wonder if I stepped into some socket behavior which I overlooked? noecho is not the cause btw.
>> - Michael
> Hi Michael,
> I just tried it with the python zbeacon and the only way I can send data
> from socat to the socket is by specifying the broadcast option:
> $ socat - UDP-DATAGRAM:255.255.255.255:5670,broadcast
> works okay, I reveive an error in zbeacon because the filter doens't match.
> $ socat - UDP-DATAGRAM:255.255.255.255:5670
> 2013/11/30 17:11:57 socat E sendto(3, 0x1ad99d0, 28, 0, AF=2
> 255.255.255.255:5670, 16): Permission denied
> In netstat I see the socket only listening on the broadcast address:
> udp 0 768 255.255.255.255:5670 0.0.0.0:*
thanks! this makes perfect sense - my implicit assumption so far was that udpsocket would receive unicasts just as well, which likely was the error - in retrospect there's no good reason it should
this would suggest that binding udpsocket also for each interface address will result in the desired behavior. I'll try that but I'm sure that was it.
is that a change we're willing to accept? I dont see side effects as of now - yet
> I haven't read the docs but I guess this is normal socket behaviour?
> w: http://www.sphaero.org
> t: http://twitter.com/sphaero
> g: http://github.com/sphaero
> i: freenode: sphaero_z25
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
More information about the zeromq-dev