Available Commands in the Sensor CLI Access Window

Shows asset information.

Shows CM Controller IP address and connection status.

Include the heartbeat parameter (that is, show cm heartbeat) to see the status of the sensor's most recent heartbeat to its CM Controller. Use this to confirm that a sensor is still communicating with the CM when troubleshooting connectivity from the sensor console.

The output reports the CM Controller the sensor is communicating with, the status of the last attempt, and the times of the last successful and last failed heartbeats, each with its message ID. For example:

Sensor> show cm heartbeat
Last Heartbeat to CM
   CM Controller           : 10.34.22.100
   Success count           : 0
   Failure count           : 0
   Last status             : FAIL (24 seconds ago, msg id: 17089)
   Last success            : 2026-07-04 15:16:51 UTC (msg id: 17088)
   Last fail              : 2026-07-04 15:17:51 UTC (msg id: 17089)
   (counts since aella_conf last started)

The success and failure counts are reset each time the sensor's aella_conf service restarts. If the sensor has not yet communicated with its CM Controller, the command reports No heartbeat record found.

Include the probe parameter (that is, show cm probe) to test TCP connectivity from the sensor to its configured CM Controller and Aggregator (if any). The command performs a TLS handshake against each target on the specified port(s) and reports each as Reachable or Unreachable, which can help diagnose cases where a firewall is blocking sensor-to-CM or sensor-to-aggregator traffic.

The syntax is as follows:

show cm probe [<port> | all] [<timeout>]

• <port> – One of 6640, 6642, 6644, 6646, or 6648. If omitted, or if you specify all, all five ports are probed.

• <timeout> – Timeout in seconds for each port probe. Defaults to 3 seconds if not specified.

For example:

DataSensor> show cm probe
Probing CM Controller (192.168.11.11):
Port 6640: Reachable
Port 6642: Reachable
Port 6644: Reachable
Port 6646: Reachable
Port 6648: Reachable

Probing Primary Aggregator (172.20.228.14):
Port 6640: Unreachable
Port 6642: Unreachable
Port 6644: Unreachable
Port 6646: Unreachable
Port 6648: Unreachable

Lists background CLI jobs, or shows the status and output of a specific job.

Refer to Running Long-Duration CLI Commands for syntax and examples.

Shows information on Customer Log Parsers, if applied.

Shows MAC and IP address for sensor data port(s) (where data is ingested by the sensor).

Shows actions being taken to limit disk usage.

Shows the IP address of the sensor's DNS server.

Shows deep packet inspection information, including:

• Categorization for different applications

• Memory usage, flow count, and pool usage

Note that the output for this command can be lengthy. Use the all parameter to see all entries in paged output (for example, show dpi all).

You can include the version argument (show dpi version) to see the following additional information:

• DPI Engine version

• DPI Protocol Bundle version

Use show dpi protocol custom metadata to list any user-defined DPI metadata entries that have been added with the set dpi protocol custom metadata command.

Shows information on the number of packets dropped by the sensor broken out by Rx and Tx and interface.

Modular Sensors only. Shows ethtool-equivalent information for a sensor's ethernet interfaces. The syntax is as follows:

show ethtool <interface> [info | driver | stats | features | ring | coalesce | pause | channels]

• info (default) – Link speed, duplex, and status.

• driver – Driver name and version.

• stats – NIC statistics.

• features – Offload feature flags.

• ring – Ring buffer sizes.

• coalesce – Interrupt coalescing settings.

• pause – Pause frame parameters.

• channels – Channel counts.

For example:

Sensor> show ethtool eth0 driver
driver: vmxnet3
version: 1.6.0.0-k-NAPI
firmware-version: 
expansion-rom-version: 
bus-info: 0000:0b:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no

Shows syn flood detection information.

Shows the IP address of the sensor's default gateway.

Modular Sensors only. Shows the sensor's current GRUB net.ifnames setting, which controls whether the sensor's ethernet interfaces use legacy eth-style names or predictable PCI bus names.

For example:

Sensor> show grub
GRUB Configuration
==================
net.ifnames configuration:
/etc/default/grub: net.ifnames=1 (predictable naming scheme (e.g. enpXsY, ...))
/etc/default/grub.d/90-aella-kernel-params.cfg: net.ifnames=1 (predictable naming scheme (e.g. enpXsY, ...))
/boot/grub/grub.cfg: net.ifnames=1 (predictable naming scheme (e.g. enpXsY, ...))

Valid values:
0 - Use legacy naming scheme (e.g. eth0, eth1, ...)
1 - Use predictable naming scheme (e.g. enpXsY, ...)
Run 'restart system' to reboot for changes to take effect after update.

This command is not available on other Device Sensor profiles (for example, security or network sensors) or on Server Sensors.

Shows a timestamped log of the most recent 25 CLI commands that executed actions. Show commands are excluded.

Shows the hugepage_size currently configured for the sensor. Refer to the set hugepage_size entry in the table below for details on what a hugepage is and why you might consider changing it.

Shows the status of the IDS PCAP capture feature on the Modular Sensor. When enabled, this feature captures trace files to the Sensor's storage when an IDS signature match is detected. The show ids output reports whether the IDS PCAP feature is enabled, and, if enabled, the filenames of any saved PCAP files so you can copy them off of the device for further analysis. This command only provides output when used with a virtual 6.0.0+ Modular Sensor with the IDS feature enabled in its Sensor Profile.

Refer to Capturing Trace Files for IDS Signature Matches for more information on enabling and configuring the IDS PCAP feature.

Shows equivalent output of the Linux ifconfig command with status, packets, drops, and bytes Rx and Tx broken out by interface.

If a whitelist is configured for SSH connections to the Management port, allowed IP addresses/ranges appear in the show interface output for the management interface.

Shows information on AFIX IPFIX classification engines.

Shows information on AFIX JSON metadata transfer.

Shows the state of the ldap-metadata feature is enabled (enabled or disabled).

Shows information on the configuration of and records sent by different log collectors.

Shows information on logs received and forwarded, including the following:

• Receiver IP address/hostname and port.

• Status of specific log forwarding features, such as the HTTP JSON Parser, forwarding to an external server, or TLS log forwarding.

• Number of workers provisioned for the sensor by the system.

• Name of custom log forwarder certificate used with the TLS log forwarding feature, if in use.

• The transport protocol used by each incoming log source, reported in the Input section as a record count per protocol (for example, cisco_meraki 5 udp:2 tcp:3). Sources whose protocol cannot be determined are reported as unknown. This helps you identify whether a source is sending over UDP or TCP when troubleshooting ingestion problems.

