[SOLVED] Wapttftpserver under debian

[cedric_974]

Hello,

I'm writing because I'm having a problem with TFTP on a secondary repository under Debian.
I installed the repository in a directory I'll call /XXXX, and I can correctly locate the /XXXX/wads/pxe directory and the ipxe.efi file.
The machine doesn't have a firewall, only ClamAV antivirus.
I should mention that DHCP isn't configured at this point, but I just wanted to test TFTP.
Currently in version 2.6.0.17392, I can launch the systemctl status wapttftpserver service without any problem:

#################################
systemctl status wapttftpserver:

● wapttftpserver.service - WAPT/WADS TFTP Server startup script
Loaded: loaded (/usr/lib/systemd/system/wapttftpserver.service; enabled; preset: enabled)
Active: active (running) since Thu 2025-10-30 08:22:22 +04; 2 weeks 0 days ago
Invocation: af16754aa4234cae821ca58ec17760f1
Main PID: 841 (wapttftpserver.)
Tasks: 2 (limit: 9455)
Memory: 3.8M (peak: 4.6M)
CPU: 14min 16.331s
CGroup: /system.slice/wapttftpserver.service
└─841 /opt/wapt/wapttftpserver.bin --fork --username=root --root_dir=/XXXX/wads/pxe --verbose --log-path=/dev/stdout

Oct 30 08:22:22 XX-XX-XXXXXXX-X systemd[1]: Starting wapttftpserver.service - WAPT/WADS TFTP Server startup script...
Oct 30 08:22:22 XX-XX-XXXXXXX-X systemd[1]: Started wapttftpserver.service - WAPT/WADS TFTP Server startup script.
#################################


I tried this command found in the documentation from another Debian system:
###################################
cd ~
tftp XX-XX-XXXXXXX-X.mydomain.lan
binary
get ipxe.efi
quit
ls -l ipxe.efi
###############################

Right after the get ipxe.efi command, I get an error:
##########################
Error code 1: File not found
##########################

I then tried an nmap command from another Debian system:
#################################
nmap -Pn 192.168.1.2 -sU -p 69
###################################

I get this response:
###################################
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-13 09:14 +04
Nmap scan report for XX-XX-XXXXXXX-X.mydomain.lan (192.168.1.2)
Host is up.

PORT STATE SERVICE
69/udp open|filtered tftp

Nmap done: 1 IP address (1 host up) scanned in 2.21 seconds
######################################

The port is "open|filtered".

I decided to test nmap to our old TFTP server which is on Windows to see the reaction:
##########################
nmap -Pn 192.168.1.3 -sU -p 69
##########################

I get this response:
######################################
Starting Nmap 7.95 ( https://nmap.org ) at 2025-11-13 09:13 +04
Nmap scan report for XX-XX-XXXXXXX-X.mydomain.lan (192.168.1.3)
Host is up (0.0048s latency).

PORT STATE SERVICE
69/udp open tftp

Nmap done: 1 IP address (1 host up) scanned in 0.22 seconds
####################################

The port is now "open".

When trying to retrieve a file from the Windows TFTP server, I get an Error code 4: Access violation. This means I have a response (negative, but a response nonetheless...).

I hope I've been clear enough, but I don't understand this "open|filtered" concept, nor why I can't retrieve ipxe.efi.
Is there a configuration file for the wapttftpserver?

Thank you for your help.

Best regards

[sfonteneau]

Hello,

we should first check if the ipxe.efi file is present in the folder: /XXXX/wads/pxe

Simon

[cedric_974]

Hello,

Thank you for your reply.

root@XX-XX-XXXXXXX-X:/# cd /XXXX/wads/pxe/
root@XX-XX-XXXXXXX-X:/XXXX/wads/pxe# ls
Boot EFI ipxe.efi snponly.efi sources undionly.kpxe

Yes, I confirm that it is present, and below are the permissions.

50355110 1020 -rw-r--r-- 1 root www-data 1042944 Sep 2 18:05 ipxe.efi

Thank you for your help.

[sfonteneau]

Can you try this:

but on the repo itself with 127.0.0.1:

Code: Select all

cd ~
tftp 127.0.0.1
binary
get ipxe.efi
quit
ls -l ipxe.efi

[cedric_974]

It works at 127.0.0.1 and also with the repository's IP address.

In the meantime, I reinstalled another Debian system to eliminate all possibilities and ran another remote test, and it works there too.
So, I think the problem must have been with the machine I'd been using to test my remote TFTP from the beginning...

Thank you for your help and sorry for wasting your time.

Thanks again.