TFTP ARP Timeout
-
image url)This is the data he gave me to use LMAO
-
Do you think subnet mask could be the issue?
-
user@fog:~$ ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s25: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 18:03:73:cf:ab:5a brd ff:ff:ff:ff:ff:ff inet 10.1.80.1/16 brd 10.1.255.255 scope global noprefixroute enp0s25 valid_lft forever preferred_lft forever inet6 fe80::7298:8d49:d303:484d/64 scope link noprefixroute valid_lft forever preferred_lft foreverthere we go
-
Still ARP timeout. now the DHCP IP is 10.1.0.3 before it was 10.1.0.2
-
@cammykool Do you have 2 dhcp servers on your network? I might guess one is 10.1.0.3 and the other is 10.1.0.2??
If we can’t get it I have a tutorial that will allow the fog server to capture the pxe booting process. Once captured we can look at it and tell a bit more about why the arp timeout. https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue
-
@george1421 no just DHCP on 10.1.0.1
DNS is 2 and 3
-
@cammykool OK lets follow the tutorial I posted. Upload the pcap to a file share site and post the link here. I’ll take a look at it. Once we are done you can remove the file from the file share site.
-
-
@cammykool OK let me look
-
@george1421 Thanks man. I appreciate it.
-
@cammykool OK if you have wireshark go ahead and open the pcap so I can show you.
Lets switch over to FOG IM so turnaround is quicker. I have a few questions.
-
@george1421 After looking through the pcap(s) we found that the OP had 2 dhcp servers and both were still pointing to the old imaging solution. The OP was setting the fog server dhcp options at the global level, but there was a scope level override that was still pointing to the old imaging solution. Once the OP found the scope level setting and corrected it then the client was able to pxe boot.
The second issue was the FOG server’s subnet mask was incorrectly set in regards to the rest of the OPs network. We discovered the correct subnet mask, updated the fog server and then rebooted. Upon reboot the fog server showed the correct subnet mask.
The OP confirmed this issue can be marked Solved.
-
So one of our deplyed machines is UEFI PXE only. What is the process for configuring that separate to this?
-
@cammykool Follow setting up your windows dhcp server as Sebastian first posted: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Using_Windows_Server_2012_.28R1_and_later.29_DHCP_Policy
Following those instructions, the windows dhcp server will send out the right boot file name based on the target computer (the same way as I told you the pxe booting computer in the pcap was bios based).
-
@george1421 when i had looked previosly it didnt show me the option for EFi PXE like his guide showed. Just regular PXE.
-
@cammykool That wiki page is accurate, you want to create the filters for PXEClient:Arch:00009 and PXEClient:Arch:00007 surely because that is both uefi types. The others are optional. Any device that doesn’t match the filter will take the default which you currently have configured as undionly.kpxe. Just remember that the policies are created on the scope where you want the dynamic dhcp boot.
In my environment I use this method to pxe boot both uefi and bios systems without having to touch the dhcp server.
-
pointed it all to ipxe.efi and get that as a return followed article to a T
-
@cammykool Well I would grab another pcap to make sure things are as they should be. Its suspicious that it lists the server address as 10.1.0.3. Its a bit ambiguous as to what server?? dhcp server, pxe boot server, what?
The file size 0 bytes means that the file doesn’t exist or it can’t reach the tftp server.
-
@george1421 ill run and IM you that pcap
-
This post is deleted!