You can include the all parameter (that is, show logforwarder all) to see additional information, including the Top 5 Error Types sorted by count along with the Start Time for each error type. Counts are provided based on the current td-agent log file and update each time you run the command. This provides quick visibility into frequent td-agent runtime errors without accessing raw logs.

Include the debug parameter to gather live diagnostic information for troubleshooting log ingestion. The command samples traffic for several seconds before reporting, so it takes roughly 15 seconds to complete. The syntax is as follows:

show logforwarder debug [<port>]

Without a port, the command reports all of the following:

• The Top 5 Error Types from the current td-agent log, as also reported by show logforwarder all.

• The firewall redirect rules that map the standard syslog ports (514 and 6514) to their internal parser ports.

• Active ingestion – The source IP addresses actively sending to each parser port during the sampling window, listed separately for UDP and TCP.

• Worker Load Distribution – How records for each source IP and parser port combination are spread across the sensor's log forwarder workers, sorted by record count. A maximum of 200 entries is displayed.

Supply a port to limit the Worker Load Distribution output to a single parser port. For example:

Sensor> show logforwarder debug 5681
Worker Load Distribution(Sorted by Total_Records):
# Show top 2 of 2 entries
Total_Records  Source_IP     Parser_Port  Total_Bytes  Workers  Max_Worker  Min_Worker  Ratio
4              10.36.26.74   5681         4.9K         3/3      #0: 2       #1: 1       2.00x
1              10.36.200.90  5681         1.2K         1/3      #2: 1       -           -

Interpret the Worker Load Distribution columns as follows:

• Workers – The number of workers receiving this source and port combination, out of the total number of workers.

• Max_Worker / Min_Worker – The busiest and least busy worker for this source and port, shown as #N: record count, where N is the worker index.

• Ratio – The Max_Worker record count divided by the Min_Worker record count. The closer this value is to 1.00x, the more evenly the load is balanced across workers.

Include the port-ingestion parameter (that is, show logforwarder port-ingestion) to see how the ingestion ports configured for your Parser Studio – Log Sources are mapped to the sensor's internal parser ports. The output has three parts:

• Port ingestion – A table of the configured mappings, listing the permitted source addresses, the protocol, the ingestion port, and the parser port it redirects to. The parser currently associated with each parser port appears in parentheses, or (inactive) if none is active. The sessions column reports how many sessions are currently established, and the tls column reports whether the mapping accepts TLS.

• Config File – The last modified time and raw contents of the sensor's port ingestion configuration file. An empty configuration is reported as {}.

• Chain PREROUTING – The unparsed firewall rules that perform the redirection, including packet and byte counters for each rule. Use these counters to confirm whether traffic is actually arriving on an ingestion port.

For example (trimmed):

DataSensor> show logforwarder port-ingestion
Current Time: 2026-05-19 05:55:27
Port ingestion
seq  sessions  source  proto  ingest_port  parser_port          tls  hostname
1    1         Any     udp    514          5172(cisco_meraki)  n/a  n/a
2    0         Any     tcp    514          5172(cisco_meraki)  no   n/a
3    0         Any     tcp    443          5151(nginx)       yes  n/a
Config File: Last Modified Time: 2026-05-19 05:43:23
{"3e6e9ace-78ad-43a4-b9f6-800240a08948": {"parser_port": 5172, "ingestion_port": 514, "addresses": ["Any"], "tls": false}, ...}
Chain PREROUTING (policy ACCEPT 142 packets, 28035 bytes)
 pkts bytes target     prot opt in     out    source              destination
    1   458 REDIRECT   udp  --  *      *      !0.0.0.0             0.0.0.0/0            udp dpt:514 redir ports 5172

Include the parser parameter (that is, show logforwarder parser) to see the list of currently enabled Log Forwarder parsers.

Include the tls-cipher-mode parameter (that is, show logforwarder tls-cipher-mode) to see the sensor's current TLS cipher mode (secure or legacy) for TLS log forwarding connections.

Shows the log level for different Stellar Cyber modules. Note that you can also set the log level for different modules from the CLI Access window using the set loglevel command; see the table below.

Shows detailed statistics on malware sandbox usage, including the total number of IDS events broken out by the number of events buffered by the sensor and the number already sent to the DP.

Note: When NFS file assembly is enabled, the output also shows the current NFS Assembly status.

The output also reports the state of the sensor's IDS engine:

• Engine Uptime – How long the engine has been running, or Offline if it is not responding.

• Rules Loaded – The number of signatures loaded, with the number that failed to load. Reports Unavailable when the engine cannot be queried.

• Capture Threads – The number of worker threads attached to interfaces, listed individually with their packet and drop counts.

Capture Threads is the most reliable indicator that the sensor is actually inspecting traffic. The engine loads its ruleset before it starts capturing, so an engine can report a full set of loaded rules — and appear to be running — while no traffic is being inspected at all. A count of 0 means the engine is running but not capturing. Unavailable means the engine is still starting and is not yet a cause for concern.

For example:

Sensor> show maltrace
Engine Uptime   : 0d 2h 16m 17s
Rules Loaded    : 89423 (failed: 0)
Capture Threads: 1
  W#01-eth0     : pkts=177710 drop=0
NFS Assembly   : Disabled

Include the debug parameter (that is, show maltrace debug) to troubleshoot an engine that is not capturing. The output has two parts: the memory limits and throttling applied to the engine, which is reported even when the engine cannot be queried, and the engine's runtime detail, including its version, pattern matcher, interfaces, and drop counters.

The Active MPM line in the debug output identifies the multi-pattern matcher the engine is using. hs (Hyperscan) is expected. Sensors whose engine build does not include Hyperscan fall back to Aho-Corasick and report a warning:

Active MPM       : ac (Aho-Corasick fallback)
  -> WARNING: Hyperscan not in build; MPM degraded to Aho-Corasick (slower, higher memory)

The engine still inspects traffic in this state, but pattern matching is slower and uses more memory, which matters most on sensors with large rulesets or limited RAM. This is a property of the sensor's engine build rather than something you configure; contact Stellar Cyber Customer Success if you see this warning on a sensor where performance is a concern.

Shows the sensor's memory usage, including a Hypervisor Memory section reporting whether the hypervisor is reclaiming memory from the sensor's virtual machine.

