@sebastian-roth

Not to ignore you, but when I came in this morning, me and my boss had a conversation. He was messing around with another VM that was also having speed issues. He turned off VMQ under the Hardware Acceleration for the VM’s NIC on Hyper-V. His file transfer speed issue immediately went away. Naturally, I tried this for the FOG VM. When I booted up a machine, PXE boot ran as expected. I never saw the TFTP spinning, and both bzimage and init loaded instantly. However, I turned VMQ back on and tried again and the speed issue was still gone, so I don’t know if this was a problematic setting or not.

If the speed issue comes back, I will go ahead and do the tcpdump, unless you’d like me to do it now anyways just for sake of gaining info. FOG is running on the latest Ubuntu Server OS.

@Wayne-Workman This fixed my original issue as well. Thanks for the help!

@Wayne-Workman I had to look up where to put the script in the first place, and was instructed to use SetupComplete.cmd; that is what worked for me.

@george1421 Don’t spend too much time on it if at all since it’s working now. I’d love to know why it wasn’t working, but I assume those packet captures aren’t going to show jack since they weren’t captured during the issue’s occurrence.

@george1421 Here you go. Taken from my computer on VLAN 3, attempting a pxe boot on the computer that was having an issue. Though like I said, it seems to be working fine now.

0_1541174066153_vlan3computer.pcap

The computer in question is 10.32.10.118, DHCP server is 10.32.0.224, and the fog server is 10.32.0.31.

@george1421 No, it was a TCPdump from the fog server.

@george1421 I would love to send you a pcap of the issue, but it’s no longer happening. I’ve tested several work stations a couple dozen times. They’ve all been fine.

So the VLAN 3 pcap was not enough to see what was going wrong?

@george1421 I don’t know how it couldn’t be sending the option out properly. If I have them set globally and every subnet works besides one of them, I don’t know what it could be. Unless someone happened to plug in a DHCP server enabled device to that subnet, but there doesn’t appear to be any evidence of that anywhere.

I’m sure this isn’t fog, but I’m still at a loss.

@george1421 Notice in my picture that PXE boot stalls at “Please enter tftp server:” where I must enter the fog IP manually. On all the computers on vlan 3 that haven’t been booted up yet, they will stall at this section of the PXE boot. I don’t feel like getting more calls about this.

Around noon, every computer that will be turned on for the day should be turned on, so I’ll turn the options back on and begin testing.

@Sebastian-Roth I’ve opened another thread about it. I ran a program that scans for DHCP traffic because I’m not too familiar with wireshark, but it does the same thing I imagine. After three hours, the only traffic showing up was our one and only DHCP server.

https://forums.fogproject.org/topic/12615/tftp-only-working-with-certain-vlans/2

@george1421 The vlan 3 pcap is the one that doesn’t work. I’ll make another pcap later today. I can’t turn the option 66 and 67 back on right now, as it’ll prevent computers on the network from booting.

@drewklein22 Windows Server 2012 R2. Option 66 and 67 are global, but having them specific to the scopes doesn’t change the result unfortunately.

Fog 1.5.4
Ubuntu 16.04 LTS

We began having issues this morning that prevented computers on a different VLAN than the fog server from finding the TFTP server; it would request us to enter the TFTP server address. Going through a few threads, it seems that this is caused by multiple DHCP servers, but we only have one. Throughout the day, I tested a few more VLANs. It appears that there’s only one VLAN having issues.

I ran sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011 while PXE booting over both VLANs. VLAN 2 (and others) works, VLAN 3 doesn’t. I don’t really know what to be looking for, so I’ll attach the pcaps.

1_1541098906654_vlan3.pcap
0_1541098906651_vlan2.pcap