TFTP server not listening on port defined

m4rtin · 06-17-2014, 04:26 AM

I started a tftp server with "atftpd -v --port 69 --bind-address 10.10.10.2 --daemon /srv/tftp/" command, but for some reason I do not see TFTP server listening on port 69 in ss/netstat output. However, if I connect to a TFTP server with TFTP client, I'm able to transfer files and automatically another instance of TFTP server starts(PID 5191):

Code:

# ss -l -4 -u
Recv-Q Send-Q                                 Local Address:Port                                     Peer Address:Port   
# ss -l -6 -u
Recv-Q Send-Q                                 Local Address:Port                                     Peer Address:Port   
# pgrep -lf tftp
4316 /usr/sbin/atftpd -v --port 69 --bind-address 10.10.10.2 --daemon /srv/tftp/
5191 in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp
#

in.tftpd is a symbolic link to /usr/sbin/atftpd. How are clients able to connect to TFTP server if the TFTP server is not listening on UDP port 69? Are there other servers which work in a same manner?

MensaWater · 06-17-2014, 07:50 AM

udp is "stateless" so would does not have a "LISTEN" state.

To see your udp ports run "ss -a -u".

For network troubleshooting I prefer to use lsof which is available on many platforms including Linux:
lsof -i |grep -i udp

You can get a lot more detail about networking from it and also about many other open files (lsof = list open files).

m4rtin · 07-03-2014, 04:08 AM

Quote:

Originally Posted by MensaWater

udp is "stateless" so would does not have a "LISTEN" state.

To see your udp ports run "ss -a -u".

For network troubleshooting I prefer to use lsof which is available on many platforms including Linux:
lsof -i |grep -i udp

You can get a lot more detail about networking from it and also about many other open files (lsof = list open files).

I see. So none of the servers using UDP protocol like TFTP, DHCP, NTP and others can not be seen with "ss -l -u" because they are stateless? In addition, looks like if atftpd is started without "--daemon" then it uses inetd process for listening incoming UDP requests and then inetd will launch the atftpd process. In my example the "5191 in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp" shown in my previous post. Is this a common practice to use inetd for listening (multiple) servers? From troubleshooting point of view it's bit more clear if inetd is not used as one can have a clear overview which processes with corresponding arguments are running.

MensaWater · 07-03-2014, 09:59 AM

inetd/xinetd was introduced long ago because some services do NOT need to be running all the time. They only need to be run on request. For such services inetd/xinetd simply "LISTEN" for anything requesting that port then they launch the program that actually relies on that port.

Some services are in use all the time or so frequently or take long enough to launch that it makes sense to run them as standalone utilities rather than via inetd/xinetd. (e.g. sshd usually runs as a standalone daemon.)

You can enable standalone daemons for most things as a choice (of course you'd disable them in inetd/xinetd if already enabled there). However, if you were only making 1 tftp connection to this server every day that lasted for an hour it means you're wasting resources for the other 23 hours of the day. All by themselves individual services may not take up that much but since inetd/xinetd can be and is used to configure many different services the cumulative resource saving of not running them all 24 hours a day is well worth using inetd/xinetd.