基于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回送最后一帧数据 |
符合设计 |