基于TFTP协议的远程升级设计

说明：因为CSDN博客编辑器对word格式近乎不支持。因此对表格使用了图片方式（最后一个表格未使用图片格式。大家能够看看效果），CSDN博客编辑器上传图片十分不人性化（直接复制图片是不显示的），因此本文省略了不是太重要的图片，包含TFTP协议举例9幅图片（能够使用抓包工具抓包分析）和測试的10幅图片。

1.简单介绍

         在基础网络建设已趋于完好的今天，使用以太网进行传输数据有着众多优势。不仅传输速度快、传输距离远、传输通道更安全，并且以太网具有一系列标准协议，能够与众多的配套设备互联。能够免费使用众多的软件。

         因为网络基础建设的完好，如今越来越多远程測控设备接入了互联网。管理这些分散的远程设备也越来越被人们所重视。当中之中的一个就是设备的程序更新。因此，这里讨论一种利用以太网为数据通道，使用硬件平台提供的在应用编程（IAP）技术进行远程升级的实现方法。

TFTP协议为通用协议，上位机端有众多的免费TFTPclient/server能够使用，但小型嵌入式平台一般不具备文件系统，因此在设备端须要自己来实现TFTPclient或server。本文以NXP公司的lpc1778为例，实现具有下面特性的TFTPserver：

• 支持标准TFTP(RFC1350)
• 支持扩展TFTP(RFC2347)
• 支持读、写请求
• 支持octet模式（二进制模式）
• 支持-tsize选项(RFC2349)
• 支持-blksize选项(RFC2348),但每包Data限制为512字节
• 支持数据重传功能
• 支持文件名称校验功能
• 支持文件大小校验功能
• 支持数据包长度检測功能

         因为是在嵌入式设备上实现TFTPserver。因此这个server也有一些限制，例如以下所看到的：

• port号固定为69
• 单链接
• 不支持netascii模式

2.TFTP协议

         TFTP协议全称为简单文件传输协议。它是以UDP为基础的应用层协议。在实现TFTPserver之前。须要具体理解协议。眼下非常多介绍TFTP协议的书籍都是參照RFC1350，比方著名的《TCP/IP具体解释》。然而RFC1350已经被后来RFC2347、RFC2348、RFC2349等所取代。因此我们须要系统的认识一下这些最新的协议。

2.1 TFTP协议简单介绍

         1992年，修订版TFTP协议RFC1350公布，这一版本号的TFTP协议被广泛使用。《TCP/IP具体解释卷1》章节15解说TFTP协议时便是使用的这个版本号。

         除非一些很古老的TFTPclient/server软件。眼下主流的client/server软件都会支持TFTP扩展选项，1998年公布的RFC2347定义了TFTP扩展选项。扩展选项能够同意client和server之间进行协商。以便使用一些额外的功能。比方超时时间、文件大小、数据包大小等等。TFTP扩展选项添加一个新的选项应答（OACK）数据帧。用来应答client的选项协商请求，添加一个新的错误码（8），用来指示当进行选项协商出错时，终止传输数据。

         1998年颁布的RFC2348定义了数据块大小选项（blksize）。同年颁布的RFC2349定义了超时间隔（timeout）和文件大小（tsize）选项。

         注：本文全部“字节”均由8bit构成。

2.2 TFTP协议概述

         传输数据起始于一个读取或者写入文件的请求，仅仅有client才干够发送这样的请求。

         默认情况下，数据以定长512字节传输，假设server支持扩展选项。能够使用blksize选项协商数据长度。每一个数据包中仅包括一个数据块。仅仅有收到对方的应答数据包。才会发送下一包数据。

         假设一个数据包数据大小小于512字节或小于通过blksize选项协商定的数据长度，表示传输数据结束。

         两台机器进行传输数据时，一台为发送方一台为接收方。发送方发送数据并接收应答，接收方发送应答接收数据。

         大部分的错误会导致连接中断，错误由一个错误的数据包引起，这个包不会被确认，也不会被又一次发送。

2.3 TFTP协议传输模式

         TFTP协议支持三种传输模式，分别为：

• netascii：ASCII文本模式
• octet：二进制模式。每字节8位
• mail：如今已经不使用

2.4 TFTP协议数据包种类

         TFTP协议支持六种数据包格式，如表2-1所看到的。

2.4.1读写请求数据包

         RFC2347规定的TFTP选项字段附加于读请求和写请求数据帧中。

      

2.4.1.1经常使用的选项：blksize

         协商数据块大小，默认数据块为512，能够协商的值为8~65464字节（RFC2348）。

2.4.1.2 经常使用选项：timeout

         超时间隔，能够协商的值为1~255秒（RFC2349）

2.4.1.3经常使用选项：tsize

         传输文件的大小（RFC2349）

2.4.2 Data数据包

      

2.4.3 ACK数据包

     

2.4.4 ERROR数据包

      

2.4.5 OACK包格式：

      

2.5 TFTPclient/server设计注意事项

