SUM405: Troubleshooting and Debugging Receiver for iOS and Android

SUM405: Troubleshooting and Debugging Receiver for iOS and Android
Christian Suarez Sr. Escalation Engineer May 21, 2013 Hello and Welcome to Troubleshooting and Debugging Receiver for iOS and Android. This presentation will show you the tools and data that can be used to help resolve problems in the Receivers for iOS and Android.

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

Why Now? 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!

A fast growing, rapidly changing mobile market
Source: Gartner (January 2012) Source: Gartner (September 2011) 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.

Mobility is top priority for organizations
And a big challenge for IT! Mobility is a top priority for organizations AND the employees. And it is a BIG challenge for IT.

How do you find the problem?
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 exciting new and convenient tracing methods to both the iOS and Android Receivers.

Citrix Mobile Infrastructure
Devices Network Web Resources StoreFront Access Gateway Third Party VPN Web Interface With all the combinations of products or network devices between your Mobile Receivers and your critical business applications and desktops, First, understand the infrastructure design to help narrow down the problem. These are the major components considered in this presentation. The Mobile Receivers: iOS and Android, the Network and Web components: Netscaler, Storefront and Web Interface, and your business resources like XenApp published applications and XenDesktop machines. See the big picture and ISOLATE the issue by determining which connection scenarios the problem does and does not occur. Next, SEPARATE the network layers from the applications layer by checking out the network traffic. Then, GATHER and INVESTIGATE the key diagnostic data from the applications layers. Here is how to get the most useful data from the XenDesktops and XenApp Servers and the Mobile Receivers.

Agenda NEW! Network and ICA Connection Troubleshooting
Advanced Logs on Receiver for iOS Logcat with Receiver for Android Wrap it up! Questions NEW! The Agenda: Start with common Network and ICA Connection troubleshooting steps. This section can be applied to connection issues from any Citrix Receiver. Look at Network Traces, useful Event Logs and CDF Tracing. In the next section, 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 sections, cover some Case Studies. Wrap it up and provide some references.

Network and ICA Connection Troubleshooting
Get started with Network and ICA Connection Troubleshooting

Isolate the Issue Detailed Reproduction Steps XenApp / XenDesktop?
Resources Detailed Reproduction Steps XenApp / XenDesktop? It is a common practice in identifying an issue is to ISOLATE the problem to a specific scenario. Does the issue occur for XenApp and XenDesktop connections?

Isolate the Issue Reproducible Environment XenApp / XenDesktop
Web Reproducible Environment XenApp / XenDesktop StoreFront / Web Interface / Services Site StoreFront Is there a difference if the user connects from StoreFront, Web Interface, or a Services Site? Web Interface Services Site

Isolate the Issue Reproducible Environment XenApp / XenDesktop
StoreFront / Web Interface / Services Site User-based or Device-based Frequency of the Issue Is the issue occurring for a specific user base? Or certain devices only? How often does the issue occur? Every time? 1 out of 10 times? Or the second time only?

Detailed Reproduction
Repro Steps Clear Sequential Repro Steps with timing (Start Tracing at 6:09pm on 4/2) Logon to WI from Browser at 6:10 Launch XenApp Desktop at 6:11 Expected Behavior Hear Windows logon sound Unexpected Behavior Cannot hear Windows logon sound at 6:12 It is very important to get clear, sequential steps that a user takes to reproduce the problem and include approximate times while collecting 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.

External Reproduction
Complex backend or proprietary software Provide Store Account configuration Test user account Security Token requirements present a challenge If the infrastructure is too complex or requires a proprietary software backend, may rely on an External Reproduction, 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 solution the fastest. We would ask for the StoreFront or Account configuration, 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 still work with you.

Test Other Citrix Receivers
Previous Receiver Possible Regression Beta / EAP Receiver Already Fixed From Browser or Receiver Android vs iOS Windows Receiver 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 contacting Citrix. A Beta version will help determine if we have already resolved the issue. Determine if the issue occurs when launching the connection from the Device’s Browser or within the configured Receiver. Also the iOS and Android Receivers have a relatively common feature set, so it is good to know if it happens with both of these platforms. 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.

