标签: tftp

一 实验背景 之前一段时间专门研究了固件升级的方法，主要是通过网页或者上位机软件实现远程固件升级。最近正好在研究TFTP简单文件传输协议，于是我就尝试给设备添加联网功能，通过TFTP实现网络更新固件，而后发现这种升级方式所占设备内存小，可以穿越多数***，并且不需要去设备现场，在办公室通过网络就能将成千上万用户或设备的固件升级，简单高效。 其实现在很多设备都已经具有网络固件升级功能，例如我们经常用到的电视机顶盒、家用无线路由器等设备。很多设备升级内核都是通过TFTP协议上传的，因为TFTP实现非常的简单，比如自己家里用的路由器就可以通过TFTP协议升级。 二 TFTP基础普及 TFTP是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，基于UDP协议实现，端口号为69。通过TFTP协议，可以实现网络中两台计算机之间的文件上传与下载，如文件备份，为无盘工作站下载引导文件，下载初始化代码到打印机、集线器和路由器。当然，还有就是我们本次用到的对设备进行固件升级。 TFTP协议是专为小文件传输设计的，提供不复杂、开销不大的文件传输服务，缺乏标准 FTP 协议的许多特征。TFTP 只能从远程服务器上读、写文件（邮件）或者读、写文件传送给远程服务器。它不能列出目录并且当前不提供用户认证。当前 TFTP 有 3 种传输模式： netASCII 模式即 8 位 网络ASCII码 ；octet即八位组模式；邮件模式，这种模式现在已经废止不用了。主机双方也可以自己定义其它模式。 TFTP基于UDP协议实现，而UDP使用IP。因此一个TFTP包中会有如图1所示的以下几段：本地媒介头，IP头，UDP数据报头，TFTP数据报。TFTP在IP头中不指定任何数据，但是它使用UDP中的源和目标端口以及包长度域。由TFTP使用的包标记（TID）在这里被用做端口，因此TID必须介于0到65,535之间。图中显示了5种TFTP报文格式，每个报文格式TFTP报文的头两个字节表示操作码。之后对于不同的报文格式存在差异。 图1 TFTP报文格式 下面分别对每个报文包进行分析： RRQ和WRQ包的报文格式如表1所示。 RRQ/WRQ包 Opcode Filename  0 Mode 0 2 bytes string 1 byte string 1 byte 表1 RRQ和WRQ包的报文格式 RRQ(读请求)报文由客户使用，用来建立一条从服务器读数据的连接。WRQ（写请求）报文由客户使用，用来建立一条把数据写到服务器的连接，它的格式与RRQ相同，RRQ包的操作码为1，WRQ包的操作码为2。Filename（文件名字段）说明客户要读或写的位于服务器上的文件，文件名是NETASCII码字符，以0结束。Mode(模式字段)是一个ASCII码串netascii或octet（大小写可任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR / LF）作为行结束符。 OCTET模式用于传输文件，这种文件在源机上以8位格式存储。在使用MAIL模式时，用户可以在FILE处使用接收人地址，这个地址可以是用户名或用户名@主机的形式，如果是后一种形式，允许主机使用电子邮件传输此文件。如果使用MAIL类型，包必须以WRQ开始，否则它与NETASCII完全一样。 DATA包的报文格式如表2所示。 DATA包 Opcode Block  0 2 bytes 2 bytes Data 表2 DATA包的报文格式 DATA数据包的opcode为3，它还包括有一个数据块号和数据。数据块号域从1开始编码，每个数据块加1，这样接收方可以确定这个包是新数据还是已经接收过的数据。数据域从0字节到512字节。如果数据域是512字节则它不是最后一个包，如果小于512字节则表示这个包是最后一个包。如果最后一个包正好为512字节，则再发送一个0字节的包用于表示结束。 ACK包的报文格式如表3所示。 ACK包 Opcode Block 2 bytes 2 bytes 表3 ACK包的报文格式 ACK包用于确认数据包已收到。ACK包的操作码为4。当接收方收到一个数据包后，会向发送方发送一个ACK包；而发送方则会在收到一个ACK包后继续发送下一个包。若发送完未能收到ACK包，则会使用超时机制，重新发送刚才的数据包。除了ACK和用于中断的包外，其它的包均需得到确认。发出新的数据包等于确认上次的包。WRQ和DATA包由ACK或ERROR数据包确认，而RRQ数据包由DATA或ERROR数据包确认。 ERROR包的报文格式如表4所示。 继续阅读：http://www.iwiznet.cn/blog/?p=7512    

