Failed to get an IP via DHCP!
-
@jes6309 OK that is what I expected. I need to ping the @Developers to see if that hardware is in the current FOS kernel since I haven’t seen that one before. We actually need to get the device id. There is a linux command (thinking lspci) that will display the vendor and hardware ID or we can get the same information from a windows system.
<edit> I just checked and its
lspci -kI’m suprised that my fog server running centos 7 doesn’t have lspci
ref: https://wiki.fogproject.org/wiki/index.php/Troubleshooting_Driver_Issues
</edit> -
@george1421 Ok here is the info I believe you are looking for:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)
Subsystem: Hewlett-Packard Company Device 8137
Kernel driver in use: r8169
-
@jes6309 There is actually numbers like 8086:1502 that we’ll be looking for. The first group is vendor and the second is hardware id.
lspci -nthen you will need to find the network adapter from the description -
@george1421 Ok, I think its 10ec:8136
-
@jes6309 As you can see here this NIC model is supported since kernel version 2.6.x and upwards. So it should not be a driver issue! As well, “Sending discovery…” actually means that we found a network interface and try to get an IP for it via DHCP. So it could be:
- Layer 1 issue like cable (you already checked that)
- Spanning tree issue (make sure you have RSTP or configured “port fast”)
- Auto-negotiation issue (try configuring static speed instead of auto-negotiation for that port)
- Ethernet energy saving (see if your switch has EEE/802.3az feature and disable if possible)
-
@Sebastian-Roth I will start looking into these things, but if a switch configuration was causing the issue, wouldn’t I have run into the problem before upgrading to trunk? Never had these issues occur on the normal version of fog.
Thanks!
-
@jes6309 said:
if a switch configuration was causing the issue, wouldn’t I have run into the problem before upgrading to trunk? Never had these issues occur on the normal version of fog.
Good point! Looking at if from this side only the last two bullet points seem to possibly cause the issue. Newer linux kernel with newer driver for the NIC might have a auto-negotiation problem or is now able to put the NIC in energy saving mode… and doing it wrong. Please check those two first.
-
@Sebastian-Roth said in Failed to get an IP via DHCP!:
@jes6309 As you can see here this NIC model is supported since kernel version 2.6.x and upwards. So it should not be a driver issue! As well, “Sending discovery…” actually means that we found a network interface and try to get an IP for it via DHCP. So it could be:
- Layer 1 issue like cable (you already checked that)
- Spanning tree issue (make sure you have RSTP or configured “port fast”)
- Auto-negotiation issue (try configuring static speed instead of auto-negotiation for that port)
- Ethernet energy saving (see if your switch has EEE/802.3az feature and disable if possible)
wiki worthy
-
@Sebastian-Roth Thanks! Setting static speed and enabling port-fast worked! I am now able to successfully register the host.
-
@jes6309 Can you please verify if it is static speed or port-fast that make it work in your case? We have seen more auto-negotiation issues with newer kernels lately. I am a bit concerned about this! Are we able to fix this from our side (kernel parameter or whatever)??
-
@Sebastian-Roth After reverting the port back to auto and leaving port-fast enabled, registration and imaging was still successful.
Looks like port-fast was the fix.
-
@Wayne-Workman I am getting the same issue as well. I have ensured that the TFTP username and password are correct, but I get the same error. Cannot update kernel and my kernel version does not show, same as @jes6309
-
-
Hi,
Just wanted to chime in and say I had the same issue, and the fix was the same- had to enable the ‘port-fast’ feature on our cisco switches.
From my reading of the cisco documentation it looks like its safe to enable this feature on all ports that are patches to ‘endpoint devices’ like PCs, printers etc.
Thanks to the posters in this thread for providing the required info. Nothing worse than finding a thread on the internet describing the exact issue you are having, and the last post is the original poster saying “I solved it” without elaborating what the fix was!
-
@mr626 This has been in the wiki documentation for many years! So I am wondering if it’s all just to hard to find. We should definitely work on getting the wiki updated I reckon!
-
@Sebastian-Roth I have to admit I didn’t come across the wiki entry in my search. Will make sure to check there next time.
-
@Sebastian-Roth said in Failed to get an IP via DHCP!:
@jes6309 As you can see here this NIC model is supported since kernel version 2.6.x and upwards. So it should not be a driver issue! As well, “Sending discovery…” actually means that we found a network interface and try to get an IP for it via DHCP. So it could be:
- Layer 1 issue like cable (you already checked that)
- Spanning tree issue (make sure you have RSTP or configured “port fast”)
- Auto-negotiation issue (try configuring static speed instead of auto-negotiation for that port)
- Ethernet energy saving (see if your switch has EEE/802.3az feature and disable if possible)
Made a new article for DHCP troubleshooting. This will definitely be a fun article to work on over time!
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_DHCP -
@Wayne-Workman said in Failed to get an IP via DHCP!:
Made a new article for DHCP troubleshooting. This will definitely be a fun article to work on over time!
https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_DHCPWhile I think this is a good idea I am wondering if it will have mostly the same content than the wiki article in my signature which is meant to describe the whole boot process. Possibly we can have all the DHCP related infos in that new article and link it all together in the big one as well.
-
@Sebastian-Roth You’re right. When I made it I was thinking… man we are gonna have stuff spread out everywhere. But, when I look at the other articles that are solely about DHCP there is no troubleshooting, just stuff about setup. I’ll move this stuff into what you’re working on and link this article to that.