When a virtualization host is short of memory, it can reclaim memory from a guest VM using a balloon driver. Reclaimed memory belongs to no process and does not appear in standard memory statistics, so a sensor can run short of memory — and terminate services such as suricata — with no visible cause inside the guest. Use this section to identify that situation. For example:

Sensor> show meminfo
Hypervisor Memory (VMware balloon)
  Balloon Current      : 1595MB
  Balloon Target       : 1952MB
  Ballooned Since Boot : 11197MB (cumulative)
  Guest Uptime         : 30m
  OOM Kills This Boot  : 1 (Suricata-Main x1)
  Status               : ACTIVE - hypervisor is reclaiming guest memory
  Note                 : reserve this VM's memory on the hypervisor

• Balloon Current and Balloon Target – The memory currently reclaimed and the amount the host is asking for.

• Ballooned Since Boot – The cumulative memory reclaimed since the sensor booted. Because a host can inflate and deflate the balloon repeatedly, this total can be large even when the balloon is empty at the moment you run the command.

• Guest Uptime – How long the sensor has been running. Read Ballooned Since Boot against this value: a large total over a few minutes means the host is actively reclaiming memory, while the same total over several weeks is unremarkable.

• OOM Kills This Boot – Processes the kernel terminated because the sensor ran out of memory, with the number of times each was killed.

The Hypervisor Memory section appears only on sensors running under VMware, where the balloon driver reports this detail. On other platforms — including bare metal, KVM, and Proxmox — the section is omitted entirely, which does not by itself indicate that memory is or is not being reclaimed.

If the Status reports that the hypervisor is reclaiming guest memory, reserve the sensor VM's memory on the hypervisor so that it cannot be taken back. Refer to Arguments for the "show" command in the Sensor CLI Access Window for a broader assessment of whether the host or the sensor itself is the constraint.

Low Available Memory Warning

When the memory available for new allocations falls to a small fraction of the sensor's usable memory, show meminfo reports a warning above the rest of the output. For example:

WARNING: only 371MB (6.2%) of memory is available - an allocation spike may reach the OOM killer.
MemAvailable is below MemFree (424MB), so watermark reserves exceed reclaimable cache and most free memory cannot be allocated.

This warning means the sensor is close to the point at which the kernel terminates a process to recover memory. The second sentence appears when available memory has fallen below free memory, which indicates that most of what the sensor reports as free is held in reserve by the kernel and cannot actually be allocated.

Treat the warning as a prompt to find out what is consuming memory. On a VMware sensor, check the Hypervisor Memory section first — memory reclaimed by the host is the most common cause and the least visible one.

Hidden Fields in the Memory Report

The detailed memory statistics end with a line reporting how many fields were hidden, for example (17 zero/constant fields hidden; see /proc/meminfo for all). The sensor omits fields that are always constant, along with fields that are currently zero and only meaningful when they are not. Nothing is hidden that indicates a problem: a field such as HardwareCorrupted or SwapCached is shown as soon as it reports a non-zero value.

Shows information on control and data plane memory availability and usage.

Shows information on the black list of metadata applications (traffic explicitly excluded from ingestion/evaluation in the sensor profile).

Note that the output for this command can be lengthy. The following tips can help you see the entries that interest you:

• Use the all parameter to see all entries in paged output (for example, show metalist all).

• Use a regex filter to exclude aella_log_forwarder entries and see only user-defined applications. For example:

  show metalist regex ^(?!.*aella_log_forwarder).*

  show metalist all regex ^(?!.*aella_log_forwarder).*

Shows the current Maximum Transmission Unit (MTU) setting for each interface on the sensor.

Shows information on configured traffic mirroring.

Modular Sensors only. Shows which modular features are enabled on a modular sensor (for example, log collector, aggregator, Tenable scanner, and so on), as well as its current CPU, RAM, and disk provisioning.

Modular Sensors only. Shows the amount of CPU, RAM, and disk required to support different combinations of modular sensor features.

Modular Sensors only. Shows standard netstat output for the modular sensor's management port.

The syntax is as follows:

show netstat [all | delta | rate] protocol [tcp | udp | all]

• all – returns all statistics available from the Linux kernel.

• delta – returns statistics from the previous time netstat was run, the current value, and the difference between the two.

• rate – returns just those statistics that are different from the previous time netstat was run.

• protocol – choose whether to view statistics for TCP, UDP, or both.

Lists the NICs installed in the sensor along with their names, driver names, driver versions, firmware versions, and bus information.

Lists the configured NTP servers for this sensor in order of use.

Modular Sensors only. Shows the status of a kernel and package upgrade started with exec os update kernel-and-package. The syntax is as follows:

show os kernel status

Shows the current status of a kernel and package upgrade, including recent log output. If no upgrade has been started, reports whether the upgrade service has failed or was never started.

show os kernel packages

Shows a diff of package changes made by the last kernel and package upgrade, organized into three sections: packages that were updated (with old and new versions), packages newly installed as upgrade dependencies, and packages removed during the upgrade.

Shows packet processing settings, including slicing and deduplication.

Modular Sensors only. Lists the Ethernet PCI devices detected on the sensor, including each device's PCI bus address, current interface name, driver, and description. Use this command to identify interfaces before creating a persistent-naming rule.

For example:

Sensor> show pci ethernet
PCI Address    Interface   Driver    Description
--------------------------------------------------------------------------------
0000:0b:00.0    eth0        vmxnet3    Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)

Shows detailed information on internal AFIX process mapping, including NUMA register mapping.

Shows information on proxies configured for the sensor, if any.

Shows information on the configured data receiver for the sensor, including the following:

• IP Address or hostname

• Port number

• Receiver type (JSON or Packet)

• Transport (HTTPS or HTTP)

• Status, including response time

• Currently configured compression level for Windows Server Sensor event and FIM logs.

You can also use the expanded show receiver debug command to see additional details on the sensor's SSL certificate connectivity. The certificate details provided can help you identify SSL inspection or certificate mismatches.

This command is supported for Windows Server Sensors as of the 6.2.0 release.

Shows information on the AFIX ring.

Shows static route table entries.

Shows information on configured maltrace rules.

Shows detailed scan information on sensor.

Provides the service to AppID mapping for the sensor, including the NUMA register for each. Note that the output for this command can be lengthy. Use the all parameter to see all entries in paged output (for example, show service all).

Provides a session table for the sensor listing ongoing sessions and their NUMA mappings.

The syntax is as follows:

show session [detail | summary] [| include <field> <text>]

