troubleshooting and debugging citrix receiver for ios and android

Hello and Welcome to Troubleshoo*ng and Debugging Receiver for iOS and Android. This presenta4on will show you the tools and data that can be used to help resolve problems in the Receivers for iOS and Android.

1

Why Mobility? Mobility can make employees more produc4ve and reac4ve by allowing them to access any resource, anywhere with any device.

2

Why Now? There is an increasing demand for employees to securely access these resources on the device of their choice and the pressure is on for IT to adapt!

3

Here is a look at this fast growing and rapidly changing mobile market. From these forecasts from Gartner, we’ll see twice as many smartphones and tablets by 2015 as we did in 2012.

4

Here is a look at this fast growing and rapidly changing mobile market. From these forecasts from Gartner, we’ll see twice as many smartphones and tablets by 2015 as we did in 2012.

5

Mobility is a top priority for organiza4ons AND the employees. And it is a BIG challenge for IT.

6

How do you find the problem when dealing with the Mobile Receivers? There are lots of ones and zeroes flowing, how do we know which ones to look at? There has not been much logging in the Citrix Mobile Receivers in the past and it was quite difficult to get to. Many have been frustrated looking for logging within the Mobile Receivers. We have added some exci4ng new and convenient tracing methods to both the iOS and Android Receivers.

7

With all the combina4ons of products or network devices between your Mobile Receivers and your cri4cal business applica4ons and desktops, First, understand the infrastructure design to help narrow down the problem. These are the major components considered in this presenta4on. The Mobile Receivers: iOS and Android, the Network and Web components: Netscaler, Storefront and Web Interface, and your business resources like XenApp published applica4ons and XenDesktop machines. See the big picture and ISOLATE the issue by determining which connec4on scenarios the problem does and does not occur. Next, SEPARATE the network layers from the applica4ons layer by checking out the network traffic. Then, GATHER and INVESTIGATE the key diagnos4c data from the applica4ons layers. Here is how to get the most useful data from the XenDesktops and XenApp Servers and the Mobile Receivers.

8


9


10

The Agenda: Start with common Network and ICA Connec4on troubleshoo4ng steps. This sec4on can be applied to connec4on issues from any Citrix Receiver. Look at Network Traces, useful Event Logs and CDF Tracing. In the next sec4on, gert into all new Advanced Logs in the Receiver for iOS. Show how to enable, collect and debug these logs. Then the same for LogCat logging in the Receiver for Android. Cover some supportability concerns for these Receivers. Within each of these three sec4ons, cover some Case Studies. Wrap it up and provide some references.

11

12

Get started with Network and ICA Connec4on Troubleshoo4ng

13

It is a common prac4ce in iden4fying an issue is to ISOLATE the problem to a specific scenario. Does the issue occur for XenApp and XenDesktop connec4ons?

14

Is there a difference if the user connects from StoreFront, Web Interface, or a Services Site?

15

Is the issue occurring for a specific user base? Or certain devices only? How oeen does the issue occur? Every 4me? 1 out of 10 4mes? Or the second 4me only?

16

It is very important to get clear, sequen4al steps that a user takes to reproduce the problem and include approximate 4mes while collec4ng data. For example, here we started the tracing about 6:09 on April 2nd, the user logged on to Web Interface from the Browser at about 6:10 and launched a XenApp Desktop at 6:11. Include the Expected Behavior as well as the Unexpected Behavior which is the problem you are experiencing.

17

If the infrastructure is too complex or requires a proprietary soeware backend, may rely on an External Reproduc4on, we may ask for need test user access to your environment. This would give our engineers an opportunity to test, create and recreate private Receiver builds on the spot to find the solu4on the fastest. We would ask for the StoreFront or Account configura4on, usually a URL and a Test user account. Of course, one without a Security Token would be ideal but if it is required, we will s4ll work with you.

18

