[Dnsmasq-discuss] Problem with VM and dnsmasq

[Albert ARIBAUD]

Hi mario,

Sorry for not replying sooner.

Le Thu, 8 Oct 2015 12:20:54 +0200, mario <jjskoli at gmail.com> a écrit :

> 
> First of all, I will say it  just once, but I have to say it: thanks for 
> your help.
> 
> 
> @Hartmut Krafft
> 
> Done, the output of tcpdump on the three machines (simultaneously) is 
> included in the
> file tcpdumps. Not very informative: the Reply never leaves the gateway.

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).

> @Simon Kelley
> 
> I have included the strace outputs in two included files, logeth0 (when 
> it works) and
> logwlan0 (when it does not work). I have snipped all lines pertaining to 
> the BAD FILE
> DESCRIPTOR, except for the first and last
> 
> close(6)                                = -1 EBADF (Bad file descriptor)
> close(65535)                            = -1 EBADF (Bad file descriptor)
> 
> in both files.
> 
> As for a method to reproduce the problem:
> 
> Host1= Linux rasal 3.16.0-49-generic #65~14.04.1-Ubuntu SMP Wed Sep 9 
> 10:03:23 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> VirtualBox1 = virtualbox-4.3 4.3.30-101610~Ubuntu~raring             amd64
> 
> Host2 = Linux debS 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt17-1 
> (2015-09-26) x86_64 GNU/Linux
> VirtualBox2= virtualbox 4.3.30-dfsg-1+deb8u1                 amd64
> 
> VM's: a variety: OpenBSD, ArchLinux, Debian
> 
> ALL of these display the same, identical problem, irrespective of Host 
> or VM. The logs above have been produced with Host1 (VirtualBox1, of 
> course).
> 
> Gateway: Linux router73 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt17-1 
> (2015-09-26) x86_64 GNU/Linux
> 
> # dnsmasq -v
> Dnsmasq version 2.72  Copyright (c) 2000-2014 Simon Kelley
> Compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua 
> TFTP conntrack ipset auth DNSSEC loop-detect
> 
> 
> Sequence of operations:
> 
> Cycle 1
> 1. Boot host1 ;  eth0 is on dhcp, served by dnsmasq on gateway; host1 
> obtains IP address correctly, everything OK;
> 2. BEFORE booting VM1, in configuration, Bridge Network Adapter is 
> chosen, set to attached to host's eth0;
>   3. Boot VM1; eth0 in VM is set to dhcp; IP address obtained correctly 
> from gateway's dnsmasq
> 4. Poweroff VM1;
> 5. Disconnect Host1 from eth0;
> 
> Cycle 2
> 6. Connect Host1 thru wlan0; IP address obtained correctly, everything OK
> 7. Configure VM1 to Bridge Network Adapter, but attached to host's wlan NIC;
> 8. Boot VM1; since eth0 inside VM1 is still set to dhcp, eth0 tries to 
> obtain IP address from gateway's dnsmasq, but NO success;
> 9. Poweroff VM1
> 10.Disconnect Host1 from wifi
> 
> Always reproducible: Cycle1 always yields a properly connected VM1, 
> Cycle2 always yields a disconnected VM2.
> 
> Tried this with both Host1 and Host2, and with OpenBSD/ArchLinux/Debian 
> VMs on both hosts: always reproducible.
> 
> As for the bug: difficult to say at this point. VirtualBox does not use 
> a bridge when the host is connected via wifi,
> for obvious reasons, so, in my case we are really comparing two 
> different ways of putting the VM onto the LAN.
> Also, VirtualBox does not give you any access to its connection 
> innards,so there is no
> control on  the bridge, if any.
> 
> @Albert Aribaud:
> 
> I think the above also answers your questions.

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,
-- 
Albert.