• detail – Returns the raw session list. This is the default and is the same as running show session with no arguments.

• summary – Returns per-table summary statistics instead of the raw session list.

You can filter the output of show session by appending | include and one of the following fields:

• | include <text> – Filters the raw output locally using a free-text match.

• | include ip <text> – Matches sessions where either the source or destination IP address matches.

• | include src-ip <text> – Matches sessions by source IP address.

• | include dst-ip <text> – Matches sessions by destination IP address.

• | include src-port <text> – Matches sessions by source port.

• | include dst-port <text> – Matches sessions by destination port.

• | include protocol <text> – Matches sessions by protocol (for example, tcp, udp, or icmp).

• | include app-id <text> – Matches sessions by application ID.

The ip, src-ip, dst-ip, src-port, dst-port, protocol, and app-id filters all return up to 100 matching entries. This filtering is supported identically on Device Sensors and Server Sensors (agents).

Provides troubleshooting information for support purposes. The syntax is as follows:

show support {upload | vm-resource-check [<seconds>]}

show support upload

Shows whether the sensor's support log bundle is reaching the CM Controller.

The sensor uploads a diagnostic log bundle to the CM on a regular schedule. Use show support upload to confirm those uploads are succeeding — for example, when a proxy is unreachable or a bundle is rejected for being too large. The output reports the time and result of the last attempt, the time of the last success, the destination, and success and failure counts. For example:

Sensor> show support upload
Support Log Upload to CM
Last attempt   : 2026-06-23 21:21:45 UTC (1 second ago)
Last status    : FAILED
Last success   : 2026-06-23 21:20:53 UTC (53 seconds ago)
Destination    : 10.34.22.100
Success / Fail : 3 / 1 (since aella_conf start)
Last error     : Log bundle too large

The Last error line appears only when the most recent attempt failed, and reports the reason reported by the upload.

The success and failure counts are reset each time the sensor's aella_conf service restarts.

show support vm-resource-check

Reports whether a slow or unstable sensor is being starved by its virtualization host or is saturating the resources it already has. These two conditions have opposite remedies, and cannot otherwise be told apart from inside the sensor.

The command samples CPU steal, memory and I/O pressure, and host memory reclamation, then returns a verdict in JSON so you can paste it into a support ticket. Include a number of seconds to lengthen the CPU sample window; the default is 2 seconds and the maximum is 10.

The status field reports one of the following verdicts:

• host_oversubscribed – The host is taking CPU or memory away from this sensor. Resolve this on the hypervisor — add capacity, raise the sensor VM's reservation, remove a limit, or move the VM to another host. The accompanying message names the hypervisor tool to confirm with.

• vm_saturated – The sensor is using up the vCPU, memory, or disk it has been given, and the host is not the constraint. Resolve this in the sensor — reduce the features enabled in its profile, or provision more vCPU and memory.

• clean – Neither condition was found in this sample.

• inconclusive – Host memory reclamation could not be confirmed from inside the sensor. The message names what to do to make it measurable, such as installing open-vm-tools on VMware.

The message field restates the verdict in a sentence and appends any platform-specific advice. The remaining fields report the measurements behind it. For example:

Sensor> show support vm-resource-check
Checking. Please wait for a minute
{
  "status": "clean",
  "message": "no host oversubscription and the VM is not saturated",
  "environment": {
    "vcpu_count": 4,
    "hypervisor": "vmware",
    "load_1min": 1.35,
    "load_5min": 1.19,
    "load_15min": 1.17
  },
  "cpu": {
    "steal_percentage": 0.0,
    "iowait_percentage": 0.0,
    "steal_sample_seconds": 2,
    "pressure_some_percentage": 36.4,
    "pressure_full_percentage": 0.0
  },
  "memory": {
    "pressure_some_percentage": 0.0,
    "pressure_full_percentage": 0.0,
    "total_mb": 7937,
    "available_mb": 4248,
    "ballooning_mb": 0,
    "provisioned_mb": null,
    "host_swap_mb": 0
  },
  "io": {
    "pressure_some_percentage": 0.0,
    "pressure_full_percentage": 0.0,
    "storage_error_count": 0
  }
}

The environment fields describe the sensor VM itself: vcpu_count is the number of vCPUs the guest can see, hypervisor is the detected virtualization platform (which determines the checks used), and the three load_ fields are the standard 1-, 5-, and 15-minute load averages. A 1-minute load higher than the vCPU count counts as saturation. In the example above, a load of 1.35 across 4 vCPUs is comfortable.

The cpu fields report host contention and CPU saturation:

• steal_percentage – The share of time the host made this sensor wait for a physical CPU. This is the primary evidence of host oversubscription.

• iowait_percentage – Time the CPU spent idle waiting on I/O. Informational, and used as a fallback on kernels that do not report pressure.

• steal_sample_seconds – The window actually used to sample steal.

The memory fields report guest memory and any reclamation by the host. total_mb and available_mb are guest-visible memory. ballooning_mb is memory the host has taken back through the balloon driver, and host_swap_mb is memory the host has swapped out from under the sensor; either one above zero points to host oversubscription. provisioned_mb is the maximum memory configured for the VM on the host, when the sensor can read it.

On VMware sensors, two additional fields report reclamation over time rather than at the moment you run the command:

• ballooned_since_boot_mb – The cumulative memory the host has reclaimed since the sensor booted.

• balloon_reclaim_mb_per_hour – That total averaged over the sensor's uptime.

These two fields matter because a host can reclaim memory in short bursts and then release it. A burst can last well under two minutes and leave ballooning_mb at 0 moments later, so a host that is repeatedly starving the sensor can look untroubled in a single sample. The command reports host_oversubscribed when the cumulative total and the hourly rate are both substantial, which identifies that pattern even when the balloon is empty when you look.

The io fields report storage stalls. storage_error_count is the number of storage errors found in the kernel message buffer. Because that buffer covers the whole time since boot, a non-zero count can reflect a problem that has already passed, so it is reported as a note rather than used to decide the verdict.

Each section also reports pressure_some_percentage and pressure_full_percentage. Only the full value indicates real saturation, because it means every task was stalled waiting on that resource. The some value means at least one task waited at some point, which is normal on any busy sensor and never raises a warning on its own. In the example above, a CPU pressure_some_percentage of 36.4% alongside a pressure_full_percentage of 0.0% is healthy.

A field set to null is not the same as a field set to 0. null means the sensor could not measure that signal on this platform or without additional privileges, while 0 means it was measured and found to be zero. This is why a partial set of measurements returns inconclusive instead of a misleading clean.

