TFTP port is closed is it normal?

[symrex]

Ok i have something.
I tested right now connection between Proxmox Host xxx.yyy.zzz.116 and Proxmox Guest FOG xxx.yyy.zzz.120
tftp file transfer is working fine without any issues.

But the strange thing is that Windows 10 pc with tftp can connect to the FOG tftp service but can’t download the file successfully. First 512 bytes are working but the acknowledgement from windows client is missing. Thats why the same data is send from FOG everytime.

Maybe the client from windows isn’t working properly?

[george1421]

@symrex On the windows side you need to drop the firewall because tftp works much like ftp in that there is a command channel from the remote to the server and then a data channel from the server back to the remote. Both links are needed to get the file.

[george1421]

@symrex said in TFTP port is closed is it normal?:

I tested right now connection between Proxmox Host xxx.yyy.zzz.116 and Proxmox Guest FOG xxx.yyy.zzz.120
tftp file transfer is working fine without any issues

So this has tested and ruled out the FOG server as not functioning with tftp. Because you are able to connect using the built in vSwitch on the hypervisor but its not reaching outside of the hypervisor?

[symrex]

@george1421 Yeap looks like that.
But this .pcap is from the perspective of Windows client.

Client is sending information about name, size, type
Server is responding right: tsize, blksize, timeout

But client will not responde to this information.
While I was using the win10 tftp client, I look with wireshark on his actions.

And firewall is a good idea but; the bios legacy PXE have no firewall so there should be no restrictions.
Sadly that i can’t check with wireshark while the pc is booting PXE

[Sebastian Roth]

@symrex said in TFTP port is closed is it normal?:

Sadly that i can’t check with wireshark while the pc is booting PXE

You actually can if you know how to configure a monitoring/mirroring port on your switch.

[george1421]

(some of this info is derived from a chat dialog I had with the OP)

@symrex I was thinking about this a bit, since you can TFTP on the VM host server, what would happen if you spun up a new VM on the VM host server and tried to pxe boot into the fog iPXE menu. This would test if the FOG server was operational, then all you would need to focus on is why is it communicating off the VM Host server to the network. The next step is getting a test computer connected to the same network switch as the VM Host server. The connection has to be failing at some point in the booting process. We just need to find out where its working and then when it first stops.

[EZY4]

Hi,
I also encounter a TFTP problem with a fresh installation of FOG 1.5.8.

System: Debian 10

When starting PXE on the client machine, it asks me to enter the IP of the TFTP server, but that does not change anything.

I have 3 DHCP on my network, but the 3 broadcast the 66, 67 from my fog server.

Were you able to solve your problem?

[symrex]

@Sebastian-Roth said in TFTP port is closed is it normal?:

@symrex said in TFTP port is closed is it normal?:

Sadly that i can’t check with wireshark while the pc is booting PXE

You actually can if you know how to configure a monitoring/mirroring port on your switch.

Restricted area for me, have no physical access to those.
But you got a good point…

@george1421 said in TFTP port is closed is it normal?:
what would happen if you spun up a new VM on the VM host server and tried to pxe boot into the fog iPXE menu

Great idea… lets test it.
HEUREKA: DHCP was sending to much information… to be specific:

Next-Server: xxx.xxx.xxx.xxx
Bootfile: undionly.kpxe
Option 66: yyy.yyy.yyy.yyy
Option 67: boot\x86\wdsnbp.com

Since I don’t have access to the DHCP server, someone else set up a DHCP server (I gave him my required configuration), and these additional options(66/67) came from an early configuration(someone else). After their deletion, pxe is working flawlessly.
The Dell BIOS PXE interface doesn’t give me any feedback in this regard, but wireshark and vbox and with your help I was able to find out where the problem was. It looks like option 66/67 will be prioritized when it is set.

Thank you for your help!

[george1421]

@symrex said in TFTP port is closed is it normal?:

Next-Server: xxx.xxx.xxx.xxx
Bootfile: undionly.kpxe
Option 66: yyy.yyy.yyy.yyy
Option 67: boot\x86\wdsnbp.com

It looks like someone setup a Windows Deployment server/SCCM server.

Just for clarity the next server and dhcp option need to be the same (exactly) the same goes for boot file and option 67.

The first part is in the ethernet header, that is for bootp the dhcp options are for dhcp. Some clients use bootp some use dhcp so they both need to be set correctly.

[symrex]

@EZY4 I think we both have different problems.
I would suggest that you open a new thread on this.

As a tip: Install VirtualBox + ExtensionPack and set up the network boot only.
VirtualBox has iPXE, which gives you more information.

Furthermore you can use wireshark to check what exactly your machine receives from the dhcp-server.

@george1421 Good to know. Thanks for the information and help!