USB驱动 Reset命令
[问题点数：40分]
USB驱动 Reset命令
[问题点数：40分]
不显示删除回复
显示所有回复
显示星级回复
显示得分回复
只显示楼主
2013年1月 硬件/嵌入开发大版内专家分月排行榜第一2012年10月 硬件/嵌入开发大版内专家分月排行榜第一2012年9月 硬件/嵌入开发大版内专家分月排行榜第一2012年8月 硬件/嵌入开发大版内专家分月排行榜第一2012年7月 硬件/嵌入开发大版内专家分月排行榜第一2012年6月 硬件/嵌入开发大版内专家分月排行榜第一2012年5月 硬件/嵌入开发大版内专家分月排行榜第一2012年4月 硬件/嵌入开发大版内专家分月排行榜第一2012年3月 硬件/嵌入开发大版内专家分月排行榜第一2012年2月 硬件/嵌入开发大版内专家分月排行榜第一2012年1月 硬件/嵌入开发大版内专家分月排行榜第一2011年11月 硬件/嵌入开发大版内专家分月排行榜第一2011年10月 硬件/嵌入开发大版内专家分月排行榜第一2011年9月 硬件/嵌入开发大版内专家分月排行榜第一
2014年10月 硬件/嵌入开发大版内专家分月排行榜第二2014年2月 硬件/嵌入开发大版内专家分月排行榜第二2013年10月 硬件/嵌入开发大版内专家分月排行榜第二2013年8月 硬件/嵌入开发大版内专家分月排行榜第二2013年3月 硬件/嵌入开发大版内专家分月排行榜第二2012年12月 硬件/嵌入开发大版内专家分月排行榜第二2012年11月 硬件/嵌入开发大版内专家分月排行榜第二2011年12月 硬件/嵌入开发大版内专家分月排行榜第二
2013年1月 硬件/嵌入开发大版内专家分月排行榜第一2012年10月 硬件/嵌入开发大版内专家分月排行榜第一2012年9月 硬件/嵌入开发大版内专家分月排行榜第一2012年8月 硬件/嵌入开发大版内专家分月排行榜第一2012年7月 硬件/嵌入开发大版内专家分月排行榜第一2012年6月 硬件/嵌入开发大版内专家分月排行榜第一2012年5月 硬件/嵌入开发大版内专家分月排行榜第一2012年4月 硬件/嵌入开发大版内专家分月排行榜第一2012年3月 硬件/嵌入开发大版内专家分月排行榜第一2012年2月 硬件/嵌入开发大版内专家分月排行榜第一2012年1月 硬件/嵌入开发大版内专家分月排行榜第一2011年11月 硬件/嵌入开发大版内专家分月排行榜第一2011年10月 硬件/嵌入开发大版内专家分月排行榜第一2011年9月 硬件/嵌入开发大版内专家分月排行榜第一
2014年10月 硬件/嵌入开发大版内专家分月排行榜第二2014年2月 硬件/嵌入开发大版内专家分月排行榜第二2013年10月 硬件/嵌入开发大版内专家分月排行榜第二2013年8月 硬件/嵌入开发大版内专家分月排行榜第二2013年3月 硬件/嵌入开发大版内专家分月排行榜第二2012年12月 硬件/嵌入开发大版内专家分月排行榜第二2012年11月 硬件/嵌入开发大版内专家分月排行榜第二2011年12月 硬件/嵌入开发大版内专家分月排行榜第二
本帖子已过去太久远了，不再提供回复功能。TCP异常终止（reset报文）
异常终止（报文）
的异常终止是相对于正常释放连接的过程而言的，我们都知道，连接的建立是通过三次握手完成的，而正常释放连接是通过四次挥手来完成，但是有些情况下，在交互的过程中会出现一些意想不到的情况，导致无法按照正常的四次挥手来释放连接，如果此时不通过其他的方式来释放连接的话，这个连接将会一直存在，占用系统的部分资源。在这种情况下，我们就需要有一种能够释放连接的机制，这种机制就是的报文。报文是指报头的标志字段中的位置一的报文，如下图所示：
异常终止的常见情形
我们在实际的工作环境中，导致某一方发送报文的情形主要有以下几种：
，客户端尝试与服务器未对外提供服务的端口建立连接，服务器将会直接向客户端发送报文。
，客户端和服务器的某一方在交互的过程中发生异常（如程序崩溃等），该方系统将向对端发送报文，告之对方释放相关的连接，如下图所示：
，接收端收到报文，但是发现该的报文，并不在其已建立的连接列表内，则其直接向对端发送报文，如下图所示：
，在交互的双方中的某一方长期未收到来自对方的确认报文，则其在超出一定的重传次数或时间后，会主动向对端发送报文释放该连接，如下图所示：
，有些应用开发者在设计应用系统时，会利用报文快速释放已经完成数据交互的连接，以提高业务交互的效率，如下图所示：
&报文的利用
安全设备利用报文阻断异常连接
安全设备（如防火墙、入侵检测系统等）在发现某些可疑的连接时，会构造交互双方的报文发给对端，让对端释放该连接。比如入侵检测检测到黑客攻击的连接，其构造成被攻击端给黑客主机发送报文，让黑客主机释放攻击连接。
利用报文实施攻击
安全设备可以利用报文达到安全防护的效果，黑客和攻击者也可以利用报文实现对某些主机的入侵和攻击，最常见的就是会话劫持攻击。关于会话劫持的相关知识请参考第三章《TCP会话劫持》一文。
您对本文的评分:
当前平均分: 9.6(36 次打分)
相关日志：
版权所有：《》 => 《》
本文地址：
除非注明，文章均为 《》 原创，欢迎转载！转载请注明本文地址，谢谢。
我曾七次鄙视自己的灵魂：它本可进取却故作谦卑；它在空虚时用爱欲来填充；在困难和容易之间它选择容易；它犯了错，却借由别人也会犯错来宽慰自己；它自由软弱，却把它认为是生命的坚韧；它鄙夷一张丑恶的嘴脸，却不知那正是自己面具中的一副；它侧身于生活的污泥，虽不甘心却又畏首畏尾。——纪伯伦 21:12
每个人的生命都是通向自我的征途，是对一条道路的尝试，是一条小径的悄然召唤。觉醒的人只有一项任务：找到自我，固守自我，沿着自己的路向前走，不管它通向哪里。 ——赫尔曼·黑塞 20:02
我始终相信，开始在内心生活得更严肃的人，也会在外表上开始生活得更朴素。在一个奢华浪费的年代，我希望能向世界表明，人类真正需要的的东西是非常之微少的。 ——《真实的高贵》 18:25
做产品以获得大众认可为标准，做技术以获得同行认可为标准。——tombkeeper 12:18
文化其实体现在一个人如何对待他人、对待自己、如何对待自己所处的自然环境。在一个文化厚实深沉的社会里，人懂得尊重自己——他不苟且，因为不苟且所以有品位；人懂得尊重别人——他不霸道，因为不霸道所以有道德；人懂得尊重自然——他不掠夺，因为不掠夺所以有永续的智能。——龙应台 18:481465人阅读
windows开发（8）
最近在做烧写工具的优化工作，有一些关于USB的内容需要总结一下其中包括设备的初始化过程和枚举过程。
在枚举的过程中，设备会一直等PC端的状态，当等到reset命令时会对设备进行重新枚举。但是这个reset终端是如何而来呢？
Halt Conditions
A control endpoint may recover from a halt condition upon receiving a SETUP packet. If the endpoint does not recover from a SETUP packet, it may need to be recovered via a different pipe.
If an endpoint with the endpoint number 0 does not recover with a SETUP packet, the host should issue a device reset.
在usb协议中有上面的描述，大致意思是：控制断电在接收到SETUP包的时候慧聪挂起状态恢复。如果端点没有从SETUP包恢复，它可能需要通过不同的管道来进行恢复。如果端点0没有从SETUP包中恢复，那么主机端将产生设备重启的事件。
这样就能够解释，在DFU文件工作的过程中程序要持续接收中断，等待reset之后，会对设备进行重新的枚举过程。具体的操作后续进行描述。
usb 相关文件下载：
http://www.usb.org/developers/docs/usb20_docs/
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：305662次
积分：3889
积分：3889
排名：第5252名
原创：92篇
评论：61条
谨此声明：本人目前的博客内容还有点混乱，但是本人在不断的修正中。
(1)(6)(1)(2)(1)(1)(2)(3)(1)(5)(1)(10)(3)(5)(4)(7)(5)(1)(3)(2)(1)(2)(1)(4)(4)(6)(15)TCP中异常关闭链接的意义 异常关闭的情况 - 推酷
TCP中异常关闭链接的意义 异常关闭的情况
终止一个连接的正常方式是发送FIN。
在发送缓冲区中
所有排队数据都已发送之后才发送FIN，正常情况下没有任何数据丢失。
但我们有时也有可能发送一个RST报文段而不是F
IN来中途关闭一个连接。这称为异常关闭
进程关闭socket的默认方式是正常关闭，如果需要异常关闭，利用
SO_LINGER选项来控制。
异常关闭一个连接对应用程序来说有两个优点：
（1）丢弃任何待发的已经无意义的
数据，并立即发送RST报文段；
（2）RST的接收方利用关闭方式来
区分另一端执行的是异常关闭还是正常关闭。
值得注意的是RST报文段不会导致另一端产生任何响应，另一端根本不进行确认。收到RST的一方将终止该连接。程序行为如下：
阻塞模型下，内核无法主动通知应用层出错，只有应用层主动调用read()或者write()这样的IO系统调用时，内核才会利用出错来通知应用层对端RST。
非阻塞模型下，select或者epoll会返回sockfd可读,应用层对其进行读取时，read()会报错RST。
游戏测试过程中发现某些socket错误经常出现，以下是测试游戏服务器时通常考虑的case.
Case：客户端程序正常运行的情况下，拔掉网线，杀掉客户端程序
目的：模拟客户端死机、系统突然重启、网线松动或网络不通等情况
结论：这种情况下服务器程序没有检测到任何异常，并最后等待“超时”才断开TCP连接
Case：客户端程序发送很多数据包后正常关闭Socket并exit进程(或不退出进程)
目的：模拟客户端发送完消息后正常退出的情况
结论：这种情况下服务器程序能够成功接收完所有消息，并最后收到“对端关闭”（Recv返回零）消息
Case：客户端程序发送很多数据包后不关闭Socket直接exit进程
目的：模拟客户端程序退出而忘记关闭Socket的情况（比如通过Windows窗口的关闭图标退出进程，而没有捕获相应关闭事件做正常退出处理等）
结论：这种情况下服务器程序能够收到部分TCP消息，然后收到“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）错误
Case：客户端程序发送很多数据包的过程中直接Kill进程
目的：模拟客户端程序崩溃或非正常方式结束进程（比如Linux下”kill -9″或Windows的任务管理器杀死进程）的情况
结论：这种情况下服务器程序很快收到“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）错误
Case：客户端程序发送很多数据包后正常关闭Socket并exit进程（或不退出进程）
目的：模拟客户端正常关闭Socket后，服务器端在检查到TCP对端关闭前向客户端发送消息的情况
结论：这种情况下服务器程序接收和发送部分TCP消息后，在Send消息时产生“32: Broken pipe”（Linux下）或“10053: An established connection was aborted by the software in your host machine”（Windows下）错误
当TCP连接的进程在忘记关闭Socket而退出、程序崩溃、或非正常方式结束进程的情况下（Windows客户端），会导致TCP连接的对端进程产生“104: Connection reset by peer”（Linux下）或“10054: An existing connection was forcibly closed by the remote host”（Windows下）错误
当TCP连接的进程机器发生死机、系统突然重启、网线松动或网络不通等情况下，连接的对端进程可能检测不到任何异常，并最后等待“超时”才断开TCP连接
当TCP连接的进程正常关闭Socket时，对端进程在检查到TCP关闭事件之前仍然向TCP发送消息，则在Send消息时会产生“32: Broken pipe”（Linux下）或“10053: An established connection was aborted by the software in your host machine”（Windows下）错误
服务器端已经close了Socket，客户端再发送数据
目的：测试在TCP对端进程已经关闭Socket时，本端进程还未检测到连接关闭的情况下继续向对端发送消息
结论：第一包可以发送成功，但第二包发送失败，错误码为“10053: An established connection was aborted by the software in your host machine”（Windows下）或“32: Broken pipe，同时收到SIGPIPE信号”（Linux下）错误
服务器端发送数据到TCP后close了Socket，客户端再发送一包数据，然后接收消息
目的：测试在TCP对端进程发送数据后关闭Socket，本端进程还未检测到连接关闭的情况下发送一包消息，并接着接收消息
结论：客户端能够成功发送第一包数据（这会导致服务器端发送一个RST包 &已抓包验证&），客户端再去Recv时，对于Windows和Linux程序有如下不同的表现：
Windows客户端程序：Recv失败，错误码为“10053: An established connection was aborted by the software in your host machine”
Linux客户端程序：能正常接收完所有消息包，最后收到正常的对端关闭消息（这一点与Window下不一样）
服务器端在TCP的接收缓冲区中还有未接收数据的情况下close了Socket，客户端再收包
目的：测试在TCP的接收缓冲区中还有未接收数据的情况下关闭Socket时，对端进程是否正常
结论：这种情况服务器端就会向对端发送RST包，而不是正常的FIN包（已经抓包证明），这就会导致客户端提前（RST包比正常数据包先被收到）收到“10054: An existing connection was forcibly closed by the remote host”（Windows下）或“104: Connection reset by peer”（Linux下）错误
当TCP连接的对端进程已经关闭了Socket的情况下，本端进程再发送数据时，第一包可以发送成功（但会导致对端发送一个RST包过来）：
之后如果再继续发送数据会失败，错误码为“10053: An established connection was aborted by the software in your host machine”（Windows下）或“32: Broken pipe，同时收到SIGPIPE信号”（Linux下）错误；
之后如果接收数据，则Windows下会报10053的错误，而Linux下则收到正常关闭消息
TCP连接的本端接收缓冲区中还有未接收数据的情况下close了Socket，则本端TCP会向对端发送RST包，而不是正常的FIN包，这就会导致对端进程提前（RST包比正常数据包先被收到）收到“10054: An existing connection was forcibly closed by the remote host”（Windows下）或“104: Connection reset by peer”（Linux下）错误
已发表评论数()
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
没有分页内容
图片无法显示
视频无法显示
与原文不一致}