TFTP port is closed is it normal?
-
@george1421 said in TFTP port is closed is it normal?:
First did you disable the ubuntu firewall on the FOG host server?
Debian 10.3
Proxmox Global iptables disabled
checked with pinging… after disabling, ICMP request comes through.Second, install the tftpclient role on a windows 10 computer. Drop the windows 10 firewall, then key in to a cmd window tftp <fog_server_ip> GET undionly.kpxe . We only need to test to see if the file downloads, if yes then go to Third.
There’s the problem. It tries to download it, but does not get any confirmation. That’s why it only tries the first 512 bytes again and again from the beginning.
Verbindungsanforderung fehlgeschlagen. (Connection request failed.)Every “Data Packet” have the same content.
Third, ensure you know what device is pxe booting. The undionly.kpxe boot loader is only for bios based computers. The uefi boot loader is ipxe.efi. You can’t mix boot loaders and hardware.
Yep, BIOS Legacy is right.
-
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?
-
@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.
-
@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 issuesSo 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?
-
@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, timeoutBut 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
-
@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.
-
(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.
-
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?
-
@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 menuGreat 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.comSince 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!
-
@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.comIt 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.
-
@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!
