DHCP server doesn't see the client request
- FOG Version: 1.4.4
- OS: ubuntu
- Service Version:
- OS: windows 7
I meet an issue with FOG server.
My client can boot wit pxe. It gets an IP with dhcp. So there is the menu.
However, when I select the menu.
On the client I get those messages :
Populating /dev using udev: udevd: error creating epoll fd: function not implemented done Initializing random number generator... done Starting eth0 interface and waiting for the link to come up udhcpc: started, v1.26.2 udhcpc: sending discover udhcpc: sending discover udhcpc: sending discover udhcpc: no lease, failing udhcpc: started, v1.26.2 [.../...] udhcpc: no lease, failing No DHCP response on interface eth0, skipping it. Failed to get an IP DHCP! Tried on interfaces(s): eth0 Please check your network setup and try again
What is pretty weird. DHCP server on FOG server doesn’t see that second request.
I mean. The client has boot pxe. DHCP serve logged it. And when you select the menu, it looks like there is second request for IP address. But there is no log.
I just tested Host registration and deploying image. So I confirm. It works.
@olivetree Have you tested it first. I don’t want to just solve it based on what your network admin’s say.
I submitted the spanning tree problem to networking admins. They told me now the port is on “spanning tree portfast”. So it works.
So then it’s solved. Thank you.
@olivetree Well then, now I think its a spanning tree issue. The (dumb) unmanaged switch keeps the building switch’s port from winking as the pxe client boots. The standard spanning tree protocol listens for 27 seconds for a bpdu packet before putting the network port in forwarding mode. Where the fast stp protocols starts forwarding right away and then listens for a bpdu packet. During the pxe booting, FOG iPXE menu, FOS booting process (such as in a deployment) the target computer’s network link will wink twice resetting the 27 second timer each time. FOS boots so fast by the time the port starts forwarding its already given up on trying to boot. So the unmanaged switch helps us test this process by keeping the STP timer at 0 and the port forwarding.
You will need to get with your networking admin to try to understand why standard spanning tree is enabled.
The other thing we have see is that the dumb switch also interrupts (in a good way) the miscommunication between the target computer and the green ethernet (802.3az) handshake with certain realtek chips. Its more likely its a spanning tree issue over green ethernet, but we have seen both happen.
thank you very much. I plugged an old netgear swith 5 ports FS105. And… It works!
Wayne Workman last edited by
@olivetree Put a dumb switch (layer 2 switch) between your building’s network and this box, and see if it still acts the same.
I confirm FOG Settings->Web Server ->FOG_WEB_ROOT is
The network admin fixed the spanning tree issue and the link is on fast
I understood the client can’t reach FOG server. But I don’t see why. FOG server and client are on the same vlan. DHCP server and FOG server are on the same server.
Please confirm that FOG Settings->Web Server ->FOG_WEB_ROOT is configured correctly. It should contain
This also could be a spanning tree issue in that standard spanning tree is enabled and not one of the fast protocols (RSTP, MSTP, FastSTP, etc). But you should see this earlier in the process.
This error above usually relates to the dhcp client not being able to reach the FOG server during FOS booting. It will typically do this process 3 times and then give up.
udhcpc: started, v1.26.2 udhcpc: sending discover udhcpc: sending discover udhcpc: sending discover udhcpc: no lease, failing udhcpc: started, v1.26.2 ...
Its a bit misleading in that the target computer may be getting a dhcp address but unable to reach the fog server for some reason.