Network Troubleshooting
Checking the Network Netscaler AG- VPN or ICA Proxy? Other VPN Local Users or External Users only 3/4G or Wireless Network Single or Dual Authentication Public or Private CA Certificates Intermediate Certificate on the Gateway Access Gateway Next, check out the Network connection, 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 platforms does the issue occurs from both the 4G network and from a Wi-fi connection? Since Authentication is often done on the network devices, is single or dual authentication? Certificates tends to be a common set back with the Receivers. Have a public or private certificate? Is the private certificate on the end device? Is the intermediate certificate on the Gateway device? Also, ensure using a supported certificate or authentication method. Third Party VPN

Network Troubleshooting
Identify Network devices within the connection Look for unique or custom configurations or design Check for third party logs or tracing Identify Closest Working Scenario Collect Working and Non-working Network Traces Preparing for Network traces, note the IP Addresses of all the network devices used for the connection. Look for any unique or custom configurations. Check for logging in any Third Party products used for the connection. And identify the closest working scenario. Then, if suspect that there may be something wrong at the Network level, Collect working and non-working Network Traces.

ICA Enumeration and Connection
ICA is Citrix’s primary TCP Protocol ICA wrapped in CGP / Session Reliability – 2598 Determine Enumeration or Connection Authentication in Enumeration Session Launch in Connection Create Account/Store in Mobile to Enumerate Enumerate via Web Interface each time Launch App or Desktop from Browser or Receiver Specific to the Citrix ICA Connection, ICA is Citrix’s primary TCP Protocol and it uses port Session Reliability uses CGP over 2598, which is basically a reliability buffer around ICA. It is good to determine if your issue occurs during enumeration or the connection attempt. Authentication issues may occur during Enumeration The connection issues occur during the Session launch. With the Mobile Receivers, the enumeration occurs during the initial authentication. With Web Interface enumeration occurs each time. and the App can be launch from the Desktop browser or from the Receiver.

Network Traces Analysis Tips
Finding the ICA Session Filter by Regular Expressions tcp.port == 1494 || tcp.port == 2598 ip.addr == && ip.addr == Network Traces Analysis- Here are some quick analysis tips 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. Identify the Citrix connections by filtering on ports 1494 and If you have the IP information of the client and server, filter on the IP addresses to view the entire conversation.

Finding the ICA Session Filter by Regular Expressions tcp.port == 1494 || tcp.port == 2598 ip.addr == && ip.addr == Add Name Resolution Use Display Time Format A nice feature in Wireshark from readability is to add a common name to the IP Addresses or allow the automatic Name Resolution if on the internal network. For timing or performance issues, it helps to set the Time Format to something more readable.

Finding the ICA Session Find TCP Handshake – SYN, SYN-ACK, ACK Use Follow TCP Stream Verify the ICA Sounder Once formatted and filtered the output, find the beginning of the ICA conversation. This can be done by looking for the TCP Handshake – SYN, SYN/ACK, and ACK. These three messages start every TCP/IP network connection. Once the ICA conversation is found, use Follow the TCP Stream and then identify the ICA Sounder, which shows up as 7F 7F in the data.

Identifying Issues Time issue occurred during trace Use Expert Info Features Look for Network Saturation Look for Retransmissions and Resets Find which side of conversation initiates the problem Compare with a working trace After finding the ICA network traffic, look for the most common problems. One method of finding the problem is to simply use the timing of the failed behavior. Perhaps the issue occurs 5-10 seconds after the beginning of the connection attempt 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 identify Network Saturation, 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 conversation initiated the drops. Look at the trace of a working scenario to identify differences. Use at these clues from the trace analysis to determine if any particular node within the network connection is causing a problem and then try to confirm by eliminating or avoiding that component.

Network Traces with Netscaler AG
nstrace.sh command with nsroot access Secure Shell (SSH) access with tool like PuTTY or Secure Console Secure Copy (SCP) download with tool like WinSCP or SFTP Netscaler’s Web Console Start new trace under System-> Diagnostics Decrypt a SSL Trace with Private Key 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 utilizing the nstrace command. Or a trace can be gathered from the Netscaler web console under System Diagnostics, select Start new trace. Dealing with Secure traffic, to decrypt an SSL Trace obtain the Private Key. See CTX for further details.

Other Data for ICA Connection Issues
Event Logs of XenApp or XenDesktop host Licensing Issues Authentication Issues Event Logs of Authenticating Server Web Interface or XML Broker STA Logs in CtxSta.config for Ticketing Issues Enable Web Interface tracing in web.config file IIS Logs for Web Site issues Some other data to collect for ICA Connection Issues. First check the System and Application Event Logs for your XenApp Server or XenDesktop host. Could discover Licensing issues or Authentication issues indicated there. Check the Event Logs of the Authenticating Server, whether it is the Web Interface Server or the XML Broker. For ticketing 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 Articles that you need for these steps in this slide deck. Receiver for iOS Troubleshooting Enable STA Logging Web Interface tracing