The checks used depend on the virtualization platform. On Hyper-V and Azure, CPU steal is not a reliable signal and is reported without driving the verdict; confirm host CPU on the hypervisor or in the portal instead. AWS and Azure do not overcommit memory, so they report a genuine clean rather than inconclusive.

This command is available on Linux-based sensors. It is not available on Windows Server Sensors. Refer to Arguments for the "show" command in the Sensor CLI Access Window for the underlying hypervisor balloon detail on a single sensor.

Shows the status of key Stellar Cyber services on the sensor, including service uptime.

If a given service is down, you can use the restart service <service_name> command to restart it.

This command is supported for Windows Server Sensors as of the 6.2.0 release.

Shows information on JSON tasks requested on the sensor by the DP (for example, restarting an internal sensor service).

Shows information on tcpreset actions configured as part of scripts in ATH playbooks. The available commands are as follows:

• show tcpreset – Displays the list of tcpreset traffic files. Each file provides a timestamped record of the tcpreset traffic sent by the sensor as part of a script action.

• show tcpreset [file] – Displays the contents of a specified tcpreset traffic file. You can get the list of available file names with the show tcpreset command.

• show tcpreset script-actions – Shows the tcpreset actions sent from the DP to this sensor. For example:

  Sensor> show tcpreset script-actions
[2025-11-01 22:44:11] tcpreset ad5600505689fdce -i eth1 -o eth0 -h 10.33.5.184 -d 15
  

Collects a tech-support diagnostic bundle for the sensor.

When run from the Sensor CLI Access window, this command runs as a background job. Refer to Running Long-Duration CLI Commands for details on retrieving its output with show cli job.

Available if tenable nessus is enabled in the sensor profile. Shows status of the scanner.

Shows information on CPU threads.

Shows system time.

Shows top resource usage by process.

Modular Sensors only. Displays the sensor's active persistent (udev) interface-naming rules file.

For example:

Sensor> show udev
=== /etc/udev/rules.d/60-persistent-net.rules ===
ACTION=="add", SUBSYSTEM=="net", DRIVERS=="?*", KERNELS=="0000:0b:00.0", NAME:="eth0"

Refer to the set udev persistent-rule command below for details on creating and managing these rules.

Shows information on upgrades for this sensor. The syntax is as follows:

show upgrade

Shows a history of upgrades along with log entries documenting their success or failure and details on the image applied.

Shows information on user-defined applications for this sensor.

Note that the output for this command can be lengthy. The following tips can help you see the entries that interest you:

• Use the all parameter to see all entries in paged output (for example, show userapp all).

• Use a regex filter to exclude aella_log_forwarder entries and see only user-defined applications. For example:

  show userapp regex ^(?!.*aella_log_forwarder).*

  show userapp all regex ^(?!.*aella_log_forwarder).*

Shows the sensor software version, license status, features, platform, basic configuration settings, and sensor up time. Note that values for some of these options can also be seen in the Sensor List, depending on which fields you add to the display.

Note: The statistics displayed by the show version command can vary depending on your sensor type and version. The statistics listed below are current for the latest sensor software version.

Note: Windows Server Sensors show only the following fields in their show version output – AOS Version, Product Model, License Status, Product EngineID, Internal ID, Running Mode, Running Feature, Aggregator, CM Controller,, Ctrl Plane Status, Platform OS, and Platform Type.

• AOS Version – The version of the Stellar Cyber operating system on the sensor.

  You can use the AOS Version to determine whether the sensor is operating in SaaS or on-prem/pre-SaaS mode:

  • Sensors operating in on-prem/pre-SaaS mode include a p at the end of their AOS Version in the show version output. For example:

    AOS Version : 5.2.0_99e79ab-p

  • Sensors operating in SaaS mode do not include the p in their AOS Version.

• Product Model – Shows Data_Sensor for Device Sensors and either Windows Agent Sensor or Linux Agent Sensor for Server Sensors.

• License Status – Shows whether the license on the sensor is valid.

  This field does not appear for physical Photon Sensors.

• Product EngineID – The unique system ID assigned to this sensor by Stellar Cyber.

• Product Tenant ID – The unique system ID assigned to this sensor's tenant.

• Platform Type – The type of platform on which this sensor is installed. For a virtual sensor, this can be VMware, QEMU, Virtual Machine, Microsoft, and so on. For physical sensors, a hardware revision is shown.

• Platform OS – The operating system in use on the sensor.

• Hostname – The sensor's hostname.

• Running Mode/Feature – Indicates whether the sensor is a device sensor or a server sensor (agent), as well as the type of sensor profile enabled.

  • Photon Sensors show device/modular.

  • Virtual Modular Sensors show device/modular.

  • Linux Server Sensors show agent/ds.

  • Windows Server Sensors show agent/wds, but broken out on separate lines.

• Management Port – The device interface designation for the management port on the sensor (for example, eth0).

• Management IP – The IP address of the management port on the sensor.

• CM Controller – The IP address of the Stellar Cyber platform that manages this sensor.

• Ctrl Plane Status – Can be Authorized or Unauthorized. Indicates the status of the authorization handshake between the sensor and its managing Stellar Cyber Platform's Configuration Management module (CM). Once the handshake has established management communications and the Control Plane is authorized, the Stellar Cyber Platform pushes sensor profile settings to the sensor.

• Sensor Boot Time – The time at which the sensor was last booted. Note that this field only appears for physical Photon Sensors.

• Sensor Up Time – The amount of time the sensor has been running since the last time it was booted.

• Data Plane Status – Can be Online or Offline. Indicates whether the sensor is successfully sending ingested data to its managing Stellar Cyber Platform.

Shows interfaces available for use as a VXLAN tunnel destination.

Shows Information on VXLAN tunnel configuration.

Lets you configure the AFIX ring buffer size. AFIX is used on the sensor to extract flow and metadata information from sessions.

Must be a specified as a power of 2 with a default size of 8192.

Lets you specify the IP address of the aggregator for the sensor, if any.

Specify the aggregator as an IP address. The sensor CLI accepts a fully qualified domain name or a hostname, but the sensor cannot then be authorized: authorization fails with Invalid aggregator, and the Primary Aggregator and Secondary Aggregator fields for the sensor remain empty.