1)        仅仅能是client发送读写请求，读写请求数据包中可能附带选项信息。在读写请求数据包中可能有非常多个选项。但一个选项仅仅能出现一次。选项出现的顺序并不重要。

2)        假设server支持读写请求数据包中的选项。server会使用选项应答（OACK）响应。

OACK中包括server能够支持的选项以及该选项相应的值，绝对不能够包括client没有使用的选项。

假设client请求的某些选项server不支持。则在OACK中忽略这些选项。假设client请求的某些选项值server不能支持。server能够在OACK中将这些选项值替换为自己支持的或者发送一个错误包。错误码为8，以终止传输数据。

3)        假设client仅仅请求一个选项。而且该选项没有被server应答，client必须忽略这个选项，server必须表现的像从未收到过这个请求一样。假设client请求多个选项，server应答了部分请求选项。则client必须使用那些server已经应答的选项。忽略server没有应答的选项。

4)        当client向server发送带选项的读请求数据包，server可能返回三种响应：

• OACK：应答读请求和选项
• DATA：应答读请求，无选项
• ERROR：请求被拒绝

5)        当client向server发送带选项的写请求数据包，server可能返回三种响应：

• OACK：应答写请求和选项
• ACK：应答写请求。无选项
• ERROR：请求被拒绝

6)        假设一个server不支持协商选项，它非常可能会忽略掉client读写请求数据包中的选项字段。在这样的情况下。对于读请求，server应该返回DATA数据包；对于写请求应该返回ACK数据包。但假设某些server返回一个ERROR数据包，client应该又一次发送一个读写请求，而且这个读写请求中不包括不论什么选项信息。

7)        client应答OACK可能有两种方式，假设是读请求。则以ACK（数据块号设置为0）应答；假设是写请求，则以第一个数据块进行应答，数据块大小适应协商的值。假设client要拒绝OACK，它应该发送ERROR数据包，其错误码为8。

8)        server应保留发送的数据。直到下一帧正确到来。这样做是为了client响应超时后，重发最后一包数据。

         注意1：server不能请求选项。全部选项由client发起。

         注意2：假设client接收到的OACK中包括未请求的选项，client应该发送一个ERROR数据包，错误码为8。

3.boot程序设计

         boot程序的设计对于远程升级至关重要，在boot程序中。须要移植一个精简过的lwIP协议栈、实现TFTPserver、实如今应用编程（IAP）以及各种错误处理机制、超时重传机制。

         boot程序设计流程图如图3-1所看到的。

3.1 Flash区域划分

         如图3-2所看到的。将Flash划分为5个区域，各自是Boot程序区、标志扇区、出厂程序区和其他数据。

我们把出厂程序和用户程序统称为应用程序。

1)        Boot程序区：包含一个精简的lwIP协议栈、TFTPserver实现代码、在应用编程（IAP）实现代码以及測试用的调试工具代码。

2)        标志扇区：存储升级标志、升级地址、跳转地址等信息。

3)        出厂程序区：出厂默认程序，此区域的程序升级权限不正确非研发人员开放。

4)        用户程序区：出厂时此区域程序为空，在线升级的程序默认放到此区域，更改此区域的程序不会对出厂程序区的程序有不论什么影响。

3.2 lwIP协议栈移植

         TFTP协议属于应用层协议。须要UDP协议作支撑，因此首先应该移植一个完整的TCP/IP协议栈。TCP/IP协议栈选用lwIP1.4.1版本号，该协议栈专为嵌入式系统而设计。可在资源匮乏的微控制器上实现完整的可裁剪的TCP/IP协议，在不涉及分包和重组的嵌入式场合极其适用。

lwIP的移植涉及的东西比較多。移植本文不作描写叙述。

    

3.3 TFTPserver实现

         通过本文章节2对TFTP协议的分析能够看出，实现一个可用的TFTPclient/server并无特别之处。

但这里我们要实现一个健壮的、具有良好错误提示的TFTPserver。

         TFTPserver的设计流程图如图3-3所看到的。

         TFTPserver要有良好的容错能力，对于接收的数据包要有一定的分析能力，可以剔除非法数据、反复数据等。在设计FTFP过程中。须要识别写入的文件名称以及文件大小。防止写入非法文件或者过大的文件。

过大的文件会覆盖相邻区域的Flash数据，会造成不可恢复的错误。

         对于client传送过来的读写请求中。可能包括协商选项信息。因为我们事先并不知道client会传送多少个协商选项，因此须要将读写请求数据包进行完整的分析。对于支持的tsize选项和blksize选项。会记录选项的值。为校验文件大小以及回送OACK做准备，对于不支持的选项，直接忽略掉。

将全部选项分析完毕后。须要将支持的选项和选项值放到OACK包中回送给client。

