DHCP lease renewal failure (Fedora 12 x86-64, Parallels Desktop 5.0.9370, OSX 10.6.4)

Discussion in 'Linux Virtual Machine' started by Anthony Foiani, Aug 19, 2010.

  1. Anthony Foiani

    Anthony Foiani Bit poster

    Messages:
    2
    I'm seeing an odd behavior with my Fedora guest install. Any initial / manual DHCP activation works fine; but when the lease time is up, it's not able to successfully renew the lease, and NetworkManager eventually gives up and disables the interface.

    The root cause seems to be some odd ARP interactions: when dhclient attempts to renew the license, it sends targeted DHCPREQUEST packets to the original DHCP server. After that fails for a while, it then tries to send DHCPREQUEST to the local broadcast address (255.255.255.255). When that fails, it gives up. As soon as I initiate a new manual connection, a proper sequence of DHCP DISCOVER / OFFER / REQUEST / ACK takes place.

    Tracing ARP packets shows that when my guest (192.168.1.168) tries to find the DHCP server (192.168.1.1), the conversation goes something like this:

    14:57:20.739590 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.168, length 28
    14:57:20.742301 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 00:24:b2:d6:d1:1e, length 28

    That's good so far. But when the server (at .1) tries to get the address for the client (at .168), things go pear-shaped:

    14:58:14.252355 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.168 tell 192.168.1.1, length 28
    14:58:14.252897 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.168 is-at 00:26:bb:03:78:0d, length 28

    This is a problem, because the MAC addresses are wrong. Within the guest, I have:

    linux$ ifconfig eth1
    eth1 Link encap:Ethernet HWaddr 00:1C:42:A1:79:83
    inet addr:192.168.1.168 Bcast:192.168.1.255 Mask:255.255.255.0
    inet6 addr: fe80::21c:42ff:fea1:7983/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:1223683 errors:0 dropped:0 overruns:0 frame:0
    TX packets:682783 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:1599379892 (1.4 GiB) TX bytes:109207918 (104.1 MiB)
    Interrupt:10 Base address:0x8400

    But the MAC address for the guest eth1 (.168) is 00:1C:42:A1:79:83 -- but the ARP response is giving 00:26:bb:03:78:0d, which is the MAC address of the host (which is actually at 192.168.1.153):

    mac$ ifconfig en1
    en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
    ether 00:26:bb:03:78:0d
    inet6 fe80::226:bbff:fe03:780d%en1 prefixlen 64 scopeid 0x6
    inet 192.168.1.153 netmask 0xffffff00 broadcast 192.168.1.255
    media: <unknown subtype>
    status: active

    This configuration used to work flawlessly; this problem started only after I temporarily changed the VM networking to be "host-only". I have since changed it back to "bridged", but it's still disconnecting me every 24 hours or so. (That's the result of about 10 hours lease time, then 10 hours sending DHCPREQUEST to 192.168.1.1, then another hour or two sending DHCPREQUEST to 255.255.255.255, before giving up and disabling eth1.)

    Anyone have any ideas? At this point, it's mostly just an inconvenience -- but I'd like to get it working stably again.

    Thanks!
     
  2. joevt

    joevt Forum Maven

    Messages:
    1,229
    What if you delete the network adapter device from the hardware list in the virtual machine configuration. Then add a new network adapter device? That should remove whatever happened when you temporarily changed the VM networking to be "host-only". You could save the config.pvs file in the .pvm before and after the change and compare them to see if anything actually changed.
     

Share This Page