For client side issues, compare with other Receivers. Did the issue occur with a previous Receiver version? This tells us that is may be a Regression. Or if available, does the issue occur in the Beta Version of the Receiver? Here is the Beta for Android and iOS has an Early Adopter Program that you subscribe to by contac4ng Citrix. A Beta version will help determine if we have already resolved the issue. Determine if the issue occurs when launching the connec4on from the Device’s Browser or within the configured Receiver. Also the iOS and Android Receivers have a rela4vely common feature set, so it is good to know if it happens with both of these plagorms. Finally, the real litmus test for Receiver issues is does it occur with the latest Receiver for Window? This could indicate the problem is on the server.

19


20


21

Next, check out the Network connec4on, is there an Access Gateway in the mix and is it in ICA Proxy mode or Full VPN mode? Or using a third party VPN? Does the issue occur for Internal users or External users or both? For the Mobile plagorms does the issue occurs from both the 4G network and from a Wi-‐fi connec4on? Since Authen4ca4on is oeen done on the network devices, is single or dual authen4ca4on? Cer4ficates tends to be a common set back with the Receivers. Have a public or private cer4ficate? Is the private cer4ficate on the end device? Is the intermediate cer4ficate on the Gateway device? Also, ensure using a supported cer4ficate or authen4ca4on method.

22

Preparing for Network traces, note the IP Addresses of all the network devices used for the connec4on. Look for any unique or custom configura4ons. Check for logging in any Third Party products used for the connec4on. And iden4fy the closest working scenario. Then, if suspect that there may be something wrong at the Network level, Collect working and non-‐working Network Traces.

23

Specific to the Citrix ICA Connec4on, ICA is Citrix’s primary TCP Protocol and it uses port 1494. Session Reliability uses CGP over 2598, which is basically a reliability buffer around ICA. It is good to determine if your issue occurs during enumera4on or the connec4on aiempt. Authen4ca4on issues may occur during Enumera4on The connec4on issues occur during the Session launch. With the Mobile Receivers, the enumera4on occurs during the ini4al authen4ca4on. With Web Interface enumera4on occurs each 4me. and the App can be launch from the Desktop browser or from the Receiver.

Network Traces Analysis-‐ Here are some quick analysis 4ps to find the ICA traffic in a Network Trace. Wireshark and several other network tools have the same type of features. First, filter the trace to the most useful data. Iden4fy the Citrix connec4ons by filtering on ports 1494 and 2598. If you have the IP informa4on of the client and server, filter on the IP addresses to view the en4re conversa4on.

24

Network Traces Analysis-‐ Here are some quick analysis 4ps to find the ICA traffic in a Network Trace. Wireshark and several other network tools have the same type of features. First, filter the trace to the most useful data. Iden4fy the Citrix connec4ons by filtering on ports 1494 and 2598. If you have the IP informa4on of the client and server, filter on the IP addresses to view the en4re conversa4on.

25

A nice feature in Wireshark from readability is to add a common name to the IP Addresses or allow the automa4c Name Resolu4on if on the internal network. For 4ming or performance issues, it helps to set the Time Format to something more readable.

26

Once formaied and filtered the output, find the beginning of the ICA conversa4on. This can be done by looking for the TCP Handshake – SYN, SYN/ACK, and ACK. These three messages start every TCP/IP network connec4on. Once the ICA conversa4on is found, use Follow the TCP Stream and then iden4fy the ICA Sounder, which shows up as 7F 7F in the data.

27


28


29

Aeer finding the ICA network traffic, look for the most common problems. One method of finding the problem is to simply use the 4ming of the failed behavior. Perhaps the issue occurs 5-‐10 seconds aeer the beginning of the connec4on aiempt so focus on that area of the trace. Wireshark has an excellent Expert Info feature, located in the Analyze Menu, you can get some useful data from the Details tab. Here you can iden4fy Network Satura4on, see these TCP Dup ACK messages and Retransmission or Resets. If one of these issues, look at the traffic and determine which side of the conversa4on ini4ated the drops. Look at the trace of a working scenario to iden4fy differences. Use at these clues from the trace analysis to determine if any par4cular node within the network connec4on is causing a problem and then try to confirm by elimina4ng or avoiding that component.