一 实验背景 之前一段时间专门研究了固件升级的方法，主要是通过网页或者上位机软件实现远程固件升级。最近正好在研究TFTP简单文件传输协议，于是我就尝试给设备添加联网功能，通过TFTP实现网络更新固件，而后发现这种升级方式所占设备内存小，可以穿越多数***，并且不需要去设备现场，在办公室通过网络就能将成千上万用户或设备的固件升级，简单高效。 其实现在很多设备都已经具有网络固件升级功能，例如我们经常用到的电视机顶盒、家用无线路由器等设备。很多设备升级内核都是通过TFTP协议上传的，因为TFTP实现非常的简单，比如自己家里用的路由器就可以通过TFTP协议升级。 二 TFTP基础普及 TFTP是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，基于UDP协议实现，端口号为69。通过TFTP协议，可以实现网络中两台计算机之间的文件上传与下载，如文件备份，为无盘工作站下载引导文件，下载初始化代码到打印机、集线器和路由器。当然，还有就是我们本次用到的对设备进行固件升级。 TFTP协议是专为小文件传输设计的，提供不复杂、开销不大的文件传输服务，缺乏标准 FTP 协议的许多特征。TFTP 只能从远程服务器上读、写文件（邮件）或者读、写文件传送给远程服务器。它不能列出目录并且当前不提供用户认证。当前 TFTP 有 3 种传输模式： netASCII 模式即 8 位 网络ASCII码 ；octet即八位组模式；邮件模式，这种模式现在已经废止不用了。主机双方也可以自己定义其它模式。 TFTP基于UDP协议实现，而UDP使用IP。因此一个TFTP包中会有如图1所示的以下几段：本地媒介头，IP头，UDP数据报头，TFTP数据报。TFTP在IP头中不指定任何数据，但是它使用UDP中的源和目标端口以及包长度域。由TFTP使用的包标记（TID）在这里被用做端口，因此TID必须介于0到65,535之间。图中显示了5种TFTP报文格式，每个报文格式TFTP报文的头两个字节表示操作码。之后对于不同的报文格式存在差异。 图1 TFTP报文格式 下面分别对每个报文包进行分析： RRQ和WRQ包的报文格式如表1所示。 RRQ/WRQ包 Opcode Filename  0 Mode 0 2 bytes string 1 byte string 1 byte 表1 RRQ和WRQ包的报文格式 RRQ(读请求)报文由客户使用，用来建立一条从服务器读数据的连接。WRQ（写请求）报文由客户使用，用来建立一条把数据写到服务器的连接，它的格式与RRQ相同，RRQ包的操作码为1，WRQ包的操作码为2。Filename（文件名字段）说明客户要读或写的位于服务器上的文件，文件名是NETASCII码字符，以0结束。Mode(模式字段)是一个ASCII码串netascii或octet（大小写可任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR / LF）作为行结束符。 OCTET模式用于传输文件，这种文件在源机上以8位格式存储。在使用MAIL模式时，用户可以在FILE处使用接收人地址，这个地址可以是用户名或用户名@主机的形式，如果是后一种形式，允许主机使用电子邮件传输此文件。如果使用MAIL类型，包必须以WRQ开始，否则它与NETASCII完全一样。 DATA包的报文格式如表2所示。 DATA包 Opcode Block  0 2 bytes 2 bytes Data 表2 DATA包的报文格式 DATA数据包的opcode为3，它还包括有一个数据块号和数据。数据块号域从1开始编码，每个数据块加1，这样接收方可以确定这个包是新数据还是已经接收过的数据。数据域从0字节到512字节。如果数据域是512字节则它不是最后一个包，如果小于512字节则表示这个包是最后一个包。如果最后一个包正好为512字节，则再发送一个0字节的包用于表示结束。 ACK包的报文格式如表3所示。 ACK包 Opcode Block 2 bytes 2 bytes 表3 ACK包的报文格式 ACK包用于确认数据包已收到。ACK包的操作码为4。当接收方收到一个数据包后，会向发送方发送一个ACK包；而发送方则会在收到一个ACK包后继续发送下一个包。若发送完未能收到ACK包，则会使用超时机制，重新发送刚才的数据包。除了ACK和用于中断的包外，其它的包均需得到确认。发出新的数据包等于确认上次的包。WRQ和DATA包由ACK或ERROR数据包确认，而RRQ数据包由DATA或ERROR数据包确认。 ERROR包的报文格式如表4所示。  ERROR包 Opcode ErrorCode ErrMsg 0 2 bytes 2 bytes string 1 byte 表4 ERROR包的报文格式 一个ERROR包的操作码是5。此包可以被其它任何类型的包确认,错误码指定错误的类型。它用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。差错编号字段给出一个数字的差错码，跟着是一个ASCII表示的差错报文字段，可能包含额外的操作系统说明的信息。错误的值和错误的意义如下： 0 未定义，请参阅错误信息 1．文件未找到 2．访问非法 3．磁盘满或超过分配的配额 4．非法的TFTP操作 5．未知的传输ID 6．文件已经存在 7．没有类似的用户 三 TFTP嵌入式系统实现方法 TFTP 协议执行过程中，任何一个传输进程都以WRQ（请求写入远程系统）或RRQ（请求读取远程系统）开始，收到一个确定应答并建立一个连接。创建连接时，通信双方随机选择一个TID，因为是随机选择的，因此两次选择同一个ID的可能性就很小了。每个包包括两个TID，发送者ID和接收者ID。这些ID用于在UDP通信时选择端口，在第一次请求的时候它会将请求发到TID 69，也就是服务器的69端口上。应答时，服务器使用一个选择好的TID作为源TID，并用上一个包中的TID作为目的ID进行发送。这两个被选择的ID在随后的通信中会被一直使用。 连接成功以后文件就以固定的 512 字节块的长度进行传送。每个数据包都包含一个数据块，块号从1开始而且是连续的。因此对于写入请求的确定是一个比较特殊的情况，因此它的包的包号是0。在发送下一个包之前，数据块必须得到确认响应包的确认。如果一个数据包的大小小于512字节，则表明传输结束。如果包在网络中丢失，接收端就会在超时以后重新传输最后一个未被确认的数据包（可能是数据也可能是确认响应），这就导致丢失包的发送者重新发送丢失包。通信的双方都是数据的发出者与接收者，一方传输数据接收应答，另一方发出应答接收数据。发送者需要保留一个包在手头用于重新发送，由 LOCK 确认响应保证所有过去的包都已经收到。大部分的错误会导致连接中断，错误由一个错误的数据包引起。这个包不会被确认，也不会被重新发送，因此另一方无法接收到。如果错误包丢失，则使用超时机制。错误主要是由下面三种情况引起的：不能满足请求，收到的数据包内容错误(不能由延时或重发解释)，对需要资源的访问丢失（如硬盘满）。TFTP只在一种情况下不中断连接，这种情况是源端口不正确，在这种情况下，指示错误的包会被发送到源机。这个协议限制很多，这都是为了实现起来比较方便而进行的。 TFTP的工作过程很像停止等待协议，发送完一个文件块后就等待对方的确认，确认时应指明所确认的块号。发送完数据后在规定时间内收不到确认就要重发数据PDU（协议数据单元），发送确认PDU的一方若在规定时间内收不到下一个文件块，也要重发确认PDU。这样保证文件的传送不致因某一个数据报的丢失而告失败。通过下边的图片来了解TFTP协议的通信流程： 图2 TFTP通信流程 四  测试TFTP客户端 了解了TFTP协议之后，下面就让我们通过WIZnet W5500EVB做一个嵌入式TFTP客户端的简单实验。 1.实验目的：建立一个TFTP客户端 2.硬件环境：板载LED灯   图3  W5500EVB实物板 3.开发工具: MDK5（版本不一样，需要稍加改动） 4.测试软件：串口调试助手， TFTP32（可从网络下载） 下面以W5500为TFTP客户端，讲述如何测试实现TFTP通信过程。 1. 在网上下载Tftp32软件，不需安装直接点击Tftpd32软件就可以应用。 继续阅读：http://www.iwiznet.cn/blog/?p=7512

