Heartbeat function not working on ThinOS10 devices properly. Devices lose connection to WMS.

What does

1. Do you have anything in the policy for the group/device in Services, WDA Settings?
   1. Make sure you have "Enable WMS" Turned on, but "Enable Advanced Configuration" off
2. On the thin client
   1. System information, About
      1. What do you see under WMS Status and MQTT Server?
   2. Settings, Central configuration
      1. Does the WMS Server listed match yours?
      2. Is it on-premises or cloud?
      3. If it is on-premises, make sure validate CA is unchecked

1. Do you have anything in the policy for the group/device in Services, WDA Settings? :All default values, DNS/DHCP discover enabled, live updated enabled, defer package update enabled, group change notice enabled, Max timeout 3000ms, noncompliant time 0, retries for download 3, ignore MQTT is OFF.
   1. Make sure you have "Enable WMS" Turned on, but "Enable Advanced Configuration" off: This is how we have the config set
2. On the thin client
   1. System information, About
      1. What do you see under WMS Status and MQTT Server?: WMS status: connecting MQTT: Idle
   2. Settings, Central configuration
      1. Does the WMS Server listed match yours? confirmed matches after multiple attempts and copying from the non-problematic 3040 groups.
      2. Is it on-premises or cloud? on-prem pro.
      3. If it is on-premises, make sure validate CA is unchecked CA is unchecked and also disabled in config everywhere.

Ok, so if your WMS Settings look right, and the status shows connecting and idle it sounds like a communication problem. 

Can you try and ping the name and IP of your WMS Server from Settings>Troubleshooting>Ping?

Is it able to resolve the name of your WMS Server as defined in Settings>Central configuration?

Scott,

Ping resolves out to the WMS server and also internal and external IP's

Trace route also shows all hops completed successfully from client to WMS server.

We had an issues months ago where Palo Alto firewalls were disrupting package downloading in a similar fashion, but we disabled SYN Flood protection to fix this. We did not reenable it and now this is happening very strange turn of events.

It's very odd we don't see this on our 3040 models but on 5470, 7420, and AIO Pro 24. 

What is the difference between them?

What is the build of ThinOS9 and ThinOS 10?

• 3040's are on ThinOS9 2402. their last supported build.
• 5470's on ThinOS9 2411 for compatibility reason with USB devices. our 5470's are too low spec'd for thinOS 10 we learned this later after trying to deploy it to them.
• 7420AIO & AIO Pro 24 are ThinOS10 2502 (2502_10.0052)

I would say try 2505 to see if it is any differnet, then get a case going. 

PM me the SR# so I can look at it.

We have attempted those newer patches with no difference on a few test machines.

Case#: 211590150 it was created about a week ago. Pertinent logs and info for this case are in the ssfd for my email/case. Maybe one of the tech assigned to the case can give you access to the SSFD.

Reading through it now.

So, basically it looks like real time communication, which is the responsibility of MQTT is failing.

Can you confirm.

• ThinOS 10 device, make a change to a policy (Change privilege mode from None to High)
  • Device should get the command right away via MQTT to check in over 443 and get the policy and change
    • Can you confirm it does not get it?
    • Can you confirm sending a message from WMS to the device isnt received right away?
  • Reboot device
    • Policy gets applied as expected?
    • Force Check in via Central configuration setting on thin client, Gets policy as expected?
• On the thin client,   System info, About
  • What do WMS and MQTT Say? Connected?, Idle?

Hi,

Can we get following logs.

C:\Program Files\DELL\WMS\Tomcat-10\logs

localhost_access_log.<YY-MM.DD.txt>

#IWork4Dell