@andreiv I played a bit with that but have not come up with a proper solution yet. The point where you need the information (before or at login time) we are bound to get the connection speed within the iPXE environment. Although it can do lots of things I have not found any hint on it being able to display the connection speed.

Altough I know iPXE is capable of doing auto-negotiation on most network cards it’s interesting it doesn’t seem to provide this information to the outside world.

What I came across is the driver speed test: http://ipxe.org/dev/drvtest/speed
Possibly we could include that to measure download speed beforehand. Not great but maybe better than nothing.

Can you please go ahead and do a bit of testing in your environment. For that go to the FOG web UI -> FOG Configuration -> iPXE Menu Item Settings -> fog.multijoin: here the Parameters section starts like this:

login
params
param mac0 ${net0/mac}
...

Now edit that and make it read:

shell
login
params
param mac0 ${net0/mac}
...

Now when you boot up a client and select Multicast from the menu you will be dropped to the iPXE shell. Here you can test all the various iPXE commands and especially see what you can get out of the driver speed test things: time imgfetch ${boot-url}/service/ipxe/init.xz ; imgfree (takes around 1.4 to 1.6 seconds in my VM environment - see if you can get a clear difference in your setup between 10 MBit/s and 100 MBit/s links)

@fhrivers said in TFTP Open Timeout on New Fog Install:

Very strange. I even rebooted after the change for good measure.

Which change did you do exactly?? Disabled the firewall as suggested? I am not talking about the Windows firewall here!

Make sure firewall rules are gone after the disabled:

iptables -L -n -v
Chain INPUT (policy ACCEPT 70204 packets, 115M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 22073 packets, 26M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 64101 packets, 8327K bytes)
 pkts bytes target     prot opt in     out     source               destination         

All three default chains are empty and default policy set to ACCEPT.

@fhrivers Please try the following: iptables -L -n -v | grep "dpt:69"

Now you see the first number in that line. That’s how often this rules has been used so far. In the output you posted this was 26 times and that means the initial TFTP connection is going through. But that is not enough. Find the output of a network packet capture below. You see first DHCP handshake (four packets) and then TFTP:

19:42:57.319383 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:ab:0f:cc, length 548
19:42:58.327617 IP 192.168.2.7.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
19:42:59.340794 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 08:00:27:ab:0f:cc, length 548
19:42:59.355690 IP 192.168.2.7.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
19:42:59.358575 IP 192.168.2.10.2070 > 192.168.2.7.69:  31 RRQ "undionly.kkpxe" octet tsize 0
19:42:59.378177 IP 192.168.2.7.32788 > 192.168.2.10.2070: UDP, length 14
19:42:59.378538 IP 192.168.2.10.2070 > 192.168.2.7.32788: UDP, length 17
19:42:59.379556 IP 192.168.2.10.2071 > 192.168.2.7.69:  36 RRQ "undionly.kkpxe" octet blksize 1456
19:42:59.381209 IP 192.168.2.7.60001 > 192.168.2.10.2071: UDP, length 15
19:42:59.381310 IP 192.168.2.10.2071 > 192.168.2.7.60001: UDP, length 4
19:42:59.381392 IP 192.168.2.7.60001 > 192.168.2.10.2071: UDP, length 1460
19:42:59.381717 IP 192.168.2.10.2071 > 192.168.2.7.60001: UDP, length 4
19:42:59.382154 IP 192.168.2.7.60001 > 192.168.2.10.2071: UDP, length 1460
19:42:59.382273 IP 192.168.2.10.2071 > 192.168.2.7.60001: UDP, length 4
...

While the first TFTP packet goes to UDP port 69 for the actual transfer of the file random high ports are being used. This is where your clients timeout I am fairly sure!

For now I would suggest you disable the firewall on your FOG server to see if I am on the right track. If that works then you might start reading more about Linux firewalling and how to enable it the way to still be able to use FOG. Just a hint on that: FOG uses NFS and FTP beside TFTP, which all use random ports. Therefore we usually tend to leave the firewall disabled anyway.

As well you might want to take a look at SELinux, as it can cause issues as well: https://linuxize.com/post/how-to-disable-selinux-on-centos-7/

@Samuel1010 said in Hostname on imaged clients not changing:

Module is disabled on the host

Have you checked the host’s settings in the FOG web UI?

@fhrivers Run iptables -L -n -v to see if the local firewall on the Linux system is enabled. Take a picture and post here.

@jcabuco Run du -h --max-depth=1 /images to get an idea of how much space each image uses.

In case you really know what you are doing you can also delete those that you really don’t need anymore from the disk: rm -rf /images/nameofimage Be aware that there is no recovery as soon as you hit ENTER on the remove command!

@Bullet Please keep us posted if the issue is coming up again.

@EricLA2K Thanks heaps for keeping us posted. I am fairly sure this will help other users as well!!

@fhrivers Take a look at this wiki article:
https://wiki.fogproject.org/wiki/index.php?title=CentOS_7#Continue_pre-config

As well I am wondering how you setup the networking of the VirtualBox VM. Best if you can take a picture of the network settings in VirtualBox and post here.

@dpusser_CMS Yes, ich can understand that it seems a little over the top to build your very own kernel just having started to use Linux. Bu hey, I think it’s never to early to get your fingers dirty and this is not very hard to do with all the things provided. There is not much you can mess up so I’d encourage you to just give it a go and simply ask if you think something is not going the right way. Just take a picture of the screen with an error or whatever and we’ll guide you the rest of the way!