一 实验背景 之前一段时间专门研究了固件升级的方法，主要是通过网页或者上位机软件实现远程固件升级。最近正好在研究TFTP简单文件传输协议，于是我就尝试给设备添加联网功能，通过TFTP实现网络更新固件，而后发现这种升级方式所占设备内存小，可以穿越多数***，并且不需要去设备现场，在办公室通过网络就能将成千上万用户或设备的固件升级，简单高效。 其实现在很多设备都已经具有网络固件升级功能，例如我们经常用到的电视机顶盒、家用无线路由器等设备。很多设备升级内核都是通过TFTP协议上传的，因为TFTP实现非常的简单，比如自己家里用的路由器就可以通过TFTP协议升级。 二 TFTP基础普及 TFTP是TCP/IP协议族中的一个用来在客户机与服务器之间进行简单文件传输的协议，基于UDP协议实现，端口号为69。通过TFTP协议，可以实现网络中两台计算机之间的文件上传与下载，如文件备份，为无盘工作站下载引导文件，下载初始化代码到打印机、集线器和路由器。当然，还有就是我们本次用到的对设备进行固件升级。 TFTP协议是专为小文件传输设计的，提供不复杂、开销不大的文件传输服务，缺乏标准 FTP 协议的许多特征。TFTP 只能从远程服务器上读、写文件（邮件）或者读、写文件传送给远程服务器。它不能列出目录并且当前不提供用户认证。当前 TFTP 有 3 种传输模式： netASCII 模式即 8 位 网络ASCII码 ；octet即八位组模式；邮件模式，这种模式现在已经废止不用了。主机双方也可以自己定义其它模式。 TFTP基于UDP协议实现，而UDP使用IP。因此一个TFTP包中会有如图1所示的以下几段：本地媒介头，IP头，UDP数据报头，TFTP数据报。TFTP在IP头中不指定任何数据，但是它使用UDP中的源和目标端口以及包长度域。由TFTP使用的包标记（TID）在这里被用做端口，因此TID必须介于0到65,535之间。图中显示了5种TFTP报文格式，每个报文格式TFTP报文的头两个字节表示操作码。之后对于不同的报文格式存在差异。 图1 TFTP报文格式 下面分别对每个报文包进行分析： RRQ和WRQ包的报文格式如表1所示。 RRQ/WRQ包 Opcode Filename  0 Mode 0 2 bytes string 1 byte string 1 byte 表1 RRQ和WRQ包的报文格式 RRQ(读请求)报文由客户使用，用来建立一条从服务器读数据的连接。WRQ（写请求）报文由客户使用，用来建立一条把数据写到服务器的连接，它的格式与RRQ相同，RRQ包的操作码为1，WRQ包的操作码为2。Filename（文件名字段）说明客户要读或写的位于服务器上的文件，文件名是NETASCII码字符，以0结束。Mode(模式字段)是一个ASCII码串netascii或octet（大小写可任意组合），同样以0字节结束。netascii表示数据是以成行的ASCII码字符组成，以两个字节—回车字符后跟换行字符（称为CR / LF）作为行结束符。 OCTET模式用于传输文件，这种文件在源机上以8位格式存储。在使用MAIL模式时，用户可以在FILE处使用接收人地址，这个地址可以是用户名或用户名@主机的形式，如果是后一种形式，允许主机使用电子邮件传输此文件。如果使用MAIL类型，包必须以WRQ开始，否则它与NETASCII完全一样。 DATA包的报文格式如表2所示。 DATA包 Opcode Block  0 2 bytes 2 bytes Data 表2 DATA包的报文格式 DATA数据包的opcode为3，它还包括有一个数据块号和数据。数据块号域从1开始编码，每个数据块加1，这样接收方可以确定这个包是新数据还是已经接收过的数据。数据域从0字节到512字节。如果数据域是512字节则它不是最后一个包，如果小于512字节则表示这个包是最后一个包。如果最后一个包正好为512字节，则再发送一个0字节的包用于表示结束。 ACK包的报文格式如表3所示。 ACK包 Opcode Block 2 bytes 2 bytes 表3 ACK包的报文格式 ACK包用于确认数据包已收到。ACK包的操作码为4。当接收方收到一个数据包后，会向发送方发送一个ACK包；而发送方则会在收到一个ACK包后继续发送下一个包。若发送完未能收到ACK包，则会使用超时机制，重新发送刚才的数据包。除了ACK和用于中断的包外，其它的包均需得到确认。发出新的数据包等于确认上次的包。WRQ和DATA包由ACK或ERROR数据包确认，而RRQ数据包由DATA或ERROR数据包确认。 ERROR包的报文格式如表4所示。  ERROR包 Opcode ErrorCode ErrMsg 0 2 bytes 2 bytes string 1 byte 表4 ERROR包的报文格式 一个ERROR包的操作码是5。此包可以被其它任何类型的包确认,错误码指定错误的类型。它用于服务器不能处理读请求或写请求的情况。在文件传输过程中的读和写差错也会导致传送这种报文，接着停止传输。差错编号字段给出一个数字的差错码，跟着是一个ASCII表示的差错报文字段，可能包含额外的操作系统说明的信息。错误的值和错误的意义如下： 0 未定义，请参阅错误信息 1．文件未找到 2．访问非法 3．磁盘满或超过分配的配额 4．非法的TFTP操作 5．未知的传输ID 6．文件已经存在 7．没有类似的用户 三 TFTP嵌入式系统实现方法 TFTP 协议执行过程中，任何一个传输进程都以WRQ（请求写入远程系统）或RRQ（请求读取远程系统）开始，收到一个确定应答并建立一个连接。创建连接时，通信双方随机选择一个TID，因为是随机选择的，因此两次选择同一个ID的可能性就很小了。每个包包括两个TID，发送者ID和接收者ID。这些ID用于在UDP通信时选择端口，在第一次请求的时候它会将请求发到TID 69，也就是服务器的69端口上。应答时，服务器使用一个选择好的TID作为源TID，并用上一个包中的TID作为目的ID进行发送。这两个被选择的ID在随后的通信中会被一直使用。 连接成功以后文件就以固定的 512 字节块的长度进行传送。每个数据包都包含一个数据块，块号从1开始而且是连续的。因此对于写入请求的确定是一个比较特殊的情况，因此它的包的包号是0。在发送下一个包之前，数据块必须得到确认响应包的确认。如果一个数据包的大小小于512字节，则表明传输结束。如果包在网络中丢失，接收端就会在超时以后重新传输最后一个未被确认的数据包（可能是数据也可能是确认响应），这就导致丢失包的发送者重新发送丢失包。通信的双方都是数据的发出者与接收者，一方传输数据接收应答，另一方发出应答接收数据。发送者需要保留一个包在手头用于重新发送，由 LOCK 确认响应保证所有过去的包都已经收到。大部分的错误会导致连接中断，错误由一个错误的数据包引起。这个包不会被确认，也不会被重新发送，因此另一方无法接收到。如果错误包丢失，则使用超时机制。错误主要是由下面三种情况引起的：不能满足请求，收到的数据包内容错误(不能由延时或重发解释)，对需要资源的访问丢失（如硬盘满）。TFTP只在一种情况下不中断连接，这种情况是源端口不正确，在这种情况下，指示错误的包会被发送到源机。这个协议限制很多，这都是为了实现起来比较方便而进行的。 TFTP的工作过程很像停止等待协议，发送完一个文件块后就等待对方的确认，确认时应指明所确认的块号。发送完数据后在规定时间内收不到确认就要重发数据PDU（协议数据单元），发送确认PDU的一方若在规定时间内收不到下一个文件块，也要重发确认PDU。这样保证文件的传送不致因某一个数据报的丢失而告失败。通过下边的图片来了解TFTP协议的通信流程： 图2 TFTP通信流程 四  测试TFTP客户端 了解了TFTP协议之后，下面就让我们通过WIZnet W5500EVB做一个嵌入式TFTP客户端的简单实验。 1.实验目的：建立一个TFTP客户端 2.硬件环境：板载LED灯   图3  W5500EVB实物板 3.开发工具: MDK5（版本不一样，需要稍加改动） 4.测试软件：串口调试助手， TFTP32（可从网络下载） 下面以W5500为TFTP客户端，讲述如何测试实现TFTP通信过程。 1. 在网上下载Tftp32软件，不需安装直接点击Tftpd32软件就可以应用。 继续阅读：http://www.iwiznet.cn/blog/?p=7512

