DHCP Lease Failing on 1.5.5 after upgrade - again

[totoro]

@Sebastian-Roth & @george1421

During the “udhcp: sending discover” process we don’t see anything:

We make some try with older Kenel, and it’s look we don’t have any problem with the 4.18.3 one, we going to continue to make test and see if it’s solved. They have a way to setup Fog to use a specific kernel by default without erase the last one ?
It’s could help for the last one

Thanks for you help

[Sebastian Roth]

@totoro As well you could try booting in debug mode and setting a static IP and see if you can ping then:

ip addr add 192.168.0.222/24 dev eth0
ping 192.168.0.10

[george1421]

@totoro Well that is disappointing… but now we know its not “time” that solves your issue (you mentioned randomly it works).

What I want you to do next. Take a second computer and load wireshark on it. Plug it into the same subnet/switch as the one in the picture. Use the wireshark capture filter of port 67 and port 68. Start the wireshark capture then issue that same udhcpc command. What I’m hoping to see in the capture is a DISCOVER, OFFER, REQUEST, ACK sequence from dhcp. Since dhcp is actually failing on this computer I’m guessing its failing on one of the steps. If we see the DISCOVER dhcp packet then we know the target computer is alive and on the network. Post the captured pcap here and I will take a look at it in detail.

[totoro]

@george1421

Hi here the following result:

[george1421]

@totoro Sorry I jumped off my focus and back to my questions.

5. At the linux command prompt key in: ip addr show I’m interested in what it lists for eth0.

Your picture shows that eth0 is found. Can we guess that the mac address in your picture matches the actual physical network adapter in this computer? If so then the kernel network driver is fine. Sebastian’s suggestion to use a dumb (unmanaged) switch should have fixed the problem we are thinking of. Will you reboot the computer back into the FOS debug console? I want to try a command from the FOS linux command prompt. /sbin/udhcpc -i eth0 --now

Then wait until the command completes then again run an ip addr show to see if it picks up an IP address. If a network address is assigned then I want you to run this command ping 192.168.0.10 (which should be your fog server’s IP address). Make sure you get a response.

[totoro]

@Sebastian-Roth ; No is note make a difference, it’s really strange, like I say we direclty connect client to fog server with a switch with the same result. And some time it’s working and some time not, without logique.

For the osid=0, I think it’s because we registrate de client, without making image and start it in debug mod by a fog task.

[Sebastian Roth]

@totoro Ok, just to confirm. This NIC is supported in the Linux kernel since a very long time. As well we definitely have had the driver in our kernels builds since August 2016.

Can you please grab a mini switch and connect that between your notebook and the main network and boot again? Does that make a difference?

While this is not causing the issue I still wonder why you have “osid=0”??? That shouldn’t be. Please check your image defintion of “TESTACER” as well!

[totoro]

Hi,

Here the following result:

I look on the HO G4 and G5 it the same ethernet controler.

Thank’s for helping.

[Sebastian Roth]

@george1421 As posted, using case insensitive grep should work fine: lspci -nn|grep -i net

[george1421]

@Sebastian-Roth FWIW it looks like we need some kind of regex expression to catch both cases.

$ lspci -nn|grep net
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)

$ lspci -nn|grep etwork
00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
02:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0082] (rev 34)

[Sebastian Roth]

@george1421 said in DHCP Lease Failing on 1.5.5 after upgrade - again:

lspci -nn|grep etwork

Please run lspci -nn|grep -i net…

To me it looks like the ethernet card is properly loaded and UP. Looks like the driver is not properly sending or receiving packets. We need to know the exact model of the card. Please run the above command and we’ll see.

[totoro]

Hi thank’s for your answer,

Here the following result:

[george1421]

@totoro OK what I want you to do here is this:

1. Manually register this target computer with FOG
2. Schedule a capture/deploy (don’t care) but before you hit the schedule button, check the debug check box, then schedule the task .
3. PXE boot the target computer.
4. After a few enter key presses, you should be dropped to a linux command prompt on the target computer.
5. At the linux command prompt key in: ip addr show I’m interested in what it lists for eth0. Just post a screen shot of that output.
6. I’m also interested in the output from this command: lspci -nn|grep etwork

Based on the output of those two commands we’ll decide the next steps.

[totoro]

Hi again,

Same problem with a fresh install on 1.5.5

Regards