30


31


32


33


34


35


36


37

There are a couple of ways to get a Network trace from a Netscaler device. The command line way with secure shell tools like PuTTY and secure copy tools u4lizing the nstrace command. Or a trace can be gathered from the Netscaler web console under System Diagnos4cs, select Start new trace. Dealing with Secure traffic, to decrypt an SSL Trace obtain the Private Key. See CTX116557 for further details.

38


39


40


41

42

Some other data to collect for ICA Connec4on Issues. First check the System and Applica4on Event Logs for your XenApp Server or XenDesktop host. Could discover Licensing issues or Authen4ca4on issues indicated there. Check the Event Logs of the Authen4ca4ng Server, whether it is the Web Interface Server or the XML Broker. For 4cke4ng issues, there are STA Logs that can be enabled. Enable Web Interface tracing in the web.config file There are several tracing categories that you can enable for Web Interface Issues. And for Web Site issues examine the IIS Logs. I have referenced all the Citrix KB Ar4cles that you need for these steps in this slide deck. Receiver for iOS Troubleshoo4ng hip://support.citrix.com/proddocs/topic/receiver-‐ios-‐57/ios-‐receiver-‐admin-‐troubleshoo4ng.html Enable STA Logging hip://support.citrix.com/ar4cle/CTX120589 Web Interface tracing hip://support.citrix.com/ar4cle/CTX122427

43


44


45

Citrix Diagnos4c Facility (CDF) is Citrix’s primary data capturing method. It is the best way to trace most of our server products. It does require parsing with symbols and we have a public Citrix Symbol server if you want to analyzing a CDF Trace. CDF is based off Event Tracing for Windows with Providers, Controllers and Consumers. This just means that you must enable the Citrix modules to trace (providers) and then collect them with a u4lity (controller and consumer). But first, we must determine where to collect the CDF Trace. For session launching issues, collect the CDF trace from the server hos4ng the applica4on or the XenDesktop VDA. If you are dealing with Applica4on enumera4on or Load-‐balancing issues, trace all IMA/XML modules on the Zone Data Collector and XML Brokers.

46

There are a couple of Citrix u4li4es that can be used to gather a CDF Trace file while the issue occurs, Scout and CDF Control. Both of these u4li4es will provide Tracing Categories of Citrix modules to enable specific to the issue. For issues that are intermiient or hard to reproduce, leave a circular CDF trace running, un4l the issue occurs and then collect the etl file. While we do not recommend leaving CDF Traces running under normal opera4ng circumstances, CDF Traces can be taken with a minimal performance impact on the host. Submit the .etl file to Citrix Technical Support for a detailed analysis.

A Demo of the CDF Control u4lity at work on a Citrix XenDesktop VDA and on a Citrix XenApp Server. <PLAY> To use CDF Control for gathering a CDF Trace, download the u4lity on the VDA from our KB at CTX111961. This will download a compressed zip file of the execu4bles for 32-‐bit and 64-‐bit. Next simply drill down and run the executable. There is no install process, which makes it easy to move this u4lity around. Here are the Op4ons for the ways to gather the trace file, like that circular log I men4oned earlier. Here are the Trace Categories, which allows us to only trace the Citrix modules (providers) specific to the issue. If your issue clearly falls into one of these categories it could save 4me but if you are in doubt select All Modules. You can also Clear All Selected. And you can select mul4ple categories and it will choose both sets of modules. When you are ready to reproduce the issue, select Start Tracing. If you are tracing an event that occurs during the logon of a disconnected session, simply leave this trace running, disconnect the session and reconnect to the session. Stop the trace once the logon process is completed. By default, the etl file will be located in the same folder as the CDF Control executable. Send this etl file into Citrix Technical Support for analysis. This works the same from the XenApp Server. You can run a CDF Trace from an Administrators session and it collect all the session’s data and it will grow very fast.

