ubuntu下tftp文件,Retry count exceeded; starting again问题

在Ubuntu虚拟机中,作者遇到了tftp传输时出现'Retry count exceeded; starting again'的问题。经过检查和尝试,发现问题源于新的虚拟机配置与旧配置的不同。尽管IP设置、服务安装等都相同,但tftp服务始终无法通过xinetd启动,只运行了in.tftpd。最终,通过改变Windows和Ubuntu的IP地址,使它们不一致,成功解决了问题。问题可能与standalone模式有关,此模式可能不允许同一IP的多个实例。
部署运行你感兴趣的模型镜像

就这么个简单的问题曾经困扰我两天,现在解决了,回想起来气得跺脚!


一,之前有个虚拟机ubuntu虚拟机,下载tftp忒正常,环境配置如下:

1,windows IP设置为uboot的serverip---192.168.1.100

        2,VM设置为静态网桥,接主机物理网卡

        3,ubuntu设置auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1

      4,install tftp-hpa tftpd-hpa xinetd

      5,touch tftp如网上说述


二,后来因为项目的原因,觉得这个虚拟机才分了15GB(VM推荐值真TMD烂),太小了不够用,于是重新装了个虚拟机大空间的,环境配置如下:

1,windows IP设置为uboot的serverip---192.168.1.100

        2,VM设置为静态网桥,接主机物理网卡

        3,ubuntu设置auto eth0
iface eth0 inet static
address 192.168.1.100
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.1

      4,install tftp-hpa tftpd-hpa xinetd

      5,配置/etc/default/tftp-hpa,如网上所述


     OK,确发现总是Retry count exceeded; starting again!后来我输入命令netstat -lnput一查看,发现xinetd没有起来,只有in.tftpd,我以为xinetd没有安装正确,于是乎卸载了重装,我靠,现象还是一样。

     再后来我在google上看了很多帖子之后才发现,TMD安装的是standalone模式,安装网上的办法消除stantalone模式,输入了两天命令,发现完全不起作用,重启后输入命令netstat -lnput一查看依然是in.tftpd。

      这下我是没有招了,思维进入了死胡同,配置和之前ubuntu环境一言,standalone模式就是不行,而且就是改变不了standalone模式,我有点死心了。


      过了两天,我得再面对这个问题,要不然编一个内核还要拷贝到之前的环境下载,这是猪干的事情!今天,也不知怎么就想到改IP了,我认为windowsIP和UbuntuIP可以不一样吧,把windowsIP改成非serverip,UbuntuIP为serverip,通了!!!相当高兴


       我猜测原因就是这个Standalone引起的,tftp在这个shiloh下仅仅允许一个实例,如果两个操作系统的都是同一个IP的话,对于xinetd(之前UBUNTU环境)来说没啥问题,但是对于Standalone来说tftp是服务于Windows的,又要服务于开发板的?

  

您可能感兴趣的与本文相关的镜像

Llama Factory

Llama Factory

模型微调
LLama-Factory

LLaMA Factory 是一个简单易用且高效的大型语言模型(Large Language Model)训练与微调平台。通过 LLaMA Factory,可以在无需编写任何代码的前提下,在本地完成上百种预训练模型的微调

<think>好的,用户现在遇到了TFTP传输失败的问题,错误信息是“Retry count exceeded; starting again”。之前已经尝试过设置网络参数、调整内存地址和超时时间,但问题依旧。现在需要进一步分析可能的原因和解决方案。 首先,用户已经确认网络层是通的,因为ping成功了。这说明基本的网络连接没问题,但TFTP传输仍然失败。可能的问题可能出在传输层或服务器端配置上。比如,TFTP服务器可能没有正确响应请求,或者文件路径、权限有问题。另外,内存地址可能冲突,或者传输的数据包过大导致超时。 接下来要考虑的是U-Boot的配置。用户之前调整过tftp_timeout,但可能需要进一步优化。另外,TFTP的块大小(blocksize)和窗口大小(window_size)可能影响传输效率,特别是在网络状况不佳的情况下。需要建议用户调整这些参数。 另外,服务器端的防火墙设置也可能阻止了TFTP的数据传输端口(通常是UDP 69以外的端口)。需要检查服务器防火墙是否允许相关端口通信。此外,TFTP服务器的配置是否正确,比如文件是否存在于指定目录,文件名是否正确,权限是否开放。 内存地址方面,用户之前尝试过0x2000000和0x42000000,但可能需要进一步确认目标地址是否被其他程序占用,或者是否符合设备的内存映射要求。可以建议用户使用内存测试命令检查该区域是否可写。 另外,可能需要检查U-Boot的网卡驱动是否正常工作,是否有丢包现象。使用mii命令查看网卡寄存器状态,确认物理层连接稳定。 最后,如果所有方法都无效,可以考虑使用替代传输方式,比如NFS或串口传输,作为临时解决方案。 总结下来,可能的解决步骤包括:检查服务器配置和文件权限,调整U-Boot的TFTP参数,验证内存地址可用性,检查防火墙设置,以及尝试替代传输协议。同时,通过日志和调试命令进一步诊断问题根源。</think>根据当前现象,这是典型的TFTP重传机制异常,以下是系统性排查方案: ```bash # 网络深度诊断 nvt> mii dump # 检查PHY状态寄存器 nvt> setenv ethact eth0@2,f01b0000 # 显式指定网卡 nvt> tftp 0x42000000 S385DPS-4_1.0.isp_config # 服务器端验证 nvt> dhcp nvt> nfs 0x42000000 ${serverip}:/tftpboot/S385DPS-4_1.0.isp_config ``` **关键问题定位**: 1. **TFTP协议交互异常**:RRQ请求未收到ACK(需抓包验证) 2. **内存屏障问题**:0x2000000地址可能被MMU映射为只读 3. **网卡DMA配置**:f01b0000网卡的缓冲区对齐问题 4. **服务器防火墙限制**:UDP 69端口以外的数据通道被拦截 **紧急处理方案**: ```bash # 强制协议降级 nvt> setenv tftp_blocksize 512 # 使用传统块大小 nvt> setenv tftp_timeout 30000 # 进一步延长超时 # 内存保护检查 nvt> mmuoff # 关闭MMU进行测试 nvt> tftp 0x42000000 S385DPS-4_1.0.isp_config ```
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值