# Troubleshooting

# Device Reset Guide

A reset cuts power to one part of a Kuori unit and lets it start again. It is the remote equivalent
of pulling a plug, and it fixes the class of fault where a component has stopped responding but the
hardware is fine.

Resets act on real equipment at a real site. A reset during opening hours puts a screen out for the
time it takes to boot. Read the rest of this page before you send one.

## Where to find them

Two places, doing the same thing.

The **Manage** button on any row of the device list opens the reset commands directly.

![The Manage menu open on a device row, listing the five reset commands](https://wiki.kuori.com/uploads/images/gallery/2026-09/devices-manage-menu.png)

The **Management** tab on a device's own page has the same five as buttons, plus scheduling.

![The Management tab, with the five reset buttons](https://wiki.kuori.com/uploads/images/gallery/2026-09/VGtdevice-tab-management.png)

## The rules

Three of them, and they matter more than knowing which button is which.

Send one reset at a time. After each one, wait five minutes for the component to restart before
you decide whether it worked. Resets are only possible while the device is online.

When you do not know which one you need, work through them in this order and stop as soon as the
symptom clears:

**Mediaplayer → LCD Driver → Modem (if reachable) → Host → SMB**

That order runs from the least disruptive to the most. The last two take the whole unit down for a
boot cycle.

## The five targets

**Reset Mediaplayer** restarts the separate media player computer that handles signage playback.
Use it when content is stuck, playback has frozen, scheduled media does not start, or the signage
software is not responding. Give the player time to boot and reconnect before you judge the result.
This is the most common reset and the least disruptive.

**Reset LCD Driver** restarts the display driver interface between the media player and the screen.
Use it when the display is black, flickering, frozen, showing artifacts, or otherwise visually
corrupted while the device itself still looks like it is running. It targets the display path
without rebooting the whole system.

**Reset Modem** restarts modem and router control to recover unstable connectivity. Use it only
when the device is still reachable but the connection is poor, meaning high latency, intermittent
drops, or unstable remote access. A device that is fully offline cannot be helped this way, because
the command travels over the very connection that is down.

**Reset Host** restarts the SMB host, normally the Android board, and the DSM client running on it.
Use it when the host side is unstable, the client is unresponsive, or the targeted resets above did
not fix it. This takes the device offline for a while.

**Reset SMB** restarts the System Management Board, which controls core hardware functions such as
the fans, the heater, reboot control, and temperature supervision. Use it when hardware control is
not reacting normally, or the device seems electrically or thermally unstable. The SMB is also what
performs the other four resets, which is why it comes last. It is the right move when the client
reports SMB disconnected while the device is otherwise online, meaning the client is running but
cannot reach the board.

## Sending one

1. Check the device is online. The status badges on the device page, or the Online dot in the list,
   tell you.
2. Pick the target.
3. Confirm.

![The confirmation dialog before a reset is sent](https://wiki.kuori.com/uploads/images/gallery/2026-09/reset-confirmation.png)

DSM confirms that the command was sent. That means DSM handed it to the device, not that the reset
worked. Wait five minutes, then check the device's Events tab and its status badges. An SMB reset
shows up as an event naming the reason the board restarted.

## Offline devices

Every reset is disabled for an offline device, and DSM says so rather than letting you click a
button that would do nothing.

![The Management tab of an offline device, with every command disabled](https://wiki.kuori.com/uploads/images/gallery/2026-09/G9Xdevice-offline-management.png)

There is no way around this, and it is the right behaviour. A reset is a message to a device, and an
offline device is not listening. If a device is offline and stays offline, DSM has done what it can
and the site needs a visit.

## Scheduling a reset

Under **Scheduled commands** on the Management tab, **New schedule** sets a reset to run at the same
time every day.

![The Add schedule dialog, with a time and a reset command type](https://wiki.kuori.com/uploads/images/gallery/2026-09/reset-schedule-dialog.png)

Pick a time and a reset command type, then save. A nightly media player reset is a reasonable way to
live with a player that drifts over a few days.

The schedule runs on the device's own timezone, which the tab shows above the button. If that
timezone is wrong or unset, fix it on the Settings tab first. A schedule set to 03:00 against the
wrong timezone will reset a screen in the middle of the trading day.

Schedules can be saved for an offline device. They start once it reconnects.

Scheduled commands need client version 0.4.20 or newer, and they are not available on Windows
devices. DSM tells you when the client is too old.

## Which reset to try

When the symptom points somewhere specific, start there rather than at the top of the order. Wait
five minutes after each attempt before moving to the next column.

| Symptom | Try first | Then |
| --- | --- | --- |
| Content stuck or frozen, playback not starting | Reset Mediaplayer | Reset Host |
| Display black, flickering, or showing artifacts | Reset LCD Driver | Reset Host |
| Connection poor, latency high, dropping in and out | Reset Modem | Reset Host |
| DSM client unresponsive, host unstable | Reset Host | Reset SMB |
| Device online but SMB disconnected | Reset SMB | Site visit |
| Fans, heater, or temperatures behaving oddly | Reset SMB | Site visit |
| Device fully offline | Nothing. Resets need the connection | Site visit |

## When a reset is not the answer

Repeat resets on the same device are a symptom, not a fix. If a unit needs a daily reset to stay
usable, log it in the device's Notes and raise it with Kuori. The Display health tab and a per-day
Offline report will show you the pattern, and that pattern is what makes the case for a hardware
swap.

A reset also cannot help with content. If the playlist is wrong, resetting the media player
reloads the same wrong playlist.

# Firewall rules and encryption (DSM)

Use this guide to diagnose connectivity problems between a device and DSM. Most connection failures trace back to blocked outbound traffic, DNS/NTP issues, or overly restrictive network filtering.

## Quick Checklist

Before digging deeper, confirm the basics:

- [ ] Device has general outbound internet access
- [ ] Required ports below are open outbound
- [ ] DNS resolution is working
- [ ] Device clock is in sync (NTP)
- [ ] No IP/domain whitelisting is restricting traffic
- [ ] MDM-specific firewall rules are in place
- [ ] Any third-party apps on the device have their own required ports open

## 1. Check Core DSM Firewall Rules

DSM requires the following outbound rules. If any of these are blocked, the client will fail to connect.

| Address | Protocol | Port | Purpose | Symptom if blocked |
|---|---|---|---|---|
| `api2.kuori.com` | TCP | 443 | HTTPS REST calls | Client can't reach API, requests time out or fail |
| `api.kuori.com` | TCP | 443 | WebSocket (WSS) | Client connects briefly but loses real-time/live connection |
| DNS servers | UDP/TCP | 53 | Name resolution | Client can't resolve `kuori.com` hostnames at all |
| NTP servers | UDP | 123 | Time synchronization | TLS handshake fails or auth errors due to clock drift |

**How to check:** Test outbound connectivity from the device/network to each address and port (e.g. `curl`, `telnet`, or a port-check tool). If DNS resolution fails, verify port 53 is open and a working DNS server is reachable. If TLS handshakes fail intermittently, check the device clock against NTP.

## 2. Check MDM-Specific and android rules

The MDM solution in use has its own required firewall openings, separate from the DSM rules above. If the MDM agent itself can't connect, DSM enrollment/management may also fail.

- **MDM firewall rules:** If you are using some other MDM than Kuori Mobile Management(KMM) you need to check their firewall rules, but for KMM they can be found from here: [KMM Firewal rules](https://wiki.kuori.com/books/troubleshooting-Edq/page/firewall-rules-and-encryption-kmm)

Also confirm outbound access is allowed per Android Enterprise requirements, since MDM device management relies on Google-managed services:

- [Android Enterprise Network Requirements](https://support.google.com/work/android/answer/10513641?hl=en) 

## 3. Rule Out Overly Restrictive Network Filtering

**A common root cause of intermittent or unexplained connection failures is IP-based whitelisting.**

IP address–based whitelisting is **not a viable approach** for Android-based devices, and is a frequent cause of connectivity problems that "used to work" and then broke.

Why this happens:

- Devices depend on Google Play and other Google-managed infrastructure, which runs on large, dynamic, globally distributed cloud networks.
- These services' IP addresses change frequently and cannot be reliably predicted or restricted to a fixed range.
- If an allowlist of IPs was configured, it will inevitably go stale as addresses rotate — causing app updates, authentication, or background services to silently fail.

**If you suspect this:** Check whether any firewall/proxy rule is restricting outbound traffic to a specific IP range rather than by port/protocol. If so, replace it with rules based on the ports and domains above, and allow general outbound internet access rather than an IP allowlist.

## 4. Check General Network Configuration

- Outbound traffic should be allowed as per the DSM, MDM, and Android Enterprise requirements above.
- Outbound NTP requests must be allowed.
- Inbound traffic should be blocked except where explicitly required (DSM does not need inbound access).
- Devices should sit within a dedicated IoT VLAN or physically isolated network — confirm the device hasn't been placed on a segment with different (more restrictive) rules.
- If egress filtering is in place, check its logs for blocked outbound attempts from the device — this is often the fastest way to spot the exact rule causing the failure.

## 5. Check Encryption / TLS Requirements

- TLS 1.3 is required for all WSS and HTTPS connections. Older TLS versions or a network appliance forcing a TLS downgrade/inspection can break the handshake.
- DSM uses API key and device ID pairing for authentication — confirm both are correctly provisioned on the device; an invalid pairing can look like a "connection" failure even when the network is fine.

## 6. Check Third-Party Applications on the Device

If other applications on the device also seem to have network issues, they may have their own port/endpoint requirements that are separate from DSM's.

**Example — TeamViewer:**

| Type | Port(s) |
|---|---|
| Outbound TCP | 5938 (primary), 443, 80 |
| Optional UDP | 5938 |

TeamViewer (and similar apps) use dynamic cloud servers, so IP whitelisting will likely break them too. Evaluate each third-party application individually and allow its required outbound ports rather than restricting by IP.

## Summary: Most Likely Causes, In Order

1. A required port (443, 53, or 123) is blocked outbound.
2. IP-based whitelisting is in place and has gone stale or is blocking dynamic Google/cloud IPs.
3. MDM-specific firewall rules haven't been applied (see internal KMM link above).
4. Device clock is out of sync (NTP blocked), breaking TLS handshakes.
5. Device is on the wrong network segment/VLAN with different rules applied.

# Display Status

## Overview

This document describes the inputs used to monitor display backlight status, how they relate to each other, and how DSM (Display Status Monitor) generates alerts from them.

## Inputs

| Input | Source | Single display | Dual display |
| --- | --- | --- | --- |
| bl1\_enable | Controllers page | Used | Used |
| bl2\_enable | Controllers page | Not applicable | Used |
| bl1 (backlight brightness) | Controllers page | Used | Used |
| bl2 (backlight brightness) | Controllers page | Not applicable | Used |
| LCD1Status | Sensors page | Used | Used |
| LCD2Status | Sensors page | Not applicable | Used |

- **bl1\_enable / bl2\_enable** — on/off flags for each display's backlight, read from the Controllers page. A single-display unit only has bl1\_enable; a dual-display unit has both bl1\_enable and bl2\_enable.
- **bl1 / bl2** — backlight brightness values for each display, also read from the Controllers page.
- **LCD1Status / LCD2Status** — Sensors page values indicating whether each display's LCD controller is enabled. A single-display unit only has LCD1Status; a dual-display unit has both LCD1Status and LCD2Status.

## Alert generation

DSM generates alerts based only on the backlight brightness values, bl1 and bl2. If either bl1 or bl2 drops to 0, DSM generates an alert for that display.

The alert text names the affected screen: bl1 = 0 shows "Screen 1 is off", and bl2 = 0 shows "Screen 2 is off".

DSM does not evaluate bl1\_enable, bl2\_enable, or LCD1Status/LCD2Status directly when deciding whether to raise an alert — but as described below, bl1\_enable and bl2\_enable can force bl1/bl2 to 0, which then triggers the alert indirectly.

## Backlight enable behavior

bl1\_enable and bl2\_enable also control the physical backlight, separately from what DSM watches for alerts:

1. bl1\_enable (or bl2\_enable) goes from 1 to 0.
2. The backlight for that display is turned off.
3. The corresponding brightness value, bl1 (or bl2), is also set to 0.
4. Because bl1/bl2 is now 0, DSM generates an alert for that display.

So a bl1\_enable/bl2\_enable transition to 0 always produces an alert, but by way of forcing bl1/bl2 to 0 — the alert itself is still keyed off bl1/bl2, not off the enable flag.

**Typical causes for bl1\_enable/bl2\_enable going to 0:** the upstream picture source (e.g. a media player) crashes, goes to sleep, or intentionally turns the display off.