47

To Summarize some of the Data Collected in this sec4on, For Network problems, get the Network Traces in pcap or cap file and the Network IP informa4on Make sure to note the IP Addresses of all the important devices, like the XenApp Server and Citrix Receiver.

48


49


50

The CDF Trace come in a etl file along with the repro steps during that collec4on. Here is the files and Good reproduc4on steps with 4mes added.

51


52


53

And finally include the other important logs like Applica4on and System Event Logs of the appropriate servers.

54

And finally include the other important logs like Applica4on and System Event Logs of the appropriate servers.

55

This is some of the key Diagnos4c Data from the Network and Server-‐side for any ICA Connec4on issues

56

First Case Study!

57

58

In this Case, the Long Commmand Line Parameter which allows you to send an argument, like an hip page or file to the published applica4on was failing intermiiently from the iOS Receiver. So we started Troubleshoo4ng by isola4ng the issue. It turns out that the issue occurred for all non-‐windows Receivers that they tested like Android and Mac. Also we no4ced that it worked on the first launch but when launching addi4onal sessions which we determines the issue only occurs when session sharing. Also we determined that it occurs from any method of launching the session, Internal, External, Web Interface or StoreFront.

59

It was preiy clear that this was not a Network issue, so we went right to the CDF Traces. We also collected client side logs which I will show you how to do in the next sec4ons, but they were not useful in this case. We gathered a CDF Trace with both a Successful and Failed launch and found the Host Launch Request marking the launching of the session. A few messages later in the successful trace, we could see the long command parameter being sent, which was a URL for Internet Explorer.

60

In the bad launch of the trace, we were able to locate the Host Launch Request and then no4ced that the Long Command Parameters was NULL therefore not gesng sent into the session.

61

With this data, the developer found a defect in all non-‐windows Receivers. We fixed the problem in each of these plagorms and the Long Command Line parameter now gets properly sent into the session during every launch.

Advanced Logging for the Citrix Receiver for iOS

62

Citrix introduced Advanced Logs to the Receiver for iOS in version 5.7. This is a first edi4on of this tracing so there are improvements to come. Advanced Logs are based of AeTracing or Advanced Extensible Tracing. It produces an interpreted plain text log file that you can look at with any text editor. Each log entry includes a Time and Date stamp and each message will also be one of the following Types – INFO, WARN, VERBOSE, or ERROR. ERROR messages are clearly something to pay aien4on to. You may see this par4cular applica4on Significant Time Change warning whenever there is new ac4vity in the Receiver aeer some 4me. So this message appears at the beginning of any logging ac4vity.

63

Enabling the Advanced Logs is done from the Sesngs of the Receiver.

64

To access the Receiver Sesngs, click on the gear icon in the top right corner. Next Click on the Advanced op4on and enable or disable the Advanced Logs by toggling the ON/OFF switch. Simply as that.

65


66


67

Run the failing condi4on on the Receiver for iOS while the Log is enabled, and then collect the logs. The Advanced Logs are stored in the Shared Documents sec4ons of the Citrix Receiver on the iOS device. There are two ways to get those logs from the Receiver. From the Receiver Sesngs, you can send an email that includes a compressed archive of all the Advanced Logs on the device as well as some version informa4on about your device.

68

From the Sesngs icon on the Receiver, click on Send Feedback at the boiom and then Request Help from Support.

69

Here you can see the email that pops up with your device informa4on and the logs aiached in a zip.

70

Or you can get the Advanced Logs from the Shared Documents sec4on of a synced iTunes. Here is a very brief video on what that looks like. <PLAY> Once the device is synced to the PC or Mac, you will see the Receiver in the File Sharing sec4on of the Apps tab. Highlight the Log folder and Save As. Then pull up a Finder window and open the Logs directory and there you will see a series of Advanced Logs files.

71

