Ubuntu小白指南：轻松解决TFTP传输难题，让ARM开发板不再卡顿

为什么你的TFTP传输总失败？ARM开发板文件传输避坑指南（实测Ubuntu 22.04）

每次在ARM开发板上调试，最让人头疼的往往不是代码逻辑，而是文件传不过去。你明明照着教程一步步配置了TFTP服务器， tftpd-hpa 也重启了，可板子那边就是卡在 TIMEOUT 或者 ACCESS VIOLATION 。那种感觉，就像你对着一个上了锁的保险箱，钥匙孔都对不上。这篇文章，就是帮你找到那把对的钥匙，或者至少告诉你，锁到底卡在哪里了。

我经历过太多次这种挫败，尤其是在Ubuntu 22.04 LTS这个看似稳定，实则在一些细节上有所变化的系统上。网上很多教程是基于旧版本，直接套用过来，坑就埋下了。今天我们不谈基础搭建，那个你已经会了。我们聚焦于那些让你传输失败的“幽灵”问题，通过几个我亲自踩过、也帮别人解决过的真实案例，把权限、路径、防火墙、服务状态这些高频“杀手”一个个揪出来。目标很明确：让你下次再遇到 Transfer timed out 时，能有一套清晰的排查思路，而不是盲目地重启服务。

1. 权限与路径：最隐蔽的“访问拒绝”

你以为配置了 TFTP_DIRECTORY 就万事大吉？很多时候，问题就出在这个目录本身，以及守护进程“看待”这个目录的方式上。

1.1 目录权限的“三重门”

TFTP服务运行时的用户身份是关键。在Ubuntu 22.04上，默认的 tftpd-hpa 服务是以 tftp 用户（或你在配置中指定的用户，如 root ）运行的。这意味着，你的TFTP根目录及其所有父目录，都必须对这个运行用户 可读 （对于下载）和 可写 （对于上传）。

一个典型的错误是，用户在 /home/username/tftp 下创建了目录，却忽略了 /home/username 这个父目录的权限。如果 /home/username 的权限是 750 （即，仅所有者可读、写、执行，同组用户可读和执行），而运行TFTP服务的用户（如 tftp ）既不是所有者，也不在所属组内，那么它连进入 /home/username 的权限都没有，更别提访问子目录了。

排查与修复步骤：

1. 确认TFTP服务运行用户 ：

   sudo cat /etc/default/tftpd-hpa | grep TFTP_USERNAME
   

   通常输出是 TFTP_USERNAME="tftp" 。

2. 检查整个路径链的权限 ： 假设你的TFTP目录是 /home/alex/develop/tftp_share 。

   # 从根目录开始，逐级检查权限
   ls -ld /home
   ls -ld /home/alex
   ls -ld /home/alex/develop
   ls -ld /home/alex/develop/tftp_share
   

   你需要确保 tftp 用户（或其所属的组）对每一级目录都有执行( x )权限。对于 tftp_share 目录本身，还需要读( r )和写( w )权限。

3. 一键修正权限（谨慎操作） ： 一个相对安全的方法是，将TFTP目录的组所有权改为 tftp 用户所在的组（通常是 tftp ），并赋予组权限。同时，确保所有父目录对“其他用户”(others)至少有执行权限。

   # 将TFTP目录及其内容的所有组改为tftp组
   sudo chgrp -R tftp /home/alex/develop/tftp_share
   # 赋予组读写执行权限
   sudo chmod -R g+rwx /home/alex/develop/tftp_share
   # 确保父目录对其他用户有执行权限（如果之前没有）
   sudo chmod o+x /home/alex /home/alex/develop
   

   注意：直接使用 chmod 777 是最简单粗暴的，但会带来严重的安全风险，不建议在生产环境或任何有网络暴露风险的机器上使用。

1.2 符号链接的“陷阱”

有时为了管理方便，我们会将TFTP目录设置为一个符号链接（Symlink）。例如， /var/lib/tftpboot 链接到 /srv/tftp 。在Ubuntu 22.04的 tftpd-hpa 中，如果使用了 -s （安全）选项， 默认情况下它会跟随符号链接 。但这并不意味着没有风险。

问题在于，符号链接指向的实际路径，其权限也必须对TFTP服务运行用户开放。而且，如果 tftpd-hpa 的配置中包含了 --secure （ -s 选项的完整形式）且没有额外允许符号链接的选项，某些旧版本或特定配置下可能会拒绝访问。

案例 ：用户配置 TFTP_DIRECTORY="/tftp" ，而 /tftp 是一个指向 /mnt/data/tftp 的符号链接。 /mnt/data 的挂载选项或权限设置不当，导致 tftp 用户无法访问，传输失败。

解决方案 ：

• 直接使用实际路径作为 TFTP_DIRECTORY ，避免使用符号链接。
• 如果必须使用，请确保链接目标和所有相关父目录的权限正确。
• 检查 tftpd-hpa 的启动参数（ TFTP_OPTIONS ），确认其对符号链接的处理方式。

