[Dnsmasq-discuss] Problem with VM and dnsmasq

Albert ARIBAUD albert.aribaud at free.fr
Tue Oct 13 12:28:27 BST 2015


Hi mario,

Le Tue, 13 Oct 2015 12:29:57 +0200, mario <jjskoli at gmail.com> a écrit :

> Dear Albert,
> 
> On 10/13/2015 11:49 AM, Albert ARIBAUD wrote:
> > Actually not all of them: I believe you have not tested my suggestion 
> > that you set a fixed IP in the VM instead of using DHCP, connect the 
> > host through wlan, boot up the VM and then test connectivity between 
> > the VM and gateway ([ar]ping, netcat...) so that you can determine 
> > whether your issue is DHCP-related or "just" network-related. 
> > Amicalement, 
> 
> it works perfectly, see the attached file. Sequence of ops:
> 
> 1. Disconnect host from ethernet; put it on wifi;
> 2. configure VM to connect thru the host wlan0 interface, bridge adapter.
> 3. start VM; in VM... (see attached file!)
> 4. stop network-manager;
> 5. check that VM's ethernet interface has not received an IP address 
> from gateway;
> 6. Configure VM's eth0 manually;
> 7. Ping remote site.

Ok, so ICMP (with ping) and UDP (through name resolution) do work,
which leaves the 

> On 10/13/2015 11:49 AM, Albert ARIBAUD wrote:
> > Actually, The reply is lost somewhere between the gateway (where the
> > reply is seen to be sent) and the host (where it is not seen to be
> > received). It is unsure whether it could leave the gateway or not. It
> > could have left the gateway been lost by the AP (which, IIUC, is
> > another machine as the gateway).
> 
> Nope, there is a slight confusion: the tcpdump capture on the gateway 
> includes two distinct conversations, one with a normal Intel pc with MAC 
> address c4:85:08:7d:79:40 which DOES receive
> two replies, and another connection with the typical (for VirtualBox 
> VMs) CADMUS pc with MAC address
> 08:00:27:03:6a:3e, which is the VM I am talking about, which never 
> receives a reply, even though the
> daemon.log displays the fact that dnsmasq has offered it a perfectly 
> good IP address.
> 
> In other words, dnsmasq's reply is lost somewhere between dnsmasq itself 
> and tcpdump on the same gateway.

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.

> Cheers,
> 
> Mario


Amicalement,
-- 
Albert.



More information about the Dnsmasq-discuss mailing list