Tftpd Server S Not Responding

Home » General » Tftpd Server S Not Responding
General 14 Comments

I have a TFTPd server S running on CentOS 7 and managed by systemd

It is not respoding to A server which is sending the TFTP read request RRQ.

I do see the RRQ packets coming from A to S, but S never responds back from a different port Y to A

So this part is working fine

https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#/media/File:Tftp-rrq.svg

But I do not see any attempts to even send a data packet back in my packet capture running on S

So this event is not occuring, as if my TFTPd server is dead. I have the firewalld turned off on S to eliminate the possibility that firewalld blocking those packets from reeaching to tftpd daemon. I also turned off selinux to eliminate any permission issue.

https://en.wikipedia.org/wiki/Trivial_File_Transfer_Protocol#/media/File:Tftp-dat1-dwn.svg

I do have TFTPd running and managed by systemd

$ systemctl status -l TFTP
● TFTP.service – TFTP Server
Loaded: loaded (/etc/systemd/system/tftp.service; indirect; vendor preset: disabled)
Active: active (running) since Wed 2018-03-28 18:57:42 UTC; 1min 44s ago
Docs: man:in.tftpd Main PID: 1685 (in.tftpd)
Memory: 136.0K
CGroup: /system.slice/tftp.service
└─1685 /usr/sbin/in.tftpd –verbose –verbosity 10 –secure
/tftpboot –port-range 4069:4169

Mar 28 18:57:42 S.example.net systemd[1]: Started TFTP Server. Mar 28 18:57:42 S.example.net systemd[1]: Starting TFTP Server…

Any help is appreciated!

—
Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

14 thoughts on - Tftpd Server S Not Responding

  • Are A and S on different IP subnets?
    Does S have a second IP on the SAME subnet as A?
    Any ASA or other firewalls between the two?
    If so this is expected behavior.

  • Yes

    No

    Firewall is set to any any between the two. Also internal firewall is down Firewall is not seeing any return pkts

    I was hoping S will at least try to reply to the RRQ pkt with a DATA pkt I do not see S is even bothering to try.

    A(x) —- RRQ —> S(69) and then I am expecting this S(y) — DAT 1 –>
    A(x)

  • BTW, If I reverse the role and have S try to send a TFTP read request, A
    reply back right away and I do the see the file.

  • A STATEFUL firewall with “ip any any” can and will still block asymmetric communications due to the firewall keeping track of state (hence tha name stateful firewall).

    Tcpdump on your servers /other/ NICs and you’ll see the TFTP traffic leaving your server on some other NIC (probably on with the default route).

    The upstream firewall will then block the TFTP response if it never saw the tftp request (due to asymmetry).

  • A (192.168.1.10)
    S (192.168.1.20)

    I do not see TFTP traffic is leaving from S

    A:~$ TFTP
    (to) 192.168.1.20
    tftp> get file Transfer timed out.

    As you can see no pkt is leaving. If it were leaving S, but A were not receiving then I would think firewall is dropping it.

    [ S ~]$ sudo tcpdump -A -nniany host 192.168.1.10
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144
    bytes

    16:40:08.390939 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ “file”
    netascii E..,J1@.>..n./…oAt…E..#…file.netascii……………….
    16:40:13.391133 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ “file”
    netascii E..,N.@.>…./…oAt…E..#…file.netascii……………….
    16:40:18.391220 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ “file”
    netascii E..,QK@.>..T./…oAt…E..#…file.netascii……………….
    16:40:23.391373 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ “file”
    netascii E..,T^@.>..@./…oAt…E..#…file.netascii……………….
    16:40:28.391469 IP 192.168.1.10.35553 > 192.168.1.20.69: 16 RRQ “file”
    netascii E..,X.@.>…./…oAt…E..#…file.netascii……………….

    —
    Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

  • Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

  • Most likely the firewall on the system running your TFTP client is blocking the traffic from the TFTP server. The easiest way to test would be to put in a rule that allows all packets from the server (or to at least log them so you can see what’s happening). The firewall issue is most likely *not* with the TFTP server.

  • Reading back through prior emails. . . TFTP client requests packets *are*
    making it to the TFTP server. So it seems like something on the TFTP server itself.

    Like previously mentioned server side firewall/iptables/tcp-wrappers/selinux are all possible culprits.

    Hmmm just thought of something else, what are the file permissions of the file you are requesting? Try `chmod a+r filename`?

  • granted

    —
    Asif Iqbal PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

  • Right. I am not sure how to debug that

    I tested with firewalld turned off and selinux all permissive. I also did not see any denied in audit log related to this when selinux was enforced

    Yes it is readable.

  • Just reading back through the thread, I’m still not sure, but does the server have multiple ethernet interfaces? If so, can you turn off the others temporarily?

    Is it possible that IPv6 is getting in the way?

    If you do

    lsof -i :69

    what do you get?

    What about all the directories above the file – are they readable and searchable?

    P.

  • Have you checked the *client* firewall? TFTP responses to client requests are blocked by the default firewall, due to the nature of the TFTP protocol.

  • Early in this thread you mentioned these are on different network subnets.
    . .

    Just thought about a similar issue. . .
    sysctl -a | grep rp_filter

    If a packet comes in to Linux and the path BACK to the remote IP is NOT out that same interface (asymmetric routing) the Linux kernel will drop the packet. “rp_filter” controls how Linux behaves regarding this.

    Please provide real `ifconfig` and `route -rn` and `tcpdump port 69` output to properly diagnose. . .