Or you can get the Advanced Logs from the Shared Documents sec4on of a synced iTunes. Here is a very brief video on what that looks like. <PLAY> Once the device is synced to the PC or Mac, you will see the Receiver in the File Sharing sec4on of the Apps tab. Highlight the Log folder and Save As. Then pull up a Finder window and open the Logs directory and there you will see a series of Advanced Logs files.

72

Couple of items to note regarding Advanced Logs. The Advanced Logs will get disabled aeer you use the Send Feedback feature. So you must re-‐enable them to collect more. This feature will send all the logs on the device in a compressed archive So it is important to know approximately when the issue has occurred to help find the right log file. There are a couple of common keywords that you can look for that may indicate a problem. ERROR is a popular one, you will see NOT oeen in errors and FAIL occasionally.

73

Make sure that you are not trying to use an unsupported feature. You can ALWAYS look at the Citrix Client Feature Matrix located here. This document is frequently updated and it the final word on supportability.

74

Advanced Logs Messages

77

The user in this case discovered the Store configura4on by entering an email address. This prompted a ChangeStore message that indicates the Store configura4on has been saved on the Receiver.

78

Here we have a user enumera4ng applica4on from Web Interface. you may see this Get Mobile App Enum for Store messages duplicated and that is normal, Here you can see some of the metadata contained in that message

79

Next we have a user that has selected a Published Desktop icon that was already enumerated from the XenApp Farm. You will see the App Clicked message.

80

This is how the ICA File appears in the Advanced Logs. You will see a “The ICA” message for that.

81

These are the messages that you may see when the Session starts to launch, the Set Session View messages.

82

You can find the Session Width in the Advanced Logs if you are dealing with a Display issue.

83

This can be very useful because oeen connec4on issues occur while the No4fica4ons are running by and the user can tell where it has failed. You will see the series of Launch Status Messages.

84

Here is a message that you hope to see, it is a successful session loaded message and yes that successful typo does appear in the message.

85

This update video out message appears whenever the user changes the view away from the ICA Session into the Receiver main area or some other applica4on.

86

And finally, this a the session close down messages when a user Disconnects the session.

87

Another important thing to know is how to get an Applica4on dump if the Receiver crashes. iOS uses CrashReporter to collect crash dumps. The Crash report includes the Stack Trace which is one of the more cri4cal parts of the dump. The crash report is located in the following loca4ons from an iTunes synced PC, Mac or Windows.

88

To Summarize the data Collected from Receiver for iOS, the Advanced Logs come in a zip of text files. Since this zip includes all the logs files on the device , it is important to get the 4me and date that the issue occurred in thorough Repro Steps

89


90


91


92

If a crash occurred provide the .crash and .log file.

93

If a crash occurred provide the .crash and .log file.

94

This is the key Diagnos4c Data from the Receiver for iOS.

95

Case study 2,Problems connec4ng through Citrix Access Gateway

96

97

In this Case, iPad users were able to enumerate their XenDesktops but unable to connect to them through Access Gateway Users from Receiver for Windows were able to access their Desktops through AG The issue only occurred for Access Gateway connec4ons, Internal iPad users were able to connect. On the Netscaler they were using FIPS and the SHA2 cer4ficate was on the iPad.

98

What debug data can we collect in this case? Looking at the State of the VDA from the Console, there was no indica4on of the connec4on aiempt on the VDA. Therefore a CDF Trace from the VDA would not be useful. So we gathered Advanced Logs from the iPad device.

99

In the Advanced Logs we could see this host error 183 – You have not chosen to trust “Entrust Cer4fica4on Authority” the issuer of the server’s security cer4ficate. So this tells me that it appears that the cer4ficate is not trusted on the device. We checked the device and no4ced that the cer4ficate was trusted on the device

100

So next we checked the Citrix Client Feature Matrix and no4ced that FIPS 140/SHA2 is not supported with iOS. FIPS/SHA2 was recently added to the Windows and Mac Receivers and it is on the roadmap for support in the Receiver for iOS later this year.

