WireShark抓包简单使用

场景

昨天和客户端调试，使用tcp上报，服务端报错。查看日志报错如下：

.connect.network.exception.RejectJsonRequestException: com.fasterxml.jackson.core.io.JsonEOFException: Unexpected end-of-input: was expecting closing quote for a string value
at [Source: {"msgId":63,"action":"reportDeviceInfo","params":{"devTid":"0f0bbd7db94841ceb38f37fdeb0372a8","mid":"01650ca78f33","workMode":1,"MAC":"","tokenType":2,"binVer":"6.0.0.14","binType":"A","zigOtaBinVer":"0.0.0.3; line: 1, column: 411]

发现，tcp传输的参数内容被截断了

2020-04-22T16:29:24.324+0800 INFO [nioEventLoopGroup-8-1] m.s.c.s.i.TerminalContextServiceImpl.channelJsonRead:138 - device send data,the receive data is:{"msgId":63,"action":"reportDeviceInfo","params":{"devTid":"0f0bbd7db94841ceb38f37fdeb0372a8","mid":"01650ca78f33","workMode":1,"MAC":"","tokenType":2,"binVer":"6.0.0.14","binType":"A","zigOtaBinVer":"0.0.0.3

2020-04-22T16:29:24.326+0800 INFO [nioEventLoopGroup-8-1] m.s.c.s.i.TerminalContextServiceImpl.channelJsonRead:138 - device send data,the receive data is:","SDKVer":"1.0.0.0","serviceHost":"xxx.com","servicePort":88,"lanIp":"192.168.3.6"}}

完整的参数内容应该是：

{"msgId":63,"action":"reportDeviceInfo","params":{"devTid":"0f0bbd7db94841ceb38f37fdeb0372a8","mid":"01650ca78f33","workMode":1,"MAC":"","tokenType":2,"binVer":"6.0.0.14","binType":"A","zigOtaBinVer":"0.0.0.3","SDKVer":"1.0.0.0","serviceHost":"xxx.com","servicePort":88,"lanIp":"192.168.3.6"}}

原因分析

首先上报逻辑最近没有改动过，开始怀疑是客户端没有遵循相应的协议，导致接受到的信息被分割了。
于是联调，使用抓包命令:

rm -f /tmp/gwb.cap && tcpdump -i ens33 host 192.168.10.58 -w /tmp/gwb.cap

客户端重新请求，推出抓包命令。
把/tmp/gwb.cap文件下载到本地，使用WireShark打开，发现tcp的数据包内容是正常的：

使用WireShark打开gwb.cap，找到传输的包 数据内容

百思不得其解，使用解析内容为文本，发现了数据包的问题，多了一个换行符：

换行符

换行符其实在里面是数据结束标志，服务端使用的是netty，为了解决粘包分包问题，使用了分隔符拆包器 DelimiterBasedFrameDecoder，所以导致了问题。

换行符 服务端Netty配置了DelimiterBasedFrameDecoder，使用换行符作为分包分隔符

验证排查

客户端去掉换行符之后，重新传输，验证通过