Client Session Health Check - Diagnostics and troubleshooting guide
Summary
To receive a detailed client diagnostic report, create a client support/log file bundle and then submit this bundle to the PCoIP health check tool. Once the files are submitted, it will take 5-10 minutes to produce a detailed report. The report will be sent to your registered e-mail address.
Client session health check are available for Zero Clients and PCoIP Software Clients (Mac, Windows and Linux).
Client Session Diagnostics Summary
|
||||||||
|
Diagnostic Details
Broker Certificate Validation
Shows the status of your client certificate check with the Broker or Connection Manager. Diagnostic returns:
Pass: | Certificate presented to the client was verified and is trusted |
Warning: | Certificate presented to the client failed the verification step. The CM/Broker is not trusted |
Fail: | Certificate was not presented to the client. |
Data Collected:
BROKER : verify_server_pbp result is PASSED | BROKER : verify_server_pbp result is FAILED_BUT_WARNABLE |
Corrective Actions (if diagnostic does not pass)
|
||||
|
Implementation Details:
Category:
This diagnostic is checked at pre-session time.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
- Step 1: Find certificate result. See log pattern (a) or (b)
- Timeout: Not Applicable.
Time Period:
- The diagnostic starts time is associated with Step 1. The end time is associated with Step 1.
Example (a) The PcoIP logs will show the following when the client was able to successfully open a secure channel with the remote server/host:
LVL:2 RC: 0 BROKER :Status: Connecting
LVL:2 RC: 0 BROKER :verify_server_pbp result is PASSED, pre=TRUE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[1]=0
LVL:2 RC: 0 BROKER :verify_server_pbp result is PASSED, pre=TRUE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[0]=0
The PCoIP logs also show the certificate details as provided by the server/host:
LVL:2 RC: 0 CERTIFICATE :(scnet_client_open_ssl): Certificate sent by the Janus server to open the SSL connection: LVL:2 RC: 0 CERTIFICATE : --> Signature Algorithm: sha256WithRSAEncryption LVL:2 RC: 0 CERTIFICATE : --> Issuer: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=jt LVL:2 RC: 0 CERTIFICATE : --> Not Before: May 13 04:30:19 2020 GMT LVL:2 RC: 0 CERTIFICATE : --> Not After : May 13 04:30:19 2021 GMT LVL:2 RC: 0 CERTIFICATE : --> Subject: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=*.domain.local LVL:2 RC: 0 CERTIFICATE : --> Subject Public Key Info: LVL:2 RC: 0 CERTIFICATE : --> Public Key Algorithm: rsaEncryption LVL:2 RC: 0 CERTIFICATE : --> RSA Public-Key: (3072 bit) LVL:2 RC: 0 CERTIFICATE : --> keyid:26:C5:60:A5:CA:C2:E4:8B:AD:22:40:BD:86:8A:59:A0:2E:F8:5E:32 LVL:2 RC: 0 CERTIFICATE : --> CA:TRUE LVL:2 RC: 0 CERTIFICATE : --> Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment LVL:2 RC: 0 CERTIFICATE : --> email:test@mycompany.com LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded LVL:2 RC: 0 SCNET :(scnet_client_open): Connected to 10.0.158.109:4172
Example (b) of the PcoIP logs when the client certificates are unknown or not valid:
LVL:2 RC: 0 BROKER :Status: Connecting
LVL:2 RC: 0 BROKER :Unknown CA detected in chain
LVL:2 RC: 0 BROKER :verify_server_pbp result is FAILED_BUT_WARNABLE, pre=FALSE sys=FALSE hn=TRUE kl=TRUE ocsp=TRUE sscl=FALSE error[0]=29
Session Initialization ("Hello" and "Hello-resp")
Shows when a session establishment is initiated. The diagnostic returns:
Pass: | Client initiates a session and successfully receives the expected response. |
Fail: | Client attempts to initiate a session but does not successfully receive a valid response. |
Data Collected:
Session Initialized by |
Corrective Actions (if diagnostic does not pass)
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (Start Pattern): Find the "Hello" message being sent out See log pattern (a) or (d) OR if the broker cannot be found. Log pattern (f)
- Step 2 (End Pattern): Find the "Hello" response being received. See log pattern (b) or (e).
- Timeout: Step 2 must be within 3 seconds of Step 1.
- Notes area should capture the name of the client and the name of the broker. See log pattern (a)/(d) and (b)/(e)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found then the end time should be the same as found in step 1.
Example (a) Hello Message (software client)
LVL:2 RC: 0 BROKER :Sending XML: ------------------------- LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:Teradici Windows Soft Client LVL:2 RC: 0 BROKER :XML:20.10.2 LVL:2 RC: 0 BROKER :XML:PCoIP LVL:2 RC: 0 BROKER :XML:en_US LVL:2 RC: 0 BROKER :XML:client.example LVL:2 RC: 0 BROKER :XML:xx:xx:xx:xx:xx:xx LVL:2 RC: 0 BROKER :XML:my-client LVL:2 RC: 0 BROKER :XML:xx:xx:xx:xx:xx:xx LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:CAP_DISCLAIMER_AUTHENTICATION LVL:2 RC: 0 BROKER :XML:CAP_NO_AUTHENTICATION LVL:2 RC: 0 BROKER :XML:CAP_DIALOG_AUTHENTICATION LVL:2 RC: 0 BROKER :XML:CAP_ALTERNATE_PROVISIONING LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:xx.xx.xx.xx LVL:2 RC: 0 BROKER :XML:my-client LVL:2 RC: 0 BROKER :XML:
Example (b) Hello Response (software client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------ LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:"PCoIP Broker" LVL:2 RC: 0 BROKER :XML:v30.844.0.2.8a7338d97b LVL:2 RC: 0 BROKER :XML:"Ubuntu 18.04 LTS"; LVL:2 RC: 0 BROKER :XML:en_US LVL:2 RC: 0 BROKER :XML:CHANGE_ME LVL:2 RC: 0 BROKER :XML:Broker.example; LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:PCoIP Connection Manager LVL:2 RC: 0 BROKER :XML:UNKNOWN LVL:2 RC: 0 BROKER :XML:GNU/Linux x86_64 LVL:2 RC: 0 BROKER :XML:xx.xx.xx.xx LVL:2 RC: 0 BROKER :XML:>cm1.example</hostname> LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:AUTHENTICATE_VIA_PASSWORD LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:test.domain LVL:2 RC: 0 BROKER :XML:
Example (d) Hello Message (Zero Client)
LVL:2 RC: 0 MGMT_PCBCSI:build_hello_request: Organization ID string is empty!
Example (e) Hello Response (Zero Client)
LVL:2 RC: 0 MGMT_PCB:Expected hostname: 20.72.244.135
Example (f) Hello Error Response (Zero Client)
LVL:1 RC:-500 MGMT_PCBCSI:tera_socket_client_connect failed with addr=20.72.244.135:443! LVL:1 RC: 260 MGMT_PCBCSI:socket error on connect: Operation timed out! LVL:1 RC:-500 MGMT_SSL:tera_mgmt_ssl_close_connection: session_id(3) has no connections! LVL:1 RC:-500 MGMT_PCBCSI:tera_mgmt_ssl_close_connection failed (ssl_session_id: 3) LVL:1 RC:-500 MGMT_SSL:tera_mgmt_ssl_close_connection: session_id(3) has no connections!
Example (g) Broker Error Response (software client)
LVL:2 RC: 0 QUERYBROKER :No PCoIP broker found on port 443, retrying on port 60443.
Session Authentication ("authenticate" and "authenticate-resp")
Shows the results of the session authentication phase. If MFA is enabled, The diagnostic returns:
Pass: | Client user successfully authenticated. |
Warning: | Client user tried to authenticate but was denied. |
Fail: | Client user tried to authenticate but did not receive a response. |
Data Collected:
User authenticated successfully. |
Corrective Actions (if diagnostic does not pass)
|
||||
|
||||
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (start Pattern): Find the "Authenticate" message being sent out. See log pattern (a) or (d)
- Step 2 (end Pattern) : Find the "Authenticate" response being received. See log patten (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes area should show the result string of the Authentication step. See log pattern (b)/(e)
- Notes area should also show if "MFA" was used. See log pattern (f) or (g). If found, add text to the notes to indicate MFA is enabled.
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) Authenticate Message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: ***** LVL:2 RC: 0 BROKER :XML:***** LVL:2 RC: 0 BROKER :XML:test.domain LVL:2 RC: 0 BROKER :XML:
Example (b) Authenticate Response Message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:AUTH_SUCCESSFUL_AND_COMPLETE LVL:2 RC: 0 BROKER :XML:User authenticated successfully. LVL:2 RC: 0 BROKER :XML:
Example (c) authenticate Error Response (Soft Client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------ LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:1 RC:-500 BROKER :Authentication: User authentication failed. Please re-enter username, password, and/or domain.. LVL:2 RC: 0 BROKER :Error: User authentication failed. Please re-enter username, password, and/or domain.LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:AUTH_FAILED_UNKNOWN_USERNAME_OR_PASSWORD LVL:2 RC: 0 BROKER :XML:User authentication failed. Please re-enter username, password, and/or domain. LVL:2 RC: 0 BROKER :XML:
Example (d) Authenticate Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:mgmt_pcb_fsm_transition_next_auth:Transition into OPEN + AUTH_VIA_PASSWORD
Example (e) Authenticate Response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 41 into AUTHORIZED.RESOURCE_QUERY
Example (f) Authenticate error response (Zero Client)
LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 44 into OPEN
Example (g) MFA enabled(Soft Client)
LVL:2 RC: 0 TBD
Example (h) MFA enabled (Zero Client)
LVL:2 RC: 0 TBD
Get a list of hosts ("get-resource-list" and "get-resource-resp")
Shows the results of the the client asking for the remote hosts that are configured as possible targets. The diagnostic returns:
Pass: | There are 1 or more hosts that are configured as available for the client. |
Fail: | There are 0 configured possible target host machines available to the client. |
Data Collected:
Resource List was retrieved successfully. | User has not been assigned any remote workstations |
Corrective Actions (if diagnostic does not pass)
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1 (start pattern): Find the "get-resource-list" message being sent out. See log pattern (a) or (d)
- Step 2 (end pattern): Find the "get-resource-list-resp" response being received. See log pattern (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes area should show the result string in the "get-resource-list-resp" message. See log pattern (b)/(e)
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) get-resource-list Message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:PCOIP LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:DESKTOP LVL:2 RC: 0 BROKER :XML:
Example (b) get-resource-list-resp message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:LIST_SUCCESSFUL LVL:2 RC: 0 BROKER :XML:Successfully retrieved the list of resources LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:Desktop_1 LVL:2 RC: 0 BROKER :XML:6043f61ff6cdce5b1437f0e8 LVL:2 RC: 0 BROKER :XML:DESKTOP LVL:2 RC: 0 BROKER :XML:UNKNOWN LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:PCOIP LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:Desktop_2 LVL:2 RC: 0 BROKER :XML:6043f60d3837b460dc3c0ed7 LVL:2 RC: 0 BROKER :XML:DESKTOP LVL:2 RC: 0 BROKER :XML:UNKNOWN LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:PCOIP LVL:2 RC: 0 BROKER :XML:
Example (c) get-resource-list-resp Error Response (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:LIST_FAILED_NO_ENTITLEMENT LVL:2 RC: 0 BROKER :XML:User has not been assigned any remote workstations LVL:2 RC: 0 BROKER :XML:
Example (d) get-resource-list Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:Called mgmt_pcb_fsm_transition_get_resource_list LVL:3 RC: 0 MGMT_PCB:NOT_AUTHORIZED.PASSWORD_AUTH: Transition 41 into AUTHORIZED.RESOURCE_QUERY
Example (e) get-resource-list response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_QUERY: Transition 51 into AUTHORIZED.RESOURCE_SELECT
Example (f) get-resource-list-resp Error Response (Zero Client)
LVL:1 RC: 0 MGMT_PCB:Error 21: User has not been assigned any remote workstations
Is host ready? ("allocate-resource" and "allocate-resource-resp")
Shows the results of the the client asking for to connect to a specific remote host. The diagnostic returns:
Pass: | Selected host is ready to accept a connection. |
Fail: | Selected host is not ready for a connection. |
Data Collected:
Resource was allocated successfully. Name Name= |
Corrective Actions (if diagnostic does not pass)
|
||||
|
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "allocate-resource" message being sent out. See log pattern (a) or (d)
- Step 2: Find the "allocate-resource-resp" response being received. See log patten (b) or (e).
- Timeout: Step 2 must be within 5 seconds of Step 1.
- In the notes area, the result of the response
and the should be added. See log pattern (b)/(e).
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) allocate-resource Message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: 6043f60d3837b460dc3c0ed7 LVL:2 RC: 0 BROKER :XML:PCOIP LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:Pacific Standard Time LVL:2 RC: 0 BROKER :XML:10.12.34.151 LVL:2 RC: 0 BROKER :XML:02:f0:1e:43:4d:68 LVL:2 RC: 0 BROKER :XML:
Example (b) allocate-resource-resp Message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:ALLOC_SUCCESSFUL LVL:2 RC: 0 BROKER :XML:Successfully allocated remote workstation LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:20.72.244.135 LVL:2 RC: 0 BROKER :XML:Desktop_1 LVL:2 RC: 0 BROKER :XML:pcoip-default-sg-sni LVL:2 RC: 0 BROKER :XML:4172 LVL:2 RC: 0 BROKER :XML:2305843009213693952 LVL:2 RC: 0 BROKER :XML:SCS1*****o9+xsC22iJ0A LVL:2 RC: 0 BROKER :XML:6043f60d3837b460dc3c0ed7 LVL:2 RC: 0 BROKER :XML:PCOIP LVL:2 RC: 0 BROKER :XML:
Example (c) allocate-resource-resp Error Response (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:ALLOC_PENDING_TRY_AGAIN LVL:2 RC: 0 BROKER :XML:Remote workstation swin-0 is starting, Please try to connect again in a few minutes LVL:2 RC: 0 BROKER :XML:
Example (d) allocate-resource Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_QUERY: Transition 51 into AUTHORIZED.RESOURCE_SELECT
Example (e) allocate-resource response Message (Zero Client)
LVL:3 RC: 0 MGMT_PCB:AUTHORIZED.RESOURCE_SELECT: Transition 52 into AUTHORIZED.START_SESSION
Pre-Session Completed ("bye" and "bye-resp")
Shows the results of the the client completing the pre-session phase. The diagnostic returns:
Pass: | Session setup was completed |
Data Collected:
Pre-session completed |
Implementation Details:
Category:
This diagnostic is checked at pre-session phase.
Implementation Steps:
- Step 1: Find the "bye" message being sent out. See log pattern (a) or (c)
- Step 2: Find the "bye-resp" response being received. See log patten (b) or (d).
- Timeout: Step 2 must be within 5 seconds of Step 1.
Time Period:
- The diagnostic starts time is associated with Step 1.
- The end time is associated with Step 2 or if step 2 pattern is not found, then end time should be step 1.
Example (a) Bye message (Soft Client)
LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: LVL:2 RC: 0 BROKER :XML:
Example (b) Bye message and bye-resp (Soft Client)
LVL:2 RC: 0 BROKER :Received XML: ------------------------ LVL:2 RC: 0 BROKER :XML:LVL:2 RC: 0 BROKER :XML: ... LVL:2 RC: 0 CLIENT :Pre-session processing complete-----------------> LVL:2 RC: 0 BROKER :XML:
Example (c) Bye message and bye-resp (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:Sending BYE APDU to peer
Example (d) Bye message and bye-resp (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:NEGOTIATED: Received BYE_OK, resetting channel
Tablet Info
Peripheral Device (Tablet Info)
Shows the connected Wacom tablet model name and connection mode.
Pass: | Wacom tablet is connected with supported connection mode |
Note: | Wacom tablet is connected with unsupported connection mode/Partially supported connection mode |
Data Collected:
Wacom tablet model name and connection mode
Corrective Actions (if diagnostic does not pass)
Note:
1 | The Intuos Pro Medium PTH-660 and Intuos Pro Large PTH-860 models are connected in Bridged Mode, while they support Local Termination mode. |
2 | The PCoIP Graphics Agent for macOS does not support any Wacom Tablet models connected in Local Termination mode, except for the Intuos Pro Medium PTH-660 and Intuos Pro Large PTH-860. |
3 | The PCoIP Graphics Agent for macOS does not support Wacom Tablet models connected in Bridged Mode. |
Please find the below link for Wacom Tablet Support models for both Local Termination and Bridged Mode
- Supported Wacom tablets for Windows Client
- Supported Wacom tablets for Linux Client
- Supported Wacom tablets for MacOS Client
Reference links: Which PCoIP products support Wacom devices?
Implementation Details
Category:
This diagnostic is checked at Pre-session.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
Step 1. Look for the Wacom tablet is connected. See log pattern (a) and Pattern (b)
Time Period:
The Time Period for both the start and end of the diagnostic is the time found for step 1.
Example (a): If a Wacom tablet is connected with local Termination supported, logs will contain this line:
2023-06-22T09:57:30.885Z a63d7300-f310-103b-98da-000000000000 LVL:2 RC: 0 MGMT_USB :HoIP supported device detected (Vid: 0x056a, Pid: 0x0357), using HoIP protocol for local termination
Example (b): If a Wacom tablet is connected with Bridged mode supported, logs will contain this line:
2023-06-23T10:50:42.775Z b2ddcc00-f3e1-103b-a18a-000000000000 LVL:2 RC: 0 MGMT_USB :Device detected - HoIP not supported - (Vid: 0x056a, Pid: 0x0357), using URBoIP protocol for local termination
Host Certificate Validation
Shows the status of your certificate. Diagnostic returns:
Pass: | Certificate was successfully verified |
Warning: | Certificate was not successfully verified |
Data Collected:
TBD |
Corrective Actions (if diagnostic does not pass)
|
||||
|
Implementation Details:
Category:
This diagnostic is checked at session time.
Once the first diagnostic is displayed, subsequent matches should only be displayed if the value changes from the previous displayed value.
Implementation Steps:
- Step 1: Find certificate result. See log pattern (a) or (b)
- Timeout: Not Applicable.
Time Period:
- The diagnostic starts time is associated with Step 1. The end time is associated with Step 1.
Example (a) The PcoIP logs will show the following when the client was able to successfully open a secure channel with the remote server/host:
LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded
The PCoIP logs also show the certificate details as provided by the server/host:
LVL:2 RC: 0 CERTIFICATE :(scnet_client_open_ssl): Certificate sent by the Janus server to open the SSL connection: LVL:2 RC: 0 CERTIFICATE : --> Signature Algorithm: sha256WithRSAEncryption LVL:2 RC: 0 CERTIFICATE : --> Issuer: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=jt LVL:2 RC: 0 CERTIFICATE : --> Not Before: May 13 04:30:19 2020 GMT LVL:2 RC: 0 CERTIFICATE : --> Not After : May 13 04:30:19 2021 GMT LVL:2 RC: 0 CERTIFICATE : --> Subject: C=in,ST=mh,L=pune,O=teradici,OU=gss,CN=*.domain.local LVL:2 RC: 0 CERTIFICATE : --> Subject Public Key Info: LVL:2 RC: 0 CERTIFICATE : --> Public Key Algorithm: rsaEncryption LVL:2 RC: 0 CERTIFICATE : --> RSA Public-Key: (3072 bit) LVL:2 RC: 0 CERTIFICATE : --> keyid:26:C5:60:A5:CA:C2:E4:8B:AD:22:40:BD:86:8A:59:A0:2E:F8:5E:32 LVL:2 RC: 0 CERTIFICATE : --> CA:TRUE LVL:2 RC: 0 CERTIFICATE : --> Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment LVL:2 RC: 0 CERTIFICATE : --> email:test@mycompany.com LVL:2 RC: 0 SCNET :(scnet_validate_by_thumbprint_hash): thumbprint hash comparison succeeded LVL:2 RC: 0 SCNET :(scnet_client_open): Connected to 10.0.158.109:4172
Example (b) of the PcoIP logs when the client certificates are unknown or not valid:
LVL:1 RC:-500 CERTIFICATE :verify_certificate: Certificate 10.0.158.109 fails verification
Establish Payload
Shows the results of the the client establishing a PCoIP connection with the host. The diagnostic returns:
Pass: | Selected host has accepted the connection. |
Fail: | Connection could not be established. |
Data Collected:
N/A | Session established successfully to |
Corrective Actions (if diagnostic does not pass)
|
Implementation Details:
Category:
This diagnostic is checked at session phase.
Implementation Steps:
- Step 1: Find the message being sent out. See log pattern (a) and (c)
- Step 2: Find the message being acknowledged. See lot pattern (e) and (g)
- Timeout: Step 2 must be within 5 seconds of Step 1.
- Notes should show the hostname of the session that was established (if established)
Time Period:
- The diagnostic starts time is associated with Step 1
- The diagnostic end time is associated with Step 2
Example (a) TCP-Handshake is successful (Soft Client)
LVL:2 RC: 0 CLIENT :Pre-session processing complete-----------------------------------
LVL:2 RC: 0 CLIENT :In-session processing begins -------------------------------------
Example (b) TCP Error Response (Soft Client)
LVL:2 RC:-500 SCNET :(scnet_client_open_ssl): tera_sock_connect failed to connect to 10.0.158.122:4172!
LVL:2 RC:-500 SCNET :(scnet_client_open_ssl): tera_sock_connect returned error 10060 - Connection timed out!
LVL:1 RC:-500 SCNET :(scnet_client_open): Failed to connect to 10.0.158.122:4172
LVL:1 RC:-500 MGMT_SCHAN :SCDAT: master_ready(): Failed scnet_client_open
Example (c) TCP-Handshake Successful (Zero Client)
LVL:3 RC: 0 MGMT_PCBCSI:create_socket_tcp succeeded
Example (d) Error Response (Zero Client)
LVL:2 RC: 0 MGMT_SSIG:Session timeout (192.168.1.95)!
LVL:1 RC: 260 MGMT_SCHAN:SCNET: master_ready(): Failed tera_socket_client_connect, will retry...
Example (e) UDP-Invite (Soft Client)
2021-02-17T23:18:40.589Z 5c40cd00-53a4-1039-a9e8-000000000000 LVL:0 RC: 0 MGMT_SYS:Session Port found as '4172' 2021-02-17T23:18:40.589Z 5c40cd00-53a4-1039-a9e8-000000000000 LVL:0 RC: 0 MGMT_SYS:Session Addr found as '10.0.158.45'
Example (f) UDP-Invite Response Error (Soft Client)
LVL:1 RC:-504 MGMT_PCOIP_DATA :Invite packet not acknowledged, aborting session
Example (g) UDP-Invite (Zero Client)
LVL:3 RC: 0 MGMT_SSIG:Sending INVITE APDU to peer
LVL:3 RC: 0 MGMT_SSIG:Received INVITE_OK APDU from: 20.72.244.135
LVL:3 RC: 0 MGMT_SSIG:Sending ACK APDU to peer
Example(h) UDP-Invite Response Error (Zero Client)
LVL:3 RC: 0 MGMT_SESS:(pcoip_data_cback): event: 0x4, PRI: 0 - queuing EVENT_PCOIP_DATA_OPEN_TIMEOUT LVL:2 RC: 0 MGMT_SYS:Session unavailable reason: 0x00001002
Disconnect session
When a PCoIP session disconnects, it is logged so that any spontaneous disconnects can be addressed and fixed.
Shows when and why a client disconnects from a PCoIP session. The note provided will explain how to interpret the disconnect cause.
Note: | Disconnection are normal events that are usually initiated by the user of the client. Disconnects can happen due to the user requesting a disconnect or due to a remote host powering down or the network disconnecting. This diagnostic will provide a reason code. To read more about different disconnect causes, refer to Meaning of disconnect causes |
Corrective Actions (if diagnostic does not pass)
|
Data Collected:
disconnect cause: X |
Implementation Details:
Category:
This diagnostic is checked during the session phase.
Implementation Steps:
- Step 1: Find the disconnect message. See log pattern (a) or (b)
- Step 2: If (a) or (b) cannot be found, then find the time when the session ID is no longer being used.
Time Period:
- The diagnostic starts time and end time is associated with the log found in Step 1 or the log associated with Step 2.
Example (a) Disconnect Message (Soft Client)
LVL:2 RC: 0 COMMON :TERA_PCOIP: SESSION_EVENT=TERA_MGMT_SYS_SESS_EVENT_RESET, disconnect cause: 768
Example (b) Disconnect message (Zero Client)
LVL:2 RC: 0 TBD