调试Linux Kernel的时候，如果是每次都使用SD卡拷贝新uImage，很明显不如直接使用串口或网口传输来的方便。使用串口kermit传输的速度有点慢，所以我使用了minicom+tftp的方式。 第一步：安装tftp yum install tftp 第二步：修改/etc/xinetd.d service tftp {         socket_type             = dgram         protocol                = udp         wait                    = yes         user                    = root         server                  = /usr/sbin/in.tftpd         server_args             = -s /tftp_root -c         per_source              = 11         cps                     = 100 2         flags                   = IPv4         disable                 = no } -s制定chroot目录，-c意思是可以创建文件。这个目录一定要直接在根目录下。 第三步：启动tftp服务 service xinetd start 如果要永久启动的话，就执行： systemctl start xinetd.service 第四步：修改防火墙设置 在runtime和perminent里面加入69号端口，同时开启tftp和tftp-cllient服务。 第五步：修改selinx setsebool -P tftp_anon_write on setsebool -P tftp_home_dir on 到这里，tftp就设置好了。 第六步：在U-Boot的命令提示符下输入： U-Boot# set ipaddr 192.168.1.133                                                 U-Boot# set serverip 192.168.1.132 第七步：执行tftp命令 U-Boot# tftp 0x82000000 uImage U-Boot# tftp 0x83000000 maria_am335x.dtb 最后，启动内核既可： U-Boot# bootm 0x82000000 - 0x83000000 速度比串口快得不是一点点哦～～～

TFTP 在调试中的应用 经过前面的步骤，已经打通了宿主机与 Zynq 客户机之间的 TFTP 数据通道，下面就可以利用这个通道进行应用程序的调试了。 在 RHEL6.3 宿主机端进入 /tftpboot 目录，编写一个简单的应用程序， cd /tftpboot vi hello.c hello.c 内容如下： #include stdio.h void main() {   printf("Hello world\n");   printf("Hello Zynq\n"); }   编辑 .bashrc 文件， vi ~/.bashrc 加入别名 xgcc ，用来快速调用 arm-xilinx-linux-gnueabi-gcc 编译器 编辑完成后，重新 source 生效 source ~/.bashrc alias | grep xgcc   编译 hello.c ，确认生成 a.out 文件 xgcc hello.c ls 有宿主机直接行 a.out ，可以发现是不行的，因为这个程序是为 Zynq 编译的，当然不能在 X86 上运行，   在 Zynq 端用 TFTP 登陆，下载 a.out ， tftp –gr a.out 192.168.1.50 /a.out 发现还是无法直接执行的，加上运行权限，再试， chmod +x a.out /a.out