[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