We're currently building and refining our Knowledge Center. You may encounter layout issues, styling inconsistencies, or minor technical quirks as we finalize the platform.

Troubleshoot the traffic sensor

Prev Next

The traffic sensor is currently in closed beta. Availability is limited, and setup and requirements may change during this phase.

If you’d like access, you can join the interest list.

You can use this list to troubleshoot the traffic sensor. Verify the basics first, apply relevant quick fixes if checks fail, and collect diagnostic data to gather logs and system details for further support.


Validation checklist

Is the service running?

Check the systemd service state and recent logs:

sudo systemctl status lansweeper-network-discovery-traffic-sensor --no-pager
sudo journalctl -u lansweeper-network-discovery-traffic-sensor --since "30 minutes ago" | tail -n 200

How can I validate that traffic is reaching the capture NIC?

Run a short tcpdump on the intended capture interface:

ip -br link 
sudo tcpdump -i <iface> -c 20 -nn

If you see packets scrolling by, traffic is arriving.
If no packets are captured, this is usually an upstream mirroring/TAP/ERSPAN issue or the wrong interface.

Optional link-layer sanity checks:

sudo ethtool <iface> | egrep "Link detected|Speed|Duplex"

How can I validate that the traffic sensor is producing output files?

Check the configured output path and confirm files are being written:

sudo ls -lah /opt/lansweeper-network-discovery-traffic-sensor/flows/

If you’re not sure the sensor is configured to write there, confirm the output setting:

grep -n "output_prefix" /opt/lansweeper-network-discovery-traffic-sensor/sensor.toml

How can I validate that the sensor is linking to the hub successfully?

Start by checking the sensor logs for hub connectivity/authentication messages, then confirm basic network reachability to the hub (DNS/routing/firewall):

sudo journalctl -u lansweeper-network-discovery-traffic-sensor --since "30 minutes ago" | egrep -i "hub|connect|auth|error|warn" | tail -n 200

If you have the hub hostname/IP, validate network reachability (commands vary by environment). If you’re unsure which ports are required in your build, open a Helpdesk ticket for the current port matrix.


Common issues and quick fixes

systemctl status lansweeper-network-discovery-traffic-sensor shows “failed”, what should I collect first?

Collect service status and the last ~30 minutes of logs:

sudo systemctl status lansweeper-network-discovery-traffic-sensor --no-pager 
sudo journalctl -u lansweeper-network-discovery-traffic-sensor --since "30 minutes ago" | tail -n 200

Common causes to check next:

  • Invalid syntax or invalid values in /opt/lansweeper-network-discovery-traffic-sensor/sensor.toml

  • A referenced capture interface that does not exist (for example under packet_sources)

  • Permissions/capabilities preventing packet capture

If capabilities are missing, the quickest fix is usually to reinstall the package. Manually setting capabilities is possible but should be treated as an advanced/exception path.

getcap /opt/lansweeper-network-discovery-traffic-sensor/bin/sensor

The service is running, but no output files appear, what should I check?

Verify the configured output path, permissions, and disk space, then review logs for capture or write errors:

grep -n "output_prefix" /opt/lansweeper-network-discovery-traffic-sensor
ls -lah /opt/lansweeper-network-discovery-traffic-sensor/sensor/
df -h /opt/lansweeper-network-discovery-traffic-sensor/sensor/
sudo journalctl -u lansweeper-network-discovery-traffic-sensor --since "30 minutes ago" | egrep -i "error|warn" | tail -n 100

Packets are not visible in tcpdump, what’s the most likely issue?

It’s almost always upstream mirroring/TAP/ERSPAN rather than the sensor host itself.
Confirm that:

  • You’re running tcpdump on the correct interface (ip -br link)

  • The mirror/TAP is physically connected (or ERSPAN is delivered to the correct endpoint)

  • SPAN includes the correct VLAN(s) and direction(s) (ingress/egress/both)

  • The feed isn’t oversubscribed (SPAN congestion can drop mirrored packets)

Helpful interface checks:

ip -br link 
sudo ethtool <iface> | egrep "Link detected|Speed|Duplex"

The sensor was working, but stopped after a reboot, what do I check?


Confirm the service is enabled to start on boot:

sudo systemctl is-enabled lansweeper-network-discovery-traffic-sensor
sudo systemctl enable --now lansweeper-network-discovery-traffic-sensor

Stopping the sensor hangs, what can I do?


First try a normal stop and check whether the process is still running:

sudo systemctl stop lansweeper-network-discovery-traffic-sensor 
sudo systemctl status lansweeper-network-discovery-traffic-sensor --no-pager 
ps aux | grep -E "[s]ensor"

If you must force-stop:

sudo systemctl kill -s SIGKILL lansweeper-network-discovery-traffic-sensor

Then collect logs and document why a force-stop was required.


Collect diagnostic data

What information should I gather for support/troubleshooting?

Run the following as root and sanitize secrets before sharing externally:

sudo -i

mkdir -p /tmp/sensor_support_bundle
cd /tmp/sensor_support_bundle

# System info
date -u > timestamp.txt
uname -a > uname.txt
lsb_release -a > lsb_release.txt 2>&1
df -h > df.txt
free -h > free.txt
ip addr show > ip_addr.txt
ip link show > ip_link.txt

# Service status + logs
systemctl status lansweeper-network-discovery-traffic-sensor --no-pager > systemctl_sensor_status.txt 2>&1
journalctl -u lansweeper-network-discovery-traffic-sensor --since "2 hours ago" > journal_sensor_last2h.txt 2>&1

# Configs (sanitize secrets before sharing)
cp -a /opt/lansweeper-network-discovery-traffic-sensor/sensor.toml .
cp -a /opt/lansweeper-network-discovery-traffic-sensor/sensor.env .

# Optional: package capabilities
getcap /usr/local/bin/sensor > getcap_sensor.txt 2>&1