Citrix Diagnostic Facility (CDF) Traces
Key Citrix Diagnostic Data requires parsing CDF is based off Event Trace for Windows (ETW) Providers, Controllers and Consumers Identify which XenApp Server to Trace Citrix XenApp Server and XenDesktop Host Session Launching issues Zone Data Collector and XML Broker Application Enumeration or Load-Balancing issues Citrix Diagnostic 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 utility (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 hosting the application or the XenDesktop VDA. If you are dealing with Application enumeration or Load-balancing issues, trace all IMA/XML modules on the Zone Data Collector and XML Brokers.

Capturing CDF Traces Steps to gather CDF Traces
Citrix Diagnostic Facility Steps to gather CDF Traces Scout - CTX130147 CDF Control – CTX111961 Use Circular Traces for Intermittent issues Provide Citrix Technical Support with .etl trace file There are a couple of Citrix utilities that can be used to gather a CDF Trace file while the issue occurs, Scout and CDF Control. Both of these utilities will provide Tracing Categories of Citrix modules to enable specific to the issue. For issues that are intermittent or hard to reproduce, leave a circular CDF trace running, until the issue occurs and then collect the etl file. While we do not recommend leaving CDF Traces running under normal operating 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.

CDF Trace Demo A Demo of the CDF Control utility 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 utility on the VDA from our KB at CTX This will download a compressed zip file of the executibles 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 utility around. Here are the Options for the ways to gather the trace file, like that circular log I mentioned 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 time but if you are in doubt select All Modules. You can also Clear All Selected. And you can select multiple 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.

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

Data Collected Network Traces – .pcap Network IP Info
CDF Traces - .etl Repro Info The CDF Trace come in a etl file along with the repro steps during that collection. Here is the files and Good reproduction steps with times added.

CDF Traces - .etl Repro Info Event Logs - .csv And finally include the other important logs like Application and System Event Logs of the appropriate servers.

CDF Traces - .etl Repro Info Event Logs - .csv This is some of the key Diagnostic Data from the Network and Server-side for any ICA Connection issues

LongCommandLine parameter fails for iOS and Android
Case Study #1 First Case Study!

Case Study #1 Troubleshooting Occurs on Receivers for iOS, Android and Mac not Windows Occurs only when session sharing Happens from Local, External, Web Interface or Storefront ICA FILE … [IE] Address= :1494 InitialProgram=#IE LongCommandLine= ClientAudio=On AudioBandwidthLimit=1 In this Case, the Long Commmand Line Parameter which allows you to send an argument, like an http page or file to the published application was failing intermittently from the iOS Receiver. So we started Troubleshooting by isolating the issue. It turns out that the issue occurred for all non-windows Receivers that they tested like Android and Mac. Also we noticed that it worked on the first launch but when launching additional 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.

Case Study #1 Debugging Obtained CDF Traces with successful and failed launch Found launch attempts with Enter:HostLaunchRequest() Successful launch It was pretty 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 sections, 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.

Case Study #1 Debugging Obtained CDF Traces with successful and failed launch Found launch attempts with Enter:HostLaunchRequest() Failed launch In the bad launch of the trace, we were able to locate the Host Launch Request and then noticed that the Long Command Parameters was NULL therefore not getting sent into the session.

Case Study #1 Results Discovered defect in all non-windows Receivers Fixed for iOS, Android, Linux and Mac ICA FILE … [IE] Address= :1494 InitialProgram=#IE LongCommandLine= ClientAudio=On AudioBandwidthLimit=1 With this data, the developer found a defect in all non-windows Receivers. We fixed the problem in each of these platforms and the Long Command Line parameter now gets properly sent into the session during every launch.

Advanced Logs for Receiver for iOS
Advanced Logging for the Citrix Receiver for iOS

Introduction to Advanced Logs on iOS
Advanced Logs introduced in Receiver for iOS 5.7 AeTracing – Advanced Extensible Tracing Plain Text Log File Time and Date Stamp - dd-mm-yyyy hh:mm:ss Message Types- INFO, WARN, VERBOSE, ERROR Citrix introduced Advanced Logs to the Receiver for iOS in version 5.7. This is a first edition 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 attention to. You may see this particular application Significant Time Change warning whenever there is new activity in the Receiver after some time. So this message appears at the beginning of any logging activity.

Enabling Advanced Logs
Enable Advanced Logs in the Receiver Settings Enabling the Advanced Logs is done from the Settings of the Receiver.

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

Two Ways of Gathering Advanced Logs
Send Feedback and Request Help from Support From Synced iTunes under File Sharing Run the failing condition on the Receiver for iOS while the Log is enabled, and then collect the logs. The Advanced Logs are stored in the Shared Documents sections of the Citrix Receiver on the iOS device. There are two ways to get those logs from the Receiver. From the Receiver Settings, you can send an that includes a compressed archive of all the Advanced Logs on the device as well as some version information about your device.

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

Here you can see the that pops up with your device information and the logs attached in a zip.

From Synced iTunes under File Sharing
Or you can get the Advanced Logs from the Shared Documents section 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 section 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.

Advanced Logs Advanced Logs disabled after Send Feedback
Find Issue within all compressed Advanced Logs Keywords to search for issues ERROR NOT FAIL Couple of items to note regarding Advanced Logs. The Advanced Logs will get disabled after 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 often in errors and FAIL occasionally.

Supportability for Citrix Receivers
See the Citrix Receiver Feature Matrix ents/products/citrix-receiver-feature-matrix.pdf 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.

Supportability for iOS
iOS Receiver Admin Troubleshooting Workspace control feature is not supported Connecting with a proxy is not supported Applications might open in different sessions Limited Support for Session Reliability ✗ 2598/CGP ✗ Client Buffer ✔ Session Freeze

Advanced Logs Messages

Discover Store config by email
Advanced Logs Analysis VERBOSE: -[CRLaunchPadViewController changeStore:] The user in this case discovered the Store configuration by entering an address. This prompted a ChangeStore message that indicates the Store configuration has been saved on the Receiver.

Enumerating Apps from Web Interface
Advanced Logs Analysis INFO: -[StoreManager getMobileAppEnumForStore Here we have a user enumerating application 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

Select Published Desktop icon
Advanced Logs Analysis VERBOSE: -[CRLaunchPadViewController appClicked:] 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.

Published Desktop ICA File
Advanced Logs Analysis INFO: -The ICA: [Encoding] This is how the ICA File appears in the Advanced Logs. You will see a “The ICA” message for that.

ICA Session begins Advanced Logs Analysis INFO: setSessionViewWasShown
These are the messages that you may see when the Session starts to launch, the Set Session View messages.

ICA Session Display Settings
Advanced Logs Analysis INFO: Session Width: You can find the Session Width in the Advanced Logs if you are dealing with a Display issue.

User Notification Messages
Advanced Logs Analysis INFO: updateLaunchStatus: statusMessage: This can be very useful because often connection issues occur while the Notifications are running by and the user can tell where it has failed. You will see the series of Launch Status Messages.

Session successfully loaded
Advanced Logs Analysis INFO: Settings succesfully loaded for session view 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.

Receiver returns to main screen
Advanced Logs Analysis INFO: updateVideoOut 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 application.

User Disconnect Session
Advanced Logs Analysis VERBOSE: closeSession: And finally, this a the session close down messages when a user Disconnects the session.

iOS Receiver crash dump
iOS uses CrashReporter .crash report includes Stack Trace Located on Synced iTunes machine Mac - ~\Library\Logs Win - \AppData\Roaming\Apple computer\Logs\CrashReporter\ Another important thing to know is how to get an Application 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 critical parts of the dump. The crash report is located in the following locations from an iTunes synced PC, Mac or Windows.

iOS Data Collected Advanced Logs - .zip of .txt Repro timing info
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 time and date that the issue occurred in thorough Repro Steps

Crash Reporter - .crash and .log If a crash occurred provide the .crash and .log file.

Crash Reporter - .crash and .log This is the key Diagnostic Data from the Receiver for iOS.

iPad users are unable to connect through Access Gateway
Case Study #2 Case study 2,Problems connecting through Citrix Access Gateway

Case Study #2 Troubleshooting Occurs with iOS but not Windows Receivers Only through Access Gateway not for Internal Users SHA2 Certificates are on the device 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 connections, Internal iPad users were able to connect. On the Netscaler they were using FIPS and the SHA2 certificate was on the iPad. Access Gateway

Case Study #2 Debugging No connection attempt from VDA, so no CDF Traces Advanced Logs captured during the failure What debug data can we collect in this case? Looking at the State of the VDA from the Console, there was no indication of the connection attempt on the VDA. Therefore a CDF Trace from the VDA would not be useful. So we gathered Advanced Logs from the iPad device.

Case Study #2 Debugging You have not chosen to trust "Entrust Certification Authority - L1C", the issuer of the server's security certificate. In the Advanced Logs we could see this host error 183 – You have not chosen to trust “Entrust Certification Authority” the issuer of the server’s security certificate. So this tells me that it appears that the certificate is not trusted on the device. We checked the device and noticed that the certificate was trusted on the device

Case Study #2 Results Checked the Citrix Client Feature Matrix FIPS/SHA2 Security is a Limitation in the Receiver for iOS So next we checked the Citrix Client Feature Matrix and noticed 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.

iOS Receiver disconnects issues after timeout
Case Study #3 Case Study 3 Receiver for iOS disconnect issues

Case Study #3 Troubleshooting Occurs only on Receivers for iOS Only happens with Access Gateway connections In this case the iOS Receiver has causing problems reconnecting to a disconnected session that timed out. What we had observed was if you let the session time out on an iPad and then attempt to click on the applications 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 Connections.

Case Study #3 Debugging Obtained Advanced Logs from iOS Receiver This app is no longer available from the server or you are no longer permitted to access it For this issue, we obtained an Advanced Log from the iPad Receiver and it show the App no longer available message.

Case Study #3 Results Discovered defect caching the credentials on the Receiver Fixed the code and the user now returns to logon screen after timeout We discovered a problem in the way we were caching the users credentials on the Receiver. We fixed this issue in version 5.7 of the iOS Receiver and after authentication times out the user returns to the logon screen instead of getting an error.

Logcat with Receiver for Android Receiver for Android Logging.

Introduction to LogCat on Android
Android uses LogCat to dump system debug output Using Android’s Log class Android Receiver always sends output to LogCat Plain Text Log File Time and Date Stamp - dd-mm-yyyy hh:mm:ss Problematic Keywords: ERROR, FATAL EXCEPTION, FAIL LogCat is Android’s inherent logging system, which allows for collecting 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 time stamp, although with some logging utilities you must enable time stamps. Some problematic keywords that you may find in a Logcat log are ERROR, FAIL and FATAL EXCEPTION for crashes, which we will talk about more shortly.

Logcat Message Tags V/ - verbose D/ - debug I/ - informational
W/ - warning E/ - error F/ - fatal S/ - silent There are several priority tags that are used to indicate the kind of message. These are the tags in priority order.

Two Ways of Gathering LogCat on Android
Send Feedback and Request Help from Support From Third Party Utility 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 Settings 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 utility.

Collect LogCat from Receiver for Android
Send Feedback and Request Help from Support Sending LogCat logs from the Receiver is from the Settings -> Send Feedback button. Click on Request help from Support.

Collect LogCat from Receiver for Android
Request Help from Support That will popup an with the single Logfile included as an attachment

Request Help from Support Email
Send Feedback This Send Feedback feature will also collect information about the Android device that it was sent from

Request Help from Support Email
Send Feedback You can see it will provide versioning information including that of the Citrix Receiver

Two Ways of Gathering LogCat on Android
From LogCat utility aLogcat The second way to gather LogCat logs from Android is with a third party utility like aLogcat.

aLogcat on Android Logcat utility
aLogcat is a third party app for collecting LogCat logs Regular expression filtering com.citrix&E/ Citrix Receiver filter com.citrix Send logs from aLogcat , ShareFile and more You can use aLogcat for collecting 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 or ShareFile or more.

Supportability of Receiver for Android
Android Receiver Admin Troubleshooting Color depth limitation for sessions Workspace control feature is not supported Connecting with a proxy is not supported Full Support for Session Reliability ✔ 2598/CGP ✔ Client Buffer ✔ Session Freeze

LogCat Messages Citrix Receiver in an LogCat log.

Discover StoreFront LogCat Analysis Discovery document URL=
Here a user discovers a StoreFront configuation via so you see the Discovery document URL.

Successful Logon from Services Site
LogCat Analysis Authentication successful Next a user successfully logging on to a Services Site. You will see a Authentication successful message.

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

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

Begin ICA Launch from Services Site
LogCat Analysis DownloadIcaFileAndLaunchEngineTask 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

User Disconnects ICA Session
LogCat Analysis Process com.citrix.Receiver:wfica This message can me a little misleading but this Process Citrix Receiver wfica has died message does appear on a graceful user disconnect.

Android Receiver crash dump
Android dump Stack Trace in LogCat - /E 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.

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

Unknown Error from Android connecting through AG the second time
Case Study #3 The last Case Study – Unknown error connecting from Android through an Access Gateway site.

Case Study #3 Troubleshooting Occurs only on Receivers for Android Occurs after one successful connection The user is able to launch a session successfully the first time, but the second attempt failed with the following Access Gateway error message. The problem only occurred on Android Receiver and only after the first successful connection. Access Gateway

Case Study #3 Debugging Network Traces checked out Obtained LogCat from Android Receiver Receiver 403 response from gateway… 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 noticed the is Receiver 403 response from gateway authentication error

Case Study #3 Results Defect discovered in Android Receiver Resolved in Receiver for Android 3.1.2 We had discovered a defect in the handling of the authentication in the Receiver for Android. This issue was fixed in the version of the Receiver and the user no longer experienced the issue Access Gateway

Wrap it up! Wrap it up!

Citrix Connection Troubleshooting
Isolate Reproduction for Data Collection Separate failing components Gather and Investigate Diagnostic Data Event Logs, Network Traces Citrix CDF Tracing Note the IP info during Network Traces Focus on Working vs. Non-working Data For common Citrix Connection issues, Isolate the reproduction, 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 diagnostic data from a working and non-working scenario.

Logging for iOS and Android
Mobile Receiver logging is quick and easy Readable text messages Search logs for ICA Session Starting Point iOS- VERBOSE & CRLaunchPadViewController Android- CTX|CITRIX|RECEIVER.COM 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

Logging for iOS and Android
Search logs for problematic keywords iOS- ERROR, NOT, FAIL Android- ERROR, FAIL, FATAL EXCEPTION Search questionable messages in working logs Provide Concise Repro Steps Collect details and data for Citrix Technical Support Search for some of the more problematic keywords. And then search the same questionable 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 timing markers when collecting 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 getting to the bottom of your issue.

Resources Troubleshooting Citrix Receiver for Mobile Devices How to Record a Network Packet Trace on a NetScaler Appliance Case Study: Troubleshooting ICA Session Disconnection with CDF and Network Traces How to Enable and Collect Advanced Logs for Receiver for iOS Case Study: Unable to Launch Applications from Android Device All Resources: Troubleshooting Citrix Receiver for Mobile Devices How to Record a Network Packet Trace on a NetScaler Appliance Case Study: Troubleshooting ICA Session Disconnection with CDF and Network Traces How to Enable and Collect Advanced Logs for Receiver for iOS Case Study: Unable to Launch Applications from Android Device Receiver for Android Troubleshooting Receiver for iOS Troubleshooting Enable STA Logging Web Interface tracing How to Decrypt SSL and TLS Traffic using Wireshark How to Take a Network Trace on a Netscaler or Citrix Access Gateway Enterprise Edition Appliance How to Capture a Nstrace from the Command Line Interface in Release 9.2 and 9.3 How to Record a Network Packet Trace on a Netscaler Appliance (GUI driven) How to Decrypt Traces Recorded on a Netscaler Appliance How to Export and use SSL Session Keys to Decrypt SSL Trace Without Sharing the SSL Private Key CDFControl Citrix Scout

Before you leave… Recommended related breakout sessions:
SUM212: How to create a fabulous user experience with Citrix Receiver SUM604: Enterprise mobility planning and design workshop Conference surveys are available online at starting Friday, May 24 at 9:00 a.m. PT Provide your feedback by 4:00 p.m. PT that day and you’ll receive a $30 Amazon.com gift card via Download presentations starting Monday, June 3, from your My Conference Planning tool located within the My Account section

Tweet about this session with #SUM405 and #CitrixSynergy

Questions & Answers Questions and Answers

SUM405: Troubleshooting and Debugging Receiver for iOS and Android

Similar presentations

Presentation on theme: "SUM405: Troubleshooting and Debugging Receiver for iOS and Android"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

SUM405: Troubleshooting and Debugging Receiver for iOS and Android

Similar presentations

Presentation on theme: "SUM405: Troubleshooting and Debugging Receiver for iOS and Android"— Presentation transcript:

Similar presentations

About project

Feedback