Lets you set the IP address to reach the management interface of the Data Processor from the sensor or aggregator. For a DP cluster, this is the IP address of the DL-master's management interface. For a single DP deployment, this is simply the DP's management IP address. You can supply either an IP address or a hostname. Running this command from the Sensor CLI Access window can be useful when migrating sensors from one DP to another.

Note: Using this command from the Sensor CLI Access window disconnects the sensor from its current DP. Because of this, you need to manually close the Sensor CLI Access window once the disconnection occurs.

The syntax is as follows:

• cm_addr – the IP address or hostname of the managing DP.

• safe – reverts the CM address to the previous address if connection to the new one is not successful. This parameter is automatically used by Stellar Cyber when set cm is executed from the Sensor CLI Access window regardless of whether you included it in the command line.

• force – sets the CM address to whatever you specify, regardless of connection success. Be careful when using this option.

Stellar Cyber strongly recommends that you always use the safe argument with set cm in order to prevent yourself from accidentally orphaning a sensor by assigning an incorrect IP address.
As a safeguard, the safe option is used automatically when you run set cm from the Sensor CLI Access window.

Lets you assign an IP address to a data port on a sensor. For example, you can set the IP address of a data port using the following command:

DataSensor> set data-port-ip 1 100.100.100.100/24

This command changes the data port IP configuration, setting the IP address of data port 1 to 100.100.100.100/24

Adds a user-defined metadata attribute for the specified DPI protocol.The syntax is as follows:

set dpi protocol custom metadata <proto> <attr> [<alias>] [<level>]

Supported protocols and example attributes:

• smb – session_id

• ssl – server_supported_version, key_share_group, ext_ec_supported_groups_list, ext_ec_supported_groups_type, client_hello_extension_type, client_hello_extension_value, server_hello_extension_type, server_hello_extension_value, ext_sig_algorithms, ext_sig_algorithm_scheme, ext_sig_algorithm_hash, ext_sig_algorithm_sig, certificate_subject_key_algo_oid, certificate_signature_algo_oid

• The optional alias argument specifies an alternative name for the attribute in output.

• The optional level argument sets the metadata collection level (default: 2).

After adding entries, run restart service aella_flow for changes to take effect. A maximum of 100 user-defined entries are supported. Enabling additional metadata can increase ingestion volume and storage requirements.

Lets you configure options related to parsing of GENEVE-encapsulated traffic from Netskope's Cloud TAP stitcher.

The Netskope Cloud TAP stitcher can be used to pull data stored by the Netskope Cloud TAP from AWS S3, stitching connections back together , performing TLS decryption, and exporting the traffic to a Stellar Cyber Modular Sensor in a GENEVE-encapsulated tunnel.

As part of the configuration of the GENEVE tunnel, you can enable Netskope-proprietary USER_ID or SITE_ID options. When enabled, additional TLVs are included in the outer GENEVE header of each packet. The Modular Sensor extracts the USER_ID or SITE_ID TLV added by the Netskope Cloud TAP stitcher from the outer GENEVE header and associates each identifier with its corresponding flow inside the tunnel. Because parsing occurs at the packet level, multiple users sharing the same tunnel are correctly recognized. Normalization maps the Netskope user identifier to srcip_username and the Netskope site identifier to srcip_siteid.

Settings for GENEVE parsing on the sensor are preconfigured to match the Netskope defaults and only need to be changed in the rare situation where you have modified them on the Netskope side. You can configure the following options for this feature with set geneve <parameter> <value>:

• netskope_port – Specifies the UDP port used by GENEVE traffic. By default, this is set to the default GENEVE port of UDP 6081.

• netskope_class – Specifies the Netskope option class. By default, this is set to 65484 (0xffcc).

• netskope_user_id_type – Specifies the Netskope User ID type. By default, this is set to 12 (0xc).

• netskope_site_id_type – Specifies the Netskope Site ID type. By default, this is set to 13 0xd).

Modular Sensors only. Lets you configure whether the sensor's ethernet interfaces use legacy eth-style names or predictable PCI bus names.

The syntax is as follows:

set grub net.ifnames <value>

• 0 – Use the legacy naming scheme (for example, eth0, eth1).

• 1 – Use the predictable PCI bus naming scheme (for example, enp3s0).

This command updates the following files on the sensor: /etc/default/grub, /etc/default/grub.d/90-aella-kernel-params.cfg, and /boot/grub/grub.cfg. For example:

Sensor> set grub net.ifnames 0
GRUB net.ifnames set to 0 (legacy naming scheme (e.g. eth0, eth1, ...))
Updated files:
/etc/default/grub
/etc/default/grub.d/90-aella-kernel-params.cfg
/boot/grub/grub.cfg
Run 'restart system' to reboot for changes to take effect after update.

Changes take effect only after you run restart system to reboot the sensor. Because this setting changes the interface names used elsewhere in this CLI (for example, with set interface and set mtu), run show interface after the reboot to confirm the new interface names before referencing them in other commands.

This command is not available on other Device Sensor profiles (for example, standard or network sensors) or on Server Sensors.

Lets you specify the hostname for the sensor. You can also specify hostnames in the Sensor List.

This is an advanced setting that you should only configure with the assistance of Stellar Cyber Customer Success team.

Lets you change the hugepage size configured for the sensor.

The syntax is as follows:

set hugepage_size <auto | 2m | 1g>

The default is auto. Note that changes to this setting only take place after restarting aella_flow.

In Linux, a hugepage is a larger-than-normal memory page that helps reduce the overhead of managing memory. By mapping larger chunks of memory at once, hugepages can improve sensor performance

In most deployments, you do not need to change the hugepage size from its default setting of auto. However, you might consider changing the hugepage size with the assistance of Stellar Cyber Customer Success in situations where your ingestion rates are very high and packet drops are observed. In these cases, adjusting the hugepage size can help reduce CPU overhead, improve memory allocation for large buffers, and maintain consistent performance under load.

Enables and configures the IDS PCAP capture feature on the Modular Sensor. When enabled, this feature captures trace files to the Sensor's storage when an IDS signature match is detected.

Refer to Capturing Trace Files for IDS Signature Matches for more information on enabling and configuring the IDS PCAP feature.

Lets you set IP configuration for a sensor interface by name, including its IP address, default gateway, and DNS server. Start by using show interface to get the name of the interface you want to configure. For example, to configure the management interface, you would use set interface management <arguments>

This command is only supported on sensors running Ubuntu 22.04.

The syntax is as follows:

• ip [<IP Address/Netmask> | dhcp]
• gateway <IP Address>
• dns <IP Address>

