Opened 9 years ago
Last modified 9 years ago
#13785 new defect
OS X Guest with Bridged Networking cannot obtain DHCP lease - guest actively DHCPDECLINEs due to host activity — at Initial Version
| Reported by: | Jason Woods | Owned by: | |
|---|---|---|---|
| Component: | network | Version: | VirtualBox 4.3.20 |
| Keywords: | bridged | Cc: | |
| Guest type: | Linux | Host type: | other |
Description
Host: OS X Yosemite 10.10.1 VirtualBox: 4.3.20 Guest: CentOS 6.4
I have configured an OS X VirtualBox guest with a primary interface as NAT, a private network secondary, and a tertiary interface as Bridge Networking with DHCP. I have bridged to my Airport Wi-Fi adapter.
When the machine boots it nearly always fails to obtain an IP address for the bridged interface. In rare cases it will actually succeed. Retrying it will eventually work though rarely (run it 100 times in a loop maybe.)
Running dhclient -v eth2 shows the guest is declining the IP offer when it fails:
[root@localhost ~]# dhclient -v eth2 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth2/HI:DD:EN:HI:DD:EN Sending on LPF/eth2/HI:DD:EN:HI:DD:EN Sending on Socket/fallback DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 5 (xid=0x2bc89bf5) DHCPOFFER from 192.168.0.1 DHCPREQUEST on eth2 to 255.255.255.255 port 67 (xid=0x2bc89bf5) DHCPACK from 192.168.0.1 (xid=0x2bc89bf5) DHCPDECLINE on eth2 to 255.255.255.255 port 67 (xid=0x2bc89bf5)
This seems to be because it sees the IP as already existing - though it doesn't. I modified /sbin/dhclient-script to show the arping output like this:
arping -D -c2 -I ${interface} ${new_ip_address} RC=$? echo "Exit: $RC" [ $RC -ne 0 ] && exit_with_hooks 1
Interestingly, if I didn't exit and let it run its own arping afterwards - it would always succeed. More on that shortly.
Output is below:
[root@localhost ~]# dhclient -v eth2 Internet Systems Consortium DHCP Client 4.1.1-P1 Copyright 2004-2010 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth2/HI:DD:EN:HI:DD:EN Sending on LPF/eth2/HI:DD:EN:HI:DD:EN Sending on Socket/fallback DHCPDISCOVER on eth2 to 255.255.255.255 port 67 interval 5 (xid=0x2bc89bf5) DHCPOFFER from 192.168.0.1 DHCPREQUEST on eth2 to 255.255.255.255 port 67 (xid=0x2bc89bf5) DHCPACK from 192.168.0.1 (xid=0x2bc89bf5) ARPING 192.168.0.149 from 0.0.0.0 eth2 Broadcast request from 192.168.0.149 [HI:DD:EN:HI:DD:EN] for 192.168.0.1 [00:00:00:00:00:00] 1.163ms Sent 1 probes (1 broadcast(s)) Received 1 response(s) (1 request(s), 1 broadcast(s)) Exit: 1 DHCPDECLINE on eth2 to 255.255.255.255 port 67 (xid=0x2bc89bf5)
Arping detects a broadcast request coming from the IP it just allocated... the Mac address there is the HOST's MAC address. So something on the host sends this request from the allocated IP, and arping here catches it and fails duplicate address detection, meaning dhclient declines the address.
Weirdly, if I precede the dhclient-script arp check with a sleep 2 instead of the debug lines above - it never works. Replace it with just a single arping command, it works every time. Seems something is happening on the host in response to the FIRST arp check. So the first fails, and the second arp check succeeds (though normally there is only one check - it's just in my debugging I stumbled on it.)
Any ideas what is causing this request from the host? Is it a VirtualBox thing or a OS X thing? Any possible fix?
VBox.log