假设client传输来的读写请求中并没有协商选项，则直接返回ACK数据包，当中的数据包号字段设置为0。

         对于client传送来的Data数据包，则须要校验数据长度和数据包号。校验数据包号能够在client发送不对数据包号时告知client下一包应该发送什么样的正确数据包，或者在client发送反复数据包时。server端不会反复的将数据写入Flash。

         考虑到实际现场环境可能很恶劣，client发送的数据或者server应答的数据可能会丢失，因此一个健壮的TFTPserver必需要有超时重传机制。为了在超时后重传最后一包数据，因此server必须额外开辟一个缓冲区用来保存近期一次发送的数据。

         因为TFTP数据包基于UDP协议，数据包最大不超过560字节，并且以太网底层具有CRC32校验、IP层和UDP层具有累加和校验，这次校验足够将传输过程中的错误数据识别出来，因此在实现TFTPserver的过程中。并不须要添加额外的校验。

图3-3 TFTPserver设计流程图

3.4 在应用编程（IAP）

         lpc1778芯片内部提供了编程Flash的底层代码。仅仅需构造一个函数指针调用芯片提供的Flash编程代码就可以。关于NXP ARM芯片的在应用编程基础知识能够參考我写过的一篇博文：基于IAP和Keil MDK的远程升级设计 。

3.5 超时退出Boot程序

         Boot程序事实上主要有两个作用。一个是上电后假设不须要升级程序。则跳转到出正确的应用程序。

二是上电发现须要升级程序则启动TFTPserver。与TFTPclient进行文件传输。能够发现。不管是第一个作用还是第二个作用，Boot运行的时间都不可能太长，毕竟真正使用的程序并不在于Boot。可是假设我们设置了升级标志后。又迟迟不给TFTP发送升级文件，这时设备会一直运行Boot程序，因此我们须要一个Boot程序运行超时定时器，来确保Boot程序运行时间到达后。跳转至正确的应用程序。

3.6 Boot程序部分指标

• 吞吐率：≈20KB/S
• 代码使用量：≈16.5KB
• RAM量使用量：≈28.5KB

4.測试

         理论上支持RFC1350和RFC2347的TFTPclient都能够使用，推荐使用Tftpd软件。该软件有两个版本号：Tftpd32软件用于32位系统，Tftpd64软件用于64位系统，软件不仅具有TFTPclient/server功能。还具有SNTPserver、DHCPserverDNSserver等功能。本次測试使用Tftpd32和Tftpd64软件作为上位机软件。

4.1 上位机配置

         打开Tftp64软件。切换到TftpClient界面，即TFTPclient配置界面。当中：

1)        Host：TFTPserverIP地址。

2)        Port：TFTPserver器port号，固定为69

3)        Local File：升级文件路径。

4)        Remote File：无需配置

5)        Block Size：数据块大小，设置为512或者Default。

6)        Getbutton：下载server上的文件，不须要

7)        Putbutton：向server上传文件，我们使用这个button向server传输升级文件

8)        Breakbutton：终止文件传输

4.2測试流程与測试结果

序号	測试方法	測试过程	符合设计
1	擦除整个芯片，仅仅烧写Boot程序	Boot要求更新用户程序区，使用Tftpdclient软件远程升级用户区程序后，Boot程序成功跳转至用户程序区。	符合设计
2	仅仅烧写Boot和出厂默认程序	执行出厂默认程序	符合设计
3	仅仅烧写Boot和用户程序	Boot要求更新用户程序区，使用ftpdclient软件远程升级用户区程序后，Boot程序成功跳转至用户程序区。	符合设计
4	执行出厂默认程序时远程升级出厂默认区域	Boot要求更新出厂程序，使用Tftpdclient软件远程升级用户区程序后。Boot程序成功跳转至用出厂程序。	符合设计
5	执行出厂默认程序时远程升级用户程序区域	Boot要求更新用户程序，使用Tftpdclient软件远程升级用户区程序后，Boot程序成功跳转至用户程序区。	符合设计
6	执行用户程序时远程升级出厂默认程序区域	Boot要求更新出厂程序，使用Tftpdclient软件远程升级用户区程序后，Boot程序成功跳转至用出厂程序。	符合设计
7	执行用户程序时远程升级用户程序区域	Boot要求更新用户程序，使用Tftpdclient软件远程升级用户区程序后，Boot程序成功跳转至用户程序区。	符合设计
8	升级过程中关闭TFTPclient软件	Boot超时重传，当重传次数过多时，跳转到正确的应用程序	符合设计
9	启动远程升级，但不传送不论什么数据	Boot执行超时后，自己主动跳转到正确的应用程序	符合设计
10	启动远程升级，但上传的文件名称非法	server向client回送”Bad filename.”错误信息	符合设计
11	启动远程升级。但上传的文件过大	server向client回送“Bad file length.”错误信息	符合设计
12	启动远程升级。使用Getbutton从server下载文件	server向client回送”File not fount.“信息	符合设计
13	启动远程升级，模拟数据丢包	数据丢包后。Boot程序启动超时重传机制，再次向client回送最后一帧数据	符合设计