嵌入式linux无法抓包,嵌入式硬件TCP通讯有关问题－附抓包情况

当前位置:我的异常网» Linux/Unix » 嵌入式硬件TCP通讯有关问题－附抓包情况

嵌入式硬件TCP通讯有关问题－附抓包情况

www.myexceptions.net  网友分享于：2013-03-23  浏览：48次

嵌入式硬件TCP通讯问题－附抓包情况

环境：

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

文章评论