Configuring an SSH Whitelist for the Management Port

You can use the CLI to configure a whitelist of IP addresses and/or ranges that are allowed to access the Management port via SSH. When a whitelist is configured, SSH connections to the Management port are only allowed from whitelisted addresses. SSH connections from all other IP addresses are rejected.

The syntax is as follows:

ssh interface management ssh-whitelist <IP/CIDR> [<IP/CIDR> ...]

For example, the following command allows SSH connections from all addresses in the 10.34.22.0 subnet:

Sensor> set interface management ssh-whitelist 10.34.22.0/24

Similarly, the following command allows SSH connections from only 192.168.1.25 and 192.168.1.50:

Sensor> set interface management ssh-whitelist 192.168.1.25 192.168.1.50

Note that changes to the SSH whitelist are not cumulative. Every time you use the set interface management ssh-whitelist command, it completely replaces the previous whitelist settings. You can verify the current whitelist by looking at the entry for the management interface in the show interface output.

Clearing the SSH Whitelist

You can clear the currently configured SSH whitelist with the unset interface management ssh-whitelist command.

Enables structured handling for LDAP search and modify request fields. You must enable this option for generation of the Suspicious LDAP Search Request alert and its subtypes of Domain Trust Enumeration, All Object Enumeration, and Wildcard Query. You can turn off the feature with unset ldap-metadata.

Lets you configure the logforwarder feature.

Use set logforwarder apply-custom-parser to force the Sensor log forwarder to redownload and apply custom parsers. This lets you refresh parser and configuration files without manual intervention, ensuring that updated or corrected parsers are immediately applied. If no custom parser exists or a parser is invalid, the command reports the condition and skips changes. This capability helps maintain parser consistency across tenants.

Lets you manage the list of active Log Forwarder parsers on the sensor. Use this command with Stellar Cyber personnel to reduce memory usage on hosts with limited resources by enabling only the parsers required for your environment. The syntax is as follows:

set logforwarder parser add <parser> | remove <parser|all> | restore_default

• add <parser> – Enables a specific parser. Tab completion is available for parser names.

• remove <parser> – Disables a specific parser.

• remove all – Disables all parsers.

• restore_default – Restores the built-in default parser set.

After making changes, run restart service td-agent for the changes to take effect. Note that parser configuration changes may not persist across platform upgrades and can be overwritten by UI management.

Lets you control which TLS 1.2 cipher suites the sensor's log forwarder (td-agent) accepts for TLS log forwarding connections.

The syntax is as follows:

set logforwarder tls-cipher-mode {secure | legacy}

• secure – Restricts the sensor to ECDHE-RSA cipher suites only, excluding the weaker DHE and static RSA key exchanges. This hardens the sensor against TLS downgrade attacks and is the default for newly installed sensors.

• legacy – Allows the broader cipher set used before this release, including DHE and RSA key exchanges, for compatibility with older log sources. Sensors upgraded from an earlier release keep this mode automatically; switch to secure explicitly if you want the hardened cipher set.

Use show logforwarder tls-cipher-mode to see the sensor's current setting.

The sensor automatically restarts the td-agent service after you change the cipher mode; you do not need to restart it manually.

Lets you set the log level for different modules. The syntax is as follows:

You can also set the loglevel timeout with the following command:

Stellar Cyber recommends that you only change the log level for modules while working with Custom Success personnel. If you do decide to change log levels, a good way to start is by checking the current log levels with the show log level command. The default log level for all modules is info.

The available modules (services) for which you can set the log level are as follows:

• audit (aella_audit)

• conf (aella_conf)

• ctrl (aella_ctrl)

• flow (aella_flow)

• mon (aella_mon)

The available log levels are as follows, from least to most severe:

• debug

• info

• warning

• error

• critical

As an example, you can set the log level for aella_flow to warning with the following command:

set loglevel flow warning

When you specify a log level, Stellar Cyber records events of the specified severity and above. So, for example, if you specify a log level of error, only events with a severity of error and critical are logged.

The log level setting also directly affects the quantity of events logged. For example, if you specify a log level of debug for a service, all events for that module are logged, regardless of severity.

Log Level Tips

Keep in mind the following tips when making changes to the log level:

• Stellar Cyber strongly recommends that you consult with Customer Success before changing log levels for a service.

• If you do make changes to the log level, Stellar Cyber recommends that you also set a loglevel timeout so that the log level returns to its normal state after whatever testing you are performing.

• Stellar Cyber recommends that you keep track of the time at which you change the log level. This can help the Customer Success team assist you with troubleshooting.

Enables or disables NFS file assembly in Suricata for Sophos malware inspection. The syntax is as follows:

set maltrace nfs-assembly {enable|disable}

This feature is resource-intensive. Only enable when working with Stellar Cyber personnel.

When enabled, Suricata reconstructs files transferred over NFS sessions and forwards them to Sophos for malware analysis. Supports NFSv3 and NFSv4; NFSv4 may not provide reliable file name metadata due to handle-based protocol operations.

To ensure Suricata can detect the NFS application layer, start packet capture before the NFS client mounts the share. If capture begins after the mount, session establishment is not observed and application-layer detection may not initialize.

This setting persists across sensor upgrades.

Lets you configure the malware upload feature. Refer to Forwarding Malware to an External HTTPS Server for details.

Lets you set the MTU for a specified interface. The syntax is as follows:

set mtu <mtu_value> <ifn_name(s)>

You can specify multiple interfaces in a single command. For example, the following command sets the MTU to 5500 bytes for eth0, eth1, and eth2:

Lets you specify an NTP server for the sensor. The syntax is as follows:

Specifying an NTP server does not configure a time zone for the sensor. During installation, the timezone for a sensor is automatically set to UTC+0. Since the logs for some security products may only include the local time without a timezone, Stellar Cyber recommends that you set the sensor timezone to the same timezone as your security product. Set the time zone for a sensor from the Sensor List. Refer also to Best Practices for NTP and Timezones .

Lets you change the password for the sensor.

Lets you specify an HTTP proxy for the sensor. The syntax is as follows:

Note: The CLI prevents you from entering non-printable characters as part of the username or password for the proxy, as well as the proxy itself.

The set proxy command works differently depending on whether the sensor is operating in NG-SaaS mode or as an on-premises sensor:

• When a modular sensor is running in NG-SaaS mode with an aggregator configured, it cannot use an external HTTP proxy. In NG-SaaS mode, the set proxy command works only when an aggregator is not configured.

