Thread Info
  • State Not Answered
  • Replies 14 replies
  • Subscribers 0 subscribers
  • Views 7093 views
  • Users 0 members are here
Options
Suggested

[8.285][NOTABUG][CLOSED] External interface won't come up when using DHCP

garylaw
Background

I have been running ASG 8.103 on hardware for a while - runs well.
I installed ASG 8.103 as VM on esxi 5.
Made sure the MAC of the external connection was same as hardware box.
Imported config , moved cables - everything works fine.

Now for the Beta

I installed the latest 8.290 as VM on same esxi 5.0 host
I set the MAC address of the external interface the same as it was on the existing ASG 8.103. 
Imported config, turned off the 8.103 VM and turned on the 8.290.
External interface is marked as down and there was nothing I could do to bring it up.
Re-booted DSL modem (note it is a modem so it is bridging connection to the ISP.) - No effect.
Tried renewing the lease from the ASG  - no effect.

This is the same as I saw when I tried using 8.201 and 8.202 on the physical box.  Something is different in the DHCP client that does not allow it to be connected when there is a lease existing.


UPDATE:  I used an XP instance where I cloned the MAC address and connected this to my WAN  (disconnected the ASG ).
The XP got the same DHCP lease as the ASG 8.103 instance had.
I then did a ipconfig /release to force a release of the lease.

Disconnected XP and re-connected the ASG 8.290 interface

This worked - the 8.290 now has the external interface  "UP"
Parents
  • 0
    Theres no need to rush, 8.300 is closed [:)] If there is an astaro bug, this will get released with 8.301...

    Setup ASG 8.290, ASG 8.105 and Windows XP with DHCP and compared the DHCP Discovery Packets. Since 8.200 we are not sending the DHCP Option "Client Identifier" and the DHCP Option "Hostname" anymore. Maybe that causes trouble, some kind of security validation of your ISP?

    * Hostname: In 8.100 we send the hostname even if not configured. In 8.300 you can enable sending
    the hostname by setting the variable to any string under Advanced in the DHCP interface.

    * Client Identifier: You can edit /var/chroot-dhcpc/etc/default.conf and insert "send dhcp-client-identifier = hardware;" without quotes in a new line between script and HOSTNAME. Then disable and enable the DHCP interface again.


    So can you try to reproduce this and see if setting the hostname or the client identifier or both fix this issue?

    You could start by starting a new 8.290 and see if this time the new ASG gets the lease immediately.
    If thats the case, try to lease with the Windows XP system again (so hostname and client identifier is set) and don't release the IP this time. Then try again to get a lease with the ASG...

    Thanks for testing this!
     Ulrich
Reply
  • 0
    Theres no need to rush, 8.300 is closed [:)] If there is an astaro bug, this will get released with 8.301...

    Setup ASG 8.290, ASG 8.105 and Windows XP with DHCP and compared the DHCP Discovery Packets. Since 8.200 we are not sending the DHCP Option "Client Identifier" and the DHCP Option "Hostname" anymore. Maybe that causes trouble, some kind of security validation of your ISP?

    * Hostname: In 8.100 we send the hostname even if not configured. In 8.300 you can enable sending
    the hostname by setting the variable to any string under Advanced in the DHCP interface.

    * Client Identifier: You can edit /var/chroot-dhcpc/etc/default.conf and insert "send dhcp-client-identifier = hardware;" without quotes in a new line between script and HOSTNAME. Then disable and enable the DHCP interface again.


    So can you try to reproduce this and see if setting the hostname or the client identifier or both fix this issue?

    You could start by starting a new 8.290 and see if this time the new ASG gets the lease immediately.
    If thats the case, try to lease with the Windows XP system again (so hostname and client identifier is set) and don't release the IP this time. Then try again to get a lease with the ASG...

    Thanks for testing this!
     Ulrich
Children
  • 0 in reply to da_merlin
    Hi Ulrich

    I managed to get the problem in reverse.

    I built 2 new virtual machines.
    Machine 1 = 8.103
    Machine 2 = 8.290

    Put the WAN connection of esxi server in promiscuous mode and used a pfsense instance as packet sniffer on this interface.

    Defaulted ALL config options in the wizard for the 8.103 and 8.290 - used only 2 nic for each - LAN and WAN.

    1. I made sure the mac address at the WAN was the same as the existing (working) 8.290 installation  (for both - did not use the virtual mac within ASG - used manual setting in esxi)

    2. I disconnected the working 8.290 from WAN , powered up the 8.103 instance and connected it to the WAN

    It would NOT get a lease ;-).  Tried taking it down and up again in asg - tried a renew from within asg.

    Packet capture is in attached 8.103.packetcapture.cap.txt  (added .txt so I could upload)

    3. I then disconnected this machine from the WAN.

    4. Re-connected the working 8.290 instance to ensure it still was functional - check ;-)

    5. I disconnected the working 8.290 from WAN , powered up the new 8.290 instance and connected it to the WAN

    It successfully got a lease ;-)

    Packet capture is in attached 8.290.packetcapture.cap.txt  

    6. I then disconnected this machine from the WAN.

    7. Re-connected the working 8.290 instance to ensure it still was functional - check ;-)


    So it seems the ISP (Verizon in USA) does something in security to check the DHCP Lease (or some settings in it over and above the MAC ...).

    So not exactly the test you asked for - but close [;)]

    I tried getting a capture for the working 8.290, but whether I took the interface down or tried a renew I could not get it to send a DHCP request. (I assume this is because there is still a valid lease in database ??)

    Let me know if there is something else you would like me to try.
Unfiltered HTML