Case Study 3 Receiver for iOS disconnect issues

101

102

In this case the iOS Receiver has causing problems reconnec4ng to a disconnected session that 4med out. What we had observed was if you let the session 4me out on an iPad and then aiempt to click on the applica4ons that appears successfully enumerated, we would see the following session expired message. the problem only occurred on iOS, really Android was the only comparable scenario in this case. And it only happened with Access Gateway Connec4ons.

103

For this issue, we obtained an Advanced Log from the iPad Receiver and it show the App no longer available message.

104

We discovered a problem in the way we were caching the users creden4als on the Receiver. We fixed this issue in version 5.7 of the iOS Receiver and aeer authen4ca4on 4mes out the user returns to the logon screen instead of gesng an error.

Receiver for Android Logging.

105

LogCat is Android’s inherent logging system, which allows for collec4ng and viewing of system debug output. LogCat uses the Log class. The Receiver for Android always outputs debug messages to LogCat by default. The output is a plain text file readable file. and it does contain a 4me stamp, although with some logging u4li4es you must enable 4me stamps. Some problema4c keywords that you may find in a Logcat log are ERROR, FAIL and FATAL EXCEPTION for crashes, which we will talk about more shortly.

106

There are several priority tags that are used to indicate the kind of message. These are the tags in priority order.

107

There are two ways of gathering Logcat logs from an Android device. we have made it very simply to collect and send just the Logcat regarding Citrix by Clicking on the Sesngs dots in the top right corner. The second way is a bit more cumbersome and will also include Logcat messages for all products running on the Android device and that is with a third party u4lity.

108

There are two ways of gathering Logcat logs from an Android device. we have made it very simply to collect and send just the Logcat regarding Citrix by Clicking on the Sesngs dots in the top right corner. The second way is a bit more cumbersome and will also include Logcat messages for all products running on the Android device and that is with a third party u4lity.

109

Sending LogCat logs from the Receiver is from the Sesngs -‐> Send Feedback buion. Click on Request help from Support.

110

Sending LogCat logs from the Receiver is from the Sesngs -‐> Send Feedback buion. Click on Request help from Support.

111

That will popup an email with the single Logfile included as an aiachment

112

This Send Feedback feature will also collect informa4on about the Android device that it was sent from

113

You can see it will provide versioning informa4on including that of the Citrix Receiver

114

The second way to gather LogCat logs from Android is with a third party u4lity like aLogcat.

115

You can use aLogcat for collec4ng LogCat logs from an Android device. It uses Regular Expression filtering with ANDs and ORs. A filter for Citrix Receiver issues is simply com.citrix. and you can also send the logs directly from aLogcat via email or ShareFile or more.

116

Citrix Receiver in an LogCat log.

118

Here a user discovers a StoreFront configua4on via email so you see the Discovery document URL.

119

Next a user successfully logging on to a Services Site. You will see a Authen4ca4on successful message.

120

Next these onLoadResource messages is what you will see in the LogCat when a Web Interface Site is loading on a Receiver for Android

121

Next you will see the Download ICA File and Launch Engine Task message at the beginning of the ICA session launching from StoreFront

122

Here is the ICA session launch from a Service Site and you will see the common Download ICA File and Launch Engine Task message followed by the URL and in this case you can see it is a PNAgent or Services Site URL

123

This message can me a liile misleading but this Process Citrix Receiver wfica has died message does appear on a graceful user disconnect.

124

Finally, unlike iOS the Stack Trace is included in the LogCat if the Receiver does crash. We are also working on improving the log messaging from the Android Receiver so we will see more relevant messages in the future.

125

Data Collected from Receiver for Android, the LogCat log. And again Repro Steps with the 4me and date that the issue occurred. The stack trace of any crashes will be included in that log.

126

Data Collected from Receiver for Android, the LogCat log. And again Repro Steps with the 4me and date that the issue occurred. The stack trace of any crashes will be included in that log.