• When a modular sensor is running in on-premises mode, the set proxy command does allow the sensor to use an external proxy for downloading updates from the internet. In this configuration, direct communication between the sensor and the DP is disabled.

Lets you change the receiver configured for the sensor in its sensor profile.

Configuring Event Log and FIM Timeouts for Windows Server Sensors

By default, Windows Server Sensors send Windows Event Log and File Integrity Monitoring (FIM) payloads with a timeout setting of 90 seconds. You can use the set receiver timeout command to fine-tune timeout settings independently for the two source types. The syntax is as follows:

set receiver timeout <seconds> [winlog | fim]

Note the following:

• A setting of 0 disables timeouts for the specified data source types.

• If you leave out the winlog | fim argument, the timeout setting applies to both data source types.

• Restore the default timeout of 90 seconds with the unset receiver timeoutcommand.

• Use show receiver to see the currently configured timeout settings for each data source type.

This setting helps you address high-latency or bandwidth-constrained environments, improving log delivery reliability and reducing premature timeout failures in variable network conditions.

Configuring the GZIP Compression Level for Windows Server Sensors

By default, Windows Server Sensors send Windows Event Log and File Integrity Monitoring payloads over HTTPS with a GZIP compression level of 1. You can use the set receiver compression command to fine-tune the compression level independently for the two source types. The syntax is as follows:

set receiver compression <level> [winlog | fim]

Note the following:

• Valid settings for level are from 0-9. A setting of 0 disables compression.

• If you leave out the winlog | fim argument, the setting applies to both source types.

• Restore the default compression level of 1 with the unset receiver compression command.

• Use show receiver to see the currently configured compression settings for each data source type.

Higher compression levels reduce bandwidth consumption while increasing CPU usage. This enhancement provides flexibility for environments with network constraints without requiring sensor profile changes.

Lets you toggle the SMB Reduction feature. Enabling this option reduces the amount of metadata collected for SMB commands. This is especially helpful in increasing your compression ratio if your network has a great deal of SMB traffic. If you enable this, metadata is only collected for:

• session setup
• logoff
• read
• write

Lets you set the system date and time in <YYYY-MM-DD HH:MM:SS> format, if you are not using NTP.

Lets you apply a token to a sensor in a SaaS installation. The syntax is as follows:

Lets you remove aggregator settings from the sensor.

Lets you remove a user-defined DPI metadata attribute for the specified protocol and attribute or removes all user-defined entries with the all argument. The syntax is as follows;

unset dpi protocol custom metadata <proto> <attr> | all

Run restart service aella_flow for changes to take effect.

Lets you remove the currently configured SSH whitelist for a sensor.

Lets you disable the Metadata Summarization feature.

Lets you unset logforwarder settings.

Lets you remove malware_upload settings.

Lets you remove the configured NTP settings.

Lets you remove the configured password from the sensor, resetting it to its default of aella/changeme.

Lets you remove the configured HTTP proxy for the sensor.

Lets you restore the compression settings for event and FIM logs from a Windows Server Sensor to the default level of 1.

Runs any command as a background job instead of waiting for it to finish.

Refer to Running Long-Duration CLI Commands for syntax and examples.

Runs the sensor's built-in CVE Checker to check the sensor's operating system and installed packages against a set of known CVEs, and lets you apply available remediations.

The syntax is as follows:

exec cve {check | summary | patch | update} [<argument>]

• exec cve summary – Lists the CVEs supported by the CVE Checker, along with severity and a one-line description.

• exec cve check {all | result | <CVE-ID>} – Runs the check for all supported CVEs, for a single CVE, or displays the most recently saved JSON report.

• exec cve patch {all | <CVE-ID>} – Applies the available remediation for a patchable CVE, or for all patchable CVEs in sequence. Not every supported CVE has a patch available.

• exec cve update – Downloads the latest version of the CVE scanner from the managing DP.

When run from the Sensor CLI Access window, exec cve check and exec cve patch run as background jobs. Refer to Running Long-Duration CLI Commands for details on retrieving their output with show cli job.

Refer to Checking Device Sensors for Common Vulnerabilities and Exposures (CVEs) for the full list of supported CVEs, detailed command syntax, and sample output.

Lets you perform on-demand updates of operating system packages and the kernel on Modular Sensors, fixing OS-level vulnerabilities without affecting critical services, and lets you roll back those changes if needed. The syntax is as follows:

exec os update kernel-and-package <kernel-version> [with-firmware]

• <kernel-version> – The QA-tested kernel version to install. This is the same kernel version shipped with new sensor installs for the current release; check the release notes for the current QA-tested version.

• with-firmware – Optional. Also updates device firmware packages as part of the upgrade.

Starts a background OS kernel and package upgrade on the sensor. The upgrade runs as a system service and continues even if the CLI session disconnects. Before proceeding, the command verifies internet connectivity, displays the number of pending package upgrades, and requires double confirmation. Critical sensor packages (suricata and squid) are held during the upgrade and released on completion. After the upgrade completes, reboot the Modular Sensor to apply kernel changes.

Use show os kernel status to monitor progress and show os kernel packages to review what changed.

Rolling Back a Kernel and Package Upgrade

Use the following command to roll back a kernel and package upgrade:

exec os update kernel packages rollback [<package> [<version>]]

Rolls back package changes made by the last kernel and package upgrade. Double confirmation is required before the rollback proceeds.

• Without arguments – Rolls back all changed packages to their pre-upgrade versions and purges any packages that were newly installed by the upgrade.

• With <package> – Rolls back only the specified package. If the package was changed by the upgrade, it is downgraded to its pre-upgrade version. If it was newly installed by the upgrade, it is purged.

• With <package> and <version> – Rolls back the specified package to the supplied version. Use this form when the pre-upgrade version is no longer available in the package repository. To find available versions, run apt-cache madison <package> from the sensor shell.

This command is only available on Modular Sensors.

Lets you execute predefined tasks specified in JSON files. The JSON files specify actions such as downloading and executing scripts. Each tasks includes parameters and exception handling instructions.

This command is only supported in the Sensor CLI Access window; it is not available in the local CLI.

Lets you stop the tcpreset process for specified IP addresses. If you do not specify an IP address, all active tcpreset processes on the sensor are stopped.

Restarts the specified sensor service.

To use this command, start by running the show system command to see the status of sensor services (for example, aella_flow, aella_mon, maltrace, and so on). Then, find the service name you need to restart in the show system output and include it as part of the restart service <service_name> command.