当前位置: 技术问答>linux和unix
嵌入式硬件TCP通讯问题－附抓包情况
来源: 互联网 发布时间：2017-02-03
本文导语: 本帖最后由 wingwind_cn 于 2011-12-07 21:58:10 编辑 环境： mpc8360目标板上运行tcp接收服务程序IP地址193.168.0.99，端7000 PC机上运行tcp客户端发送程序，发送数据来自特定采样数据文件little.datIP地址193.168.0.111 （两端socket设置bu...
环境：
mpc8360目标板上运行tcp接收服务程序IP地址193.168.0.99，端7000
PC机上运行tcp客户端发送程序，发送数据来自特定采样数据文件little.datIP地址193.168.0.111
（两端socket设置buf大小为8192，linux服务端KEEPALIVE开）
现象
1.发送随机的文件或随机数据tcp通讯正常。
2.发送little.dat文件，每次发送到固定位置会出现卡顿或者卡死情况。卡死时，PC端程序tcp发送函数处报10054错误；但mpc8360端则无任何异常，程序不会出现socket错误，而是阻塞在tcp recv函数处。
mpc8360linux环境下，netstat -a查看socket链接仍然处于established状态；用netstat -st查看，发现有collapse失序状态出现。但此时从PC机ping板子，却是通的。
PC机上ethereal抓包分析，故障位置抓包结果如下：
No. Time source Destination Protocal Info
2782 21.886684 193.168.0.99 193.168.0.111 TCP 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1610753
2783 21.900930 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1610753 nextseq=1612213 flags=PSH,ACK
2784 21.900949 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1612213 nextseq=1612801 flags=PSH,ACK
2785 21.901078 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#1] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1612213
2786 21.901090 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#2] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1612801
2787 21.901102 193.168.0.111 193.168.0.99 TCP [TCP Fast Retransmition] 1122>7000 seq=1608705 nextseq=1609729 flags=PSH,ACK
2788 21.914840 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1612801 nextseq=1614261 flags=PSH,ACK
2789 21.914854 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1614261 nextseq=1614849 flags=PSH,ACK
2790 21.914998 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#3] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1614261
2791 21.916500 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#4] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1614849
2792 21.920240 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1614849 nextseq=1616309 flags=PSH,ACK
2793 21.924344 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1616309 nextseq=1616897 flags=PSH,ACK
2794 21.925000 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#5] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1616309
2795 21.9152000 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#6] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1616897
2796 22.7000004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2797 23.530004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2798 24.7000004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2799 25.3330036 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2800 26.8220256 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2800 28.5220256 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
随后，PC机发送函数报10054错误，关闭socket。（另一个奇怪现象是此时PC程序关闭socket时抓包中发现PC机没有发出FIN包或者RST包）
问题：请帮助分析一下，什么情况下，硬件TCP接收端会认为没有收到发送端重传的包（抓包表明重传已经发出了）？令人奇怪的是，即使重传包没收到，此后那些不属于重传的发送包接收端却又收到了，就是收不到重传包。
（从没有贴出的其他抓包来看，有时候mpc8360硬件在失序发生时，偶尔可以收到重传包，从而恢复了tcp传输）
（另一个现象是，特殊的数据发送帧以很高的概率让mpc8360进入tcp失序，80%以上，此时要么卡顿，要么卡死）
困扰多时，作为一个案例请大家分析分析。
mpc8360目标板上运行tcp接收服务程序IP地址193.168.0.99，端7000
PC机上运行tcp客户端发送程序，发送数据来自特定采样数据文件little.datIP地址193.168.0.111
（两端socket设置buf大小为8192，linux服务端KEEPALIVE开）
现象
1.发送随机的文件或随机数据tcp通讯正常。
2.发送little.dat文件，每次发送到固定位置会出现卡顿或者卡死情况。卡死时，PC端程序tcp发送函数处报10054错误；但mpc8360端则无任何异常，程序不会出现socket错误，而是阻塞在tcp recv函数处。
mpc8360linux环境下，netstat -a查看socket链接仍然处于established状态；用netstat -st查看，发现有collapse失序状态出现。但此时从PC机ping板子，却是通的。
PC机上ethereal抓包分析，故障位置抓包结果如下：
No. Time source Destination Protocal Info
2782 21.886684 193.168.0.99 193.168.0.111 TCP 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1610753
2783 21.900930 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1610753 nextseq=1612213 flags=PSH,ACK
2784 21.900949 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1612213 nextseq=1612801 flags=PSH,ACK
2785 21.901078 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#1] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1612213
2786 21.901090 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#2] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1612801
2787 21.901102 193.168.0.111 193.168.0.99 TCP [TCP Fast Retransmition] 1122>7000 seq=1608705 nextseq=1609729 flags=PSH,ACK
2788 21.914840 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1612801 nextseq=1614261 flags=PSH,ACK
2789 21.914854 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1614261 nextseq=1614849 flags=PSH,ACK
2790 21.914998 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#3] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1614261
2791 21.916500 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#4] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1614849
2792 21.920240 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1614849 nextseq=1616309 flags=PSH,ACK
2793 21.924344 193.168.0.111 193.168.0.99 TCP 1122>7000 seq=1616309 nextseq=1616897 flags=PSH,ACK
2794 21.925000 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#5] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1616309
2795 21.9152000 193.168.0.99 193.168.0.111 TCP [TCP DUP ACK 2782#6] 7000>1122[ACK] seq=1 ACK=1608705 win=23552 len=0 SLE=1610165 SRE=1616897
2796 22.7000004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2797 23.530004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2798 24.7000004 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2799 25.3330036 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2800 26.8220256 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
2800 28.5220256 193.168.0.111 193.168.0.99 TCP [TCP Retransmition] 1122>7000 seq=1608705 nextseq=1610165 flags=PSH,ACK
随后，PC机发送函数报10054错误，关闭socket。（另一个奇怪现象是此时PC程序关闭socket时抓包中发现PC机没有发出FIN包或者RST包）
问题：请帮助分析一下，什么情况下，硬件TCP接收端会认为没有收到发送端重传的包（抓包表明重传已经发出了）？令人奇怪的是，即使重传包没收到，此后那些不属于重传的发送包接收端却又收到了，就是收不到重传包。
（从没有贴出的其他抓包来看，有时候mpc8360硬件在失序发生时，偶尔可以收到重传包，从而恢复了tcp传输）
（另一个现象是，特殊的数据发送帧以很高的概率让mpc8360进入tcp失序，80%以上，此时要么卡顿，要么卡死）
困扰多时，作为一个案例请大家分析分析。
|
可以去找找freescale的勘误手册 mpc8360ec 之类的
freescale每个cpu几乎都有bug 记在勘误里
刚刚遇到8548一个很变态的bug
freescale每个cpu几乎都有bug 记在勘误里
刚刚遇到8548一个很变态的bug
您可能感兴趣的文章:
本站(WWW.)旨在分享和传播互联网科技相关的资讯和技术，将尽最大努力为读者提供更好的信息聚合和浏览方式。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。
本站(WWW.)站内文章除注明原创外，均为转载、整理或搜集自网络。欢迎任何形式的转载，转载请注明出处。