127

The last Case Study – Unknown error connec4ng from Android through an Access Gateway site.

128

129

The user is able to launch a session successfully the first 4me, but the second aiempt failed with the following Access Gateway error message. The problem only occurred on Android Receiver and only aeer the first successful connec4on.

130

First we verified with network with a network trace and nothing out of the ordinary appeared. Then we gathered aLogcat log while this issue occurred. and no4ced the is Receiver 403 response from gateway authen4ca4on error

131

We had discovered a defect in the handling of the authen4ca4on in the Receiver for Android. This issue was fixed in the 3.1.2 version of the Receiver and the user no longer experienced the issue

Wrap it up!

132

133

For common Citrix Connec4on issues, Isolate the reproduc4on, Separate the failing components and gather the appropriate data. Don’t forget to note the important metadata, like IP Addresses for Network traces. Focus on diagnos4c data from a working and non-‐working scenario.

134

Great new Logging feature have been added to the Citrix Mobile Receivers that have made it quick and easy. They output readable messages. Find for the start of the ICA Session by looking for these messages

135

Search for some of the more problema4c keywords. And then search the same ques4onable messages in working logs to determine if they are normal messages. Take note of the concise and thorough steps taken to reproduce the issue and include 4ming markers when collec4ng data. And Finally if you need more help, zip up the network traces, CDF Traces, Receiver Logs and Repro info and send it into Citrix Technical Support. We this data in hand, we will certainly have a huge head start in gesng to the boiom of your issue.

All Resources: Troubleshoo4ng Citrix Receiver for Mobile Devices hip://support.citrix.com/ar4cle/CTX125533 How to Record a Network Packet Trace on a NetScaler Appliance hip://support.citrix.com/ar4cle/CTX128655 Case Study: Troubleshoo4ng ICA Session Disconnec4on with CDF and Network Traces hip://support.citrix.com/ar4cle/CTX113251 How to Enable and Collect Advanced Logs for Receiver for iOS hip://support.citrix.com/ar4cle/CTX136380 Case Study: Unable to Launch Applica4ons from Android Device hip://support.citrix.com/ar4cle/CTX131827 Receiver for Android Troubleshoo4ng hip://support.citrix.com/proddocs/topic/receiver-‐android-‐33/android-‐receiver-‐admin-‐troubleshoo4ng.html Receiver for iOS Troubleshoo4ng hip://support.citrix.com/proddocs/topic/receiver-‐ios-‐57/ios-‐receiver-‐admin-‐troubleshoo4ng.html Enable STA Logging hip://support.citrix.com/ar4cle/CTX120589

136

Web Interface tracing hip://support.citrix.com/ar4cle/CTX122427 How to Decrypt SSL and TLS Traffic using Wireshark hip://support.citrix.com/ar4cle/CTX116557 How to Take a Network Trace on a Netscaler or Citrix Access Gateway Enterprise Edi4on Appliance hip://support.citrix.com/ar4cle/CTX114018 How to Capture a Nstrace from the Command Line Interface in Release 9.2 and 9.3 hip://support.citrix.com/ar4cle/CTX120941 How to Record a Network Packet Trace on a Netscaler Appliance (GUI driven) hip://support.citrix.com/ar4cle/CTX128655 How to Decrypt Traces Recorded on a Netscaler Appliance hip://support.citrix.com/ar4cle/CTX118266 How to Export and use SSL Session Keys to Decrypt SSL Trace Without Sharing the SSL Private Key hip://support.citrix.com/ar4cle/CTX135889 CDFControl hip://support.citrix.com/ar4cle/CTX111961 Citrix Scout hip://support.citrix.com/ar4cle/CTX130147 hip://support.apple.com/kb/ht4094 hip://www.raywenderlich.com/1948/how-‐integrate-‐itunes-‐file-‐sharing-‐with-‐your-‐ios-‐app

137

troubleshooting and debugging citrix receiver for ios and android

Technology