[Dnsmasq-discuss] Problem with VM and dnsmasq
mario
jjskoli at gmail.com
Tue Oct 13 14:00:28 BST 2015
Yes, thank you Albert, you were perfectly right. This thread is now
solved, shall I somehow
signal this?
On 10/13/2015 01:28 PM, Albert ARIBAUD wrote:
> Ok.
>
> I'm not a strace guru, so I did not look into it at first, but I
> finally decided to try and I think I got something from the strace.
> Look at this part:
>
> write(2, "DHCPOFFER(brlan) 192.168.73.95 0"...,
> 49DHCPOFFER(brlan) 192.168.73.95 08:00:27:03:6a:3e ) = 49
> write(2, "\n", 1 ) = 1
> stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2652, ...}) = 0
> write(12, "<134>Oct 8 10:42:41 dnsmasq-dhc"..., 91) = 91
> alarm(7646) = 7646
> sendmsg(4, {msg_name(16)={sa_family=AF_INET, sin_port=htons(68),
> sin_addr=inet_addr("255.255.255.255")},
> msg_iov(1)=[{"\2\1\6\0\334\330J\374\0\5\200\0\0\0\0\0\300\250I_\300\250I\1\0\0\0\0\10\0'\3"...,
> 320}], msg_controllen=28, {cmsg_len=28, cmsg_level=SOL_IP,
> cmsg_type=, ...}, msg_flags=0}, 0) = -1 EPERM (Operation not
> permitted)
>
> This EPERM seems to indicate that your gateway, for some reason, does
> not allow dnsmasq to send *this* packet (previous sendmsg calls for the
> same MAC did return ok), which explains why it does not show in the
> dump.
>
> Adding Simon as cc: just to draw his attention on this EPERM -- it
> might ring a bell to him.
>
> Now, EPERM is usually due to some security or networking policy, or to
> the gateway's network configuration, but in the same strace some DHCP
> replies to the VM's MAC return ok, so I'm not sure what happens here.
>
>
> Amicalement,
I had the following rule in my iptables:
iptables -A OUTPUT -d 255.255.255.255 -j DROP
and, for some reason which I do not understand, while the BOOTP/DHCP
requests from pcs and VMs connected thru ethernet do not entail replies
to the broadcast address of the zero network, those for
VMs connected thru wifi do use it. I introduced the above rule when I
still thought that being a good
netizen meant blocking packets addressed to non-routable subnets,
malformed packets, an so on.
After removal of said rule, VMs connected thru host's wifi get their IP
address from the gateway's dnsmasq without any problem. This thread is
solved.
I will have to start dabbling in strace, because it obviously can find
you the solution when nothing
else can. When they told me, as a grad student, that being an
astrophysicist meant knowing a little of
everything, I did not think this would turn out to be so true. ;-)
Cheers, and thanks once again.
Mario
More information about the Dnsmasq-discuss
mailing list