2. 服务配置与状态：你以为它在跑，其实它睡了

服务没启动、配置未生效、或者多个服务冲突，是另一大类问题根源。

2.1 tftpd-hpa vs xinetd ：管理之争

在Ubuntu的历史上，TFTP服务可以通过两种方式运行：由 xinetd （扩展的互联网服务守护进程）管理，或者作为独立的 tftpd-hpa 守护进程。 在Ubuntu 22.04及近期的版本中，官方推荐并默认使用独立的 tftpd-hpa 服务 。但很多老教程会同时教你配置两者，极易造成混淆和端口冲突。

冲突表现 ：你重启了 tftpd-hpa ，但传输依然失败。用 netstat 查看，发现69端口没有被任何进程监听，或者被 xinetd 占用了。

排查方法：

1. 检查69端口监听情况 ：

   sudo netstat -tulnp | grep :69
   

   如果输出显示监听进程是 xinetd ，说明 xinetd 管理的TFTP在运行。如果显示是 in.tftpd 或 tftpd ，则是独立服务。如果什么都没有，说明服务没起来。

2. 确定你的管理方式 ：

   • 如果你按照 /etc/default/tftpd-hpa 配置，并使用 sudo systemctl status tftpd-hpa 管理，那么你应该 禁用 xinetd 中的TFTP服务 。
   • 编辑 /etc/xinetd.d/tftp 文件，将 disable = no 改为 disable = yes ，然后重启 xinetd 。

   sudo systemctl disable tftp  # 如果存在tftp的systemd服务（通常由xinetd安装包创建）
   sudo systemctl stop xinetd   # 或者直接停止xinetd，如果你不用它管理其他服务
   sudo systemctl restart tftpd-hpa
   

3. 验证独立服务配置 ： 确保 /etc/default/tftpd-hpa 中的 TFTP_OPTIONS 包含了 -c （允许创建文件/上传）和 -s （指定根目录）。一个典型的配置如下：

   TFTP_USERNAME="tftp"
   TFTP_DIRECTORY="/srv/tftp"
   TFTP_ADDRESS=":69"
   TFTP_OPTIONS="--secure --create"
   

   --secure 即 -s ， --create 即 -c 。

2.2 配置更改未生效

修改了配置文件后，仅仅保存是不够的。必须 重启服务 才能使更改生效。这是一个低级但常见的疏忽。

正确操作流程：

# 1. 编辑配置文件
sudo vim /etc/default/tftpd-hpa
# 2. 重新加载systemd的守护进程配置（有时需要）
sudo systemctl daemon-reload
# 3. 重启服务
sudo systemctl restart tftpd-hpa
# 4. 检查服务状态和日志
sudo systemctl status tftpd-hpa
sudo journalctl -u tftpd-hpa -f  # 查看实时日志，在尝试传输时观察

如果状态显示 active (running) ，但日志里有错误信息（如权限错误、目录不存在），就需要根据日志进一步排查。

3. 网络与防火墙：无形的墙

服务在本机跑得好好的，但来自开发板的请求就是到不了。问题往往出在网络层面。

3.1 Ubuntu 22.04 内置防火墙 ( ufw )

Ubuntu默认安装了 ufw （Uncomplicated Firewall），但默认是 禁用 状态。然而，有些用户或脚本可能会启用它，却忘了为TFTP的UDP 69端口放行。

检查与设置：

# 查看ufw状态
sudo ufw status
# 如果状态是 active，则需要添加规则
sudo ufw allow 69/udp
# 或者，如果你希望只允许特定开发板IP（更安全）
sudo ufw allow from 192.168.1.100 to any port 69 proto udp
# 添加规则后，最好重新加载或检查状态
sudo ufw reload
sudo ufw status numbered  # 查看带编号的规则列表

3.2 复杂网络环境：路由与多网卡

你的开发板和Ubuntu主机是否在 同一个子网 ？这是TFTP这种简单协议能正常工作的基本前提。

常见场景 ：

• 虚拟机网络配置 ：Ubuntu运行在VMware或VirtualBox中，网络模式设置为“NAT”。此时虚拟机与宿主机不在同一局域网，开发板无法直接访问虚拟机的IP。需要将网络模式改为“桥接”(Bridged)，使虚拟机获得一个与开发板同网段的IP。
• 主机多网卡 ：你的PC既有有线网卡（连接开发板），又有无线网卡（连接互联网）。TFTP服务可能默认绑定在了无线网卡的IP或 0.0.0.0 上。虽然绑定 0.0.0.0 通常可行，但在某些复杂路由下，回包可能走错接口。
• IP地址错误 ：这是最直白但也最容易犯的错。在开发板上执行 tftp 命令时，指定的服务器IP必须是Ubuntu主机在与开发板相连的那个网络接口上的IP。

诊断命令：

