如何抓包分析FlexNet客户端与服务器之间的通信过程（tcpdump/Wireshark）

抓包是排查FlexNet网络问题的终极手段。当ping通、telnet通但客户端依然报错时，只有数据包里的内容能告诉你真相。

这篇文章不讲虚的，直接说怎么抓、怎么看。

一、为什么需要抓包

FlexNet的通信过程不是你想象中那种“客户端问一句，服务器答一句”的简单一问一答。它的机制有些反直觉：服务器在收到客户端的释放请求后，不会返回任何确认信号。这种“无握手协议”设计意味着，如果释放数据包在传输中丢失，服务器将永远认为这个许可证仍被占用。

很多疑难杂症——许可证签不出来、签出来了还不上、客户端报错但服务器日志看不出问题——光靠看日志是找不到答案的，只有看数据包才知道到底发生了什么。

二、准备工作

抓包之前确认三件事：

第一，确认通信端口。 FlexNet默认用27000到27009之间的TCP端口，但实际端口取决于你的SERVER行配置。先确认你用的是哪个端口：

text

cat /path/to/license.lic | grep SERVER

输出里第三个字段就是端口号。如果不确定，netstat -anp | grep lmgrd也能看到。

第二，确认网卡名称。 抓包时要指定网卡。Linux下用ip link show或ifconfig -a列出所有网卡，找到客户端通信走的那块（通常是eth0、ens192或bond0）。

第三，准备好Wireshark。 如果能在服务器上直接分析，可以只抓包不传文件。如果需要在本地分析，确保Wireshark已安装。FlexNet协议在Wireshark中有对应的解析器，能自动识别并解析数据包结构。

三、用tcpdump抓包

在服务器端执行。以下命令抓取所有与FlexNet端口相关的通信，写入文件供后续分析：

text

tcpdump -i eth0 port 27000 -w flexnet.pcap

参数说明：

• -i eth0：指定网卡，换成你实际的网卡名
• port 27000：只抓这个端口的数据包，减少干扰
• -w flexnet.pcap：写入文件，方便后续用Wireshark分析

如果vendor daemon用了独立端口（比如27002），把端口范围加上：

text

tcpdump -i eth0 port 27000 or port 27002 -w flexnet.pcap

如果端口范围较大（27000-27009），可以用portrange：

text

tcpdump -i eth0 portrange 27000-27009 -w flexnet.pcap

抓多久？ 重现问题通常只需要几十秒。先让tcpdump跑起来，然后在客户端触发许可证操作（启动软件、签出、签入、关闭软件），操作完成后按Ctrl+C停止抓包。

抓下来的pcap文件可以传到本地用Wireshark打开分析，也可以在服务器上用tcpdump -r flexnet.pcap -A直接看内容。

四、用Wireshark分析

打开pcap文件后，Wireshark会自动识别FlexNet协议。如果没识别出来，检查过滤器栏是否误过滤了。

第一步：设置显示过滤器

在过滤器栏输入flexnet，只显示FlexNet协议的数据包。这样可以过滤掉TCP握手、ACK等干扰信息，直接看到业务层的内容。

如果想看某个特定客户端的通信：

text

flexnet && ip.src == 192.168.1.100

如果想看某个特定feature的请求：

text

flexnet && frame contains "FEATURE_NAME"

第二步：理解FlexNet数据包结构

FlexNet数据包有一个固定长度的头部（FLEXNET_HDRLEN），包含源地址、目标地址和控制信息。Wireshark的解析器会把头部和负载分开显示，你只需要看解析后的字段就行了。

重点关注的内容：

第三步：追踪完整会话

右键点击任何一个FlexNet数据包，选择“Follow” → “TCP Stream”，可以看整个TCP连接上的完整对话。这对于理解“客户端到底发了什么、服务器到底回了什么”非常有帮助。

五、重点观察的通信阶段

阶段一：连接建立

客户端发起TCP三次握手到lmgrd的端口（如27000）。握手成功后，客户端发送第一个FlexNet请求——通常是查询可用feature列表或直接请求签出。

如果这个阶段失败：

• 看不到SYN包 → 客户端根本没发起连接，检查客户端配置
• 能看到SYN但无SYN-ACK → 服务器端口没开或防火墙拦截
• 能看到完整三次握手但后续无FlexNet请求 → 客户端协议栈问题

阶段二：许可证签出（CHECKOUT）

客户端发送签出请求，包含feature名称、用户名、主机名、版本等信息。服务器收到后检查许可证池，返回允许或拒绝。

成功签出的数据包特征：

• 请求包中包含明确的CHECKOUT或REQUEST关键字
• 响应包中返回许可证句柄（handle）或会话ID
• 客户端后续的通信都会带上这个会话ID

被拒绝的数据包特征：

• 响应包中包含错误码，如-4（无可用许可）、-15（连接问题）
• 有时服务器会返回“All licenses are in use”的明文信息

阶段三：许可证归还（CHECKIN）

客户端主动释放许可证时发送归还请求。关键点： 服务器收到后不会返回确认。如果你在抓包中看到客户端发送了归还请求，但服务器端日志显示许可证仍然被占用，说明归还数据包可能丢失了，或者服务器处理失败了。

阶段四：心跳与保活

客户端在持有许可证期间会定期发送心跳包，告诉服务器“我还活着”。如果长时间收不到心跳，服务器会认为客户端已崩溃，自动回收许可证。

观察心跳间隔： 如果心跳间隔过长或心跳包丢失，可能导致许可证被意外回收。

六、常见问题在抓包中的表现

问题一：客户端报-15（Cannot connect）

抓包中看不到任何从客户端发往服务器端口的TCP SYN包。问题在客户端侧——环境变量没配、DNS解析失败、客户端防火墙阻止出站连接。

如果能看到SYN包但服务器没响应，问题在服务器侧或中间网络——lmgrd没启动、端口没监听、防火墙拦截。

问题二：客户端报-4（No licenses available）

能看到签出请求，服务器返回了拒绝响应，响应中带有-4错误码或“No licenses available”信息。说明许可证池确实满了，不是网络问题。

但有一种情况值得注意：服务器认为满了，但实际有许可证被僵尸进程占用。这种情况下，抓包能看到某些会话长时间没有活动也没有释放。

问题三：许可证归还失败

客户端发送了归还请求，但服务器端日志显示许可证仍然被占用。抓包中能看到归还请求包发出，但服务器没有返回确认（正常现象，因为协议本身就不返回确认）。

这种情况下，问题可能出在：

• 归还请求在传输中丢失（网络丢包）
• 服务器收到了但处理失败（查看服务器日志）
• 客户端进程异常终止，根本没发出归还请求（抓包中看不到任何归还包）

问题四：重传比例过高

在Wireshark中查看TCP重传包的比例。如果重传比例明显偏高，说明网络质量有问题——延迟大、丢包多。跨地域或跨国部署时尤其常见。

七、几个实用技巧

技巧一：抓包前先清空日志

在服务器上执行> /var/log/flexnet/debug.log清空日志，然后抓包、复现问题。这样数据包和日志的时间戳可以对照着看，定位更精准。

技巧二：同时抓服务端和客户端

如果条件允许，在服务器和客户端同时抓包。对比两边的数据包，能快速判断问题是出在“客户端没发出来”还是“服务器没收到”。

技巧三：用lmstat触发特定操作

抓包时可以用lmstat -a触发状态查询，这样数据包中会包含一个完整的查询-响应周期，便于定位解析问题。

技巧四：保存过滤后的结果

在Wireshark中分析完后，可以用File → Export Specified Packets只导出FlexNet相关的数据包，方便存档或发给其他人分析。

抓包分析FlexNet通信，核心就三件事：

1. 抓什么：抓服务器端与FlexNet端口相关的所有TCP流量
2. 怎么看：用Wireshark的flexnet过滤器只看业务层，关注CHECKOUT、CHECKIN、心跳三个阶段
3. 找什么：找请求包和响应包的对应关系、找错误码、找重传包

大多数FlexNet网络问题，看数据包都比看日志更直接。日志告诉你“发生了什么”，数据包告诉你“为什么发生”。