TFTP ARP Timeout

[george1421]

Understand that fixing the subnet mask may not address the pxe booting problem, but it will fix ARP resolution. The subnet mask controls where the broadcast address is. Two different subnet masks have their broadcast address in different locations so the two clients will have difficulty finding each other.

[cammykool]

@george1421 it looked to be /8 too before

pxe is still getting 255.255.0.0 at boot

[george1421]

@cammykool So you updated the network manager application and then either did the ifup/ifdown or reboot and its still set to /8?

The pxe stuff is coming from your dhcp server not the fog server. Your client is still having a problem finding the fog server from your first picture.

[cammykool]

yes it is. Netowkr manager has always been correct.

[cammykool]

im working on the guide i was sent initially. boss gave me direct access to the DHCP server

[george1421]

@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.

[cammykool]

@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

[george1421]

@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.

[cammykool]

image url)

This is the data he gave me to use LMAO

[cammykool]

Do you think subnet mask could be the issue?

[cammykool]

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

[cammykool]

Still ARP timeout. now the DHCP IP is 10.1.0.3 before it was 10.1.0.2

[george1421]

@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

[cammykool]

@george1421 no just DHCP on 10.1.0.1

DNS is 2 and 3

[george1421]

@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]

@george1421

https://drive.google.com/open?id=1j0MRC88x-0h-5iLnocLhEgvdKHj8CWgB

[george1421]

@cammykool OK let me look

[cammykool]

@george1421 Thanks man. I appreciate it.

[george1421]

@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]

@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.