# 在Ubuntu上查看IP地址，确认与开发板连接的网卡
ip addr show
# 例如， eth0 的 inet 是 192.168.1.50
# 在开发板上，尝试ping这个IP，确认链路层连通性
ping 192.168.1.50
# 在Ubuntu上，使用tcpdump监听69端口，看是否能收到开发板的请求
sudo tcpdump -i eth0 -n udp port 69

如果 ping 不通，检查网线、交换机、IP配置。如果 ping 通但 tcpdump 抓不到TFTP请求包，可能是开发板上的 tftp 命令参数有误，或者Ubuntu主机有防火墙拦截。

4. 客户端（ARM开发板）侧的常见坑

服务器端配置无误，问题也可能出在客户端——也就是你的ARM开发板上。

4.1 U-Boot 与 Linux 系统下的 tftp 命令差异

这是两个完全不同的环境：

• U-Boot ：通常使用 tftp 命令将文件（如内核镜像 zImage 、设备树 dtb ）下载到内存指定地址（如 0x80008000 ），然后启动。命令格式如 tftp ${loadaddr} ${serverip}:${filename} 。这里的 ${serverip} 需要提前设置好。
• Linux系统 ：进入Linux系统后，可能会使用 busybox 提供的 tftp 客户端，或者单独安装的 tftp-hpa 客户端。命令格式通常是 tftp -g -r filename server-ip （下载）或 tftp -p -l filename server-ip （上传）。

关键点 ：

1. IP地址设置 ：在U-Boot中，必须正确设置 serverip （TFTP服务器IP）和 ipaddr （开发板自身IP）环境变量。
2. 文件路径 ：在Linux系统的 tftp 命令中， -r 后面的 filename 是相对于服务器TFTP根目录的路径。而在U-Boot中，路径通常直接是文件名，位于TFTP根目录下。
3. 传输大小限制 ：U-Boot的TFTP客户端可能有默认的块大小( blksize )或窗口大小( windowsize )限制，传输大文件时容易失败。可以尝试在U-Boot中设置 setenv tftpblocksize 1460 或 setenv tftpwindowsize 1 来调整。

4.2 开发板网络初始化不完全

有时，开发板虽然获取了IP地址（通过DHCP或静态设置），但路由表或DNS（无关TFTP但可能影响其他操作）未正确配置。确保开发板能 ping 通服务器，并且路由正确（对于简单直连，默认路由指向服务器或同一网段即可）。

5. 高级调试与工具使用

当常规排查无效时，需要更深入的调试手段。

5.1 使用 tcpdump 进行网络抓包分析

这是定位网络层问题的终极武器。它告诉你数据包到底有没有到达服务器，以及服务器的回应是什么。

在Ubuntu服务器上执行：

# 监听特定网卡(如eth0)上的UDP 69端口流量，并详细显示
sudo tcpdump -i eth0 -vvv -X 'udp port 69'

然后从开发板发起一次TFTP传输。观察 tcpdump 的输出：

• 能看到来自开发板IP的 Read Request (RRQ) 包吗？ 如果没有，问题在客户端或网络链路。
• 服务器回复了 Error (5): Access violation 吗？ 这指向权限或路径问题。
• 服务器回复了 Data 包吗？ 如果有，但客户端没收到，可能是网络丢包或客户端问题。
• 只有请求，没有回应？ 可能是服务器防火墙拦截，或者TFTP服务根本没在69端口监听。

5.2 在服务器端使用 tftp 客户端进行本地测试

这可以排除网络问题，直接测试服务器配置是否正确。

# 连接到本机TFTP服务器
tftp localhost
tftp> get existing_file.txt  # 尝试下载一个确定存在于TFTP目录的文件
tftp> put local_file.txt     # 尝试上传一个文件
tftp> quit

如果本地测试成功，但开发板不行，问题大概率在网络上（防火墙、路由、IP地址）。如果本地测试也失败，那就100%是服务器配置问题。

5.3 检查 SELinux/AppArmor（Ubuntu较少见，但需知晓）

Ubuntu默认使用AppArmor。虽然 tftpd-hpa 通常有对应的配置文件，但异常配置可能导致其被限制。查看安全日志：

sudo dmesg | grep -i apparmor | grep tftp
sudo journalctl | grep -i apparmor | grep tftp

如果看到拒绝信息，可能需要调整AppArmor策略或将其置于投诉模式。

6. 实战案例汇编与快速排查流程图

最后，我们把这些散点串联起来，形成肌肉记忆。下面这个表格总结了六个典型故障现象及其最可能的根源和首要排查点，你可以把它当作速查手册。

遇到问题，不要慌。我的习惯是，先做一次 本地回环测试 （ tftp localhost ），这能立刻把问题范围缩小到“服务器配置”还是“网络/客户端”。如果本地通，就拿着 tcpdump 去守株待兔，看数据包卡在哪一环。如果本地不通，那就从服务状态、配置文件、目录权限这个铁三角里按顺序查。记住， systemctl status 和 journalctl 是你的好朋友，它们给出的错误信息往往直接指向答案。