Package: atftpd
Version: 0.7-11
Severity: minor
atftpd, when running at its default verbosity, logs a request for a
file, but fails to log an error if the requested file does not exist.
On a client machine:
% tftp -i mythtv.vl.com GET bogus
Error on server : File not found
The relevant bit logged by atftpd:
Mar 29 22:13:12 mythtv in.tftpd[25732]: connect from 192.168.0.200
(192.168.0.200)
Mar 29 22:13:12 mythtv atftpd[25732]: Advanced Trivial FTP server
started (0.7)
Mar 29 22:13:12 mythtv atftpd[25732]: Serving bogus to 192.168.0.200:1214
Mar 29 22:18:12 mythtv atftpd[25732]: atftpd terminating after 300 seconds
Mar 29 22:18:12 mythtv atftpd[25732]: Main thread exiting
I discovered that increasing the verbosity level:
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --verbose=7
/var/lib/tftpboot
does cause atftpd to log an error:
Mar 29 22:21:22 mythtv in.tftpd[26001]: connect from 192.168.0.200
(192.168.0.200)
Mar 29 22:21:22 mythtv atftpd[26001]: Advanced Trivial FTP server
started (0.7)
Mar 29 22:21:22 mythtv atftpd[26001]: started by inetd
Mar 29 22:21:22 mythtv atftpd[26001]: logging level: 7
Mar 29 22:21:22 mythtv atftpd[26001]: directory: /var/lib/tftpboot/
...
Mar 29 22:21:22 mythtv atftpd[26001]: Creating new socket:
192.168.0.203:32831
Mar 29 22:21:22 mythtv atftpd[26001]: Serving bogus to 192.168.0.200:1317
Mar 29 22:21:22 mythtv atftpd[26001]: File /var/lib/tftpboot/bogus not found
Mar 29 22:21:22 mythtv atftpd[26001]: Server thread exiting
In my opinion, such an error should be logged at the default verbosity
level. Ideally, every "Serving..." messages should have a complement
message indicating the success or failure of that transfer operation,
inclusive of network problems. (Currently network problems are logged like:
atftpd[8354]: timeout: retrying...
atftpd[8354]: recvmsg: Connection refused
atftpd[8354]: tftpd_file.c: 926: recvfrom: Connection refused
atftpd[14717]: tftpd_file.c: 931: abnormal return value 7
in a manner that is somewhat detached from the specific transfer
operation taking place, and it isn't clear from the logs whether the
transfer succeeded in the end (as a result of retries) or failed.)
It may be of no relevance, but it seems tftpd suffers from a similar
problem, as reported in bug 416722.
-Tom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
