TFTP ARP Timeout
-
im working on the guide i was sent initially. boss gave me direct access to the DHCP server
-
@cammykool said in TFTP ARP Timeout:
yes it is. Netowkr manager has always been correct.
Ok I think I’m lost here (not surprised since I jumped in late). The subnet mask of /16 255.255.0.0 is coming from your windows dhcp server. That has to be the right subnet mask for your network. Why is the FOG server set to /8 255.0.0.0?
What is the correct subnet mask for your computers? You can open a command windows on your dhcp server and key in
ipconfig /all
to confirm your subnet mask. The fog server needs to have the same subnetmask as your windows servers. -
@george1421 huh my windows box is getting 255.255.0.0 too. He gave me the 255.0.0.0 to use. Ill Change it
-
@cammykool said in TFTP ARP Timeout:
He gave me the 255.0.0.0 to use
Hmm sounds like someone is being setup for failure right out of the box.
-
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 forever
there 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.