Summary
When the FlexNet Operations back office removes support for older versions of TLS, communication between the back office and .NET XT clients may be disrupted. The cause for the disruption has been traced to .NET XT client applications being built against .NET Framework versions older than 4.6. The problem with building against these older versions is that, by default, the .NET communications will utilize the older version of TLS.
This article describes how to diagnose if the communication failure is caused by the TLS version by using a packet sniffer. In this example, we will use the Wireshark packet sniffing tool.
Configuring the Wireshark Packet Sniffer
We will use Wireshark to see the TLS communication between the client application and the back office server. In order to do this, we will need to filter on the following:
- The client's ethernet adapter. If unsure which to use, select all of them.
- The protocol: TLS.
- Communications to and from the target IP address.
Using Wireshark
The client application uses the following URL to communicate to FlexNet Operations:
https://<tenant>-uat.flexnetoperations.com/operations/deviceservices
Obtaining the Communications IP Address
Using nslookup or pinging for the hostname, you can obtain the communications IP address.
NOTE: In the example below, internal IP addresses have been obfuscated or modified for security reasons.
For this example, the IP address to use is 64.12.34.56.
Set Up Wireshark to Filter for IP Address Communication and TLS
Next you will need to set up Wireshark to filter for this IP address communication and the TLS protocol. To do that, you specify "(ip.src== 64.12.34.56 or ip.dst == 64.12.34.56) and tls" as the display filter.
IMPORTANT: Do not set this as the capture filter.
Then select the appropriate ethernet adapters.
Click the button with the shark fin to start capturing.
Failure Example
Below we have an example using C# XT client (using .NET Framework 3.5) sending a capability request to the FlexNet Operations URL.
Notice the client specifies using TLS 1.0 and the failure to communicate with the back office.
Success Example
If we update the client application to use .NET Framework 4.6 or greater, and send another capability request to FlexNet Operations, we observe the TLS version is 1.2 and the communication is successful.
Related Articles
Manually trigger MgsIPScan to diagnose undiscovered devices 20Number of Views Recommended License Changes & Unprocessed Purchases pages may take a long time to load and/or show an error due to problem… 6Number of Views Troubleshoot problems with CLR and SqlProceduresClr assembly configuration in FlexNet Manager Suite databases 33Number of Views Logging An InstallScript MSI Project 350Number of Views How to troubleshoot Active Directory Connection Problems using PowerShell for Spider 16Number of Views
Hi, I am Reva - Ask me anything.
No new updates
Thanks for the feedback!
Your feedback has been saved.Rate this response:
Add Additional feedback ( Optional )
Are you sure you want to cancel
the case creation?
Are you sure you want to cancel the case creation?
Are you sure you want to close this case
| Products | Region | Phone Numbers |
|---|---|---|
| FlexNet Operations FlexNet Embedded FlexNet Publisher FlexNet Connect FlexNet Code Insight InstallAnywhere InstallShield |
North America * |
+1 630-332-2513 (toll) +1 877-279-2853 (toll-free in North America) |
| Europe * |
+44 1925 944367 (toll) +44 800 047 8642 (toll-free in Europe) |
|
| Japan * | +81 3-4540-5335 (select option 2) | |
| Australia * |
+61 3 9895 2177 +61 1800 560 603 (toll-free in Australia) |
|
|
Usage Intelligence (formerly
Revulytics) Compliance Intelligence |
Please use the Case Portal to submit your support ticket or reach out to your Revenera contact. | |
Case id: 00001065
Activity: Status change: 2 hours ago