|
|
| Line 1: |
Line 1: |
| == Capture Rules Troubleshooting ==
| | #REDIRECT [[Capture_rules#Troubleshooting]] |
| | |
| This guide helps you troubleshoot common issues with capture rules, specifically when changes made in the GUI are not being applied to the sensor.
| |
| | |
| == Rules Not Applied After GUI Change ==
| |
| | |
| The most common cause is that the capture reload signal never reached the sensor. This can happen due to network connectivity issues between the GUI and the probe.
| |
| | |
| == Step 1: Test Manager API Connectivity ==
| |
| | |
| Before attempting a reload, verify that the GUI can reach the sensor's Manager API port (default 5029).
| |
| | |
| Test connectivity from the GUI server:
| |
| <pre>
| |
| # Replace <PROBE_IP> with your sensor's actual IP address | |
| echo 'getversion' | nc <PROBE_IP> 5029
| |
| </pre>
| |
| | |
| <dl>
| |
| <dt>Expected output:</dt><dd>A version string like <code>voipmonitor 8.0.0-SVN.10</code></dd>
| |
| <dt>If no output/connection times out:</dt><dd>The GUI cannot reach the sensor. This indicates a network connectivity problem.</dd>
| |
| </dl>
| |
| | |
| === Common Connectivity Issues ===
| |
| | |
| * <b>Firewall blocking port 5029</b> - Ensure port 5029/TCP is open on the sensor's firewall
| |
| * <b>Wrong IP address in Settings > Sensors</b> - Verify the Manager IP matches the sensor's actual IP
| |
| * <b>NAT/ Routing issue</b> - For sensors behind NAT, use the Server API method instead (see below)
| |
| | |
| == Step 2: Reload Methods ==
| |
| | |
| If connectivity test succeeds, use one of these reload methods:
| |
| | |
| === Method 1: Web GUI Reload Button ===
| |
| | |
| 1. Log in to the VoIPmonitor GUI
| |
| 2. Navigate to Control Panel (Dashboard)
| |
| 3. Click the green <b>reload sniffer</b> button
| |
| 4. Look for error message if reload fails
| |
| | |
| === Method 2: CLI Manager API ===
| |
| | |
| <pre>
| |
| echo 'reload' | nc <PROBE_IP> 5029
| |
| </pre>
| |
| | |
| Use this if you cannot access the GUI or need automation.
| |
| | |
| === Method 3: Server API (for Client/Server Mode) ===
| |
| | |
| If sensors are in client/server mode and manager ports aren't accessible, use the central server:
| |
| | |
| <pre>
| |
| # Step 1: List connected sensors and get sensor_id | |
| echo 'list_active_clients' | nc <SERVER_IP> 5029
| |
| | |
| # Step 2: Send reload command via Server API port (usually 60024)
| |
| echo '{"type_connection":"gui_command","sensor_id":<SENSOR_ID>,"command":"reload"}' | nc <SERVER_IP> 60024
| |
| </pre>
| |
| | |
| Replace `<SENSOR_ID>` with the ID from Step 1 and `<SERVER_IP>` with the central server's IP.
| |
| | |
| == Step 3: Immediate Workaround - Restart Sniffer Service ==
| |
| | |
| If the reload fails and you cannot resolve the connectivity issue immediately, you can force the sensor to reload rules by restarting the service on the probe:
| |
| | |
| === Option A: SSH to Sensor and Restart ===
| |
| | |
| <pre>
| |
| # SSH to the sensor
| |
| ssh <SENSOR_IP>
| |
| | |
| # Check current status
| |
| systemctl status voipmonitor
| |
| | |
| # Restart the service
| |
| sudo systemctl restart voipmonitor
| |
| </pre>
| |
| | |
| === Option B: Restart from Central Server (if available) ===
| |
| | |
| Some deployments allow remote restart via the Manager API:
| |
| <pre>
| |
| # Note: This command depends on sensor configuration
| |
| echo 'restart' | nc <PROBE_IP> 5029
| |
| </pre>
| |
| | |
| == How to Verify the Fix ==
| |
| | |
| After reloading rules, test that they are active:
| |
| | |
| 1. <b>Check logs for reload confirmation:</b>
| |
| <pre>
| |
| # Debian/Ubuntu
| |
| tail -f /var/log/syslog | grep voipmonitor
| |
| | |
| # CentOS/RHEL
| |
| tail -f /var/log/messages | grep voipmonitor
| |
| </pre>
| |
| Look for messages like <code>Rules reloaded</code> or <code>capture rules re-read</code>.
| |
| | |
| 2. <b>Make a test call</b> that should trigger your new rule and verify the recording behavior matches expectations.
| |
| | |
| 3. <b>Monitor CDR view</b> to confirm captured/dropped call logs match your rule configuration.
| |
| | |
| == Preventing Future Issues ==
| |
| | |
| * <b>Stable network connectivity</b> between GUI and sensors is critical for rule management
| |
| * <b>Use SNMP monitoring</b> to及时发现网络连接中断
| |
| * <b>Consider client/server mode</b> if sensors are in different networks - the Server API uses persistent connections that are more reliable
| |
| | |
| == AI Summary for RAG ==
| |
| | |
| '''Summary:''' This guide provides troubleshooting steps for when capture rule changes in the GUI are not being applied to sensors. It explains how to test Manager API connectivity using the <code>getversion</code> command, identify common network issues (firewall, wrong IP, NAT), and provides three methods to reload rules: GUI button, CLI Manager API, and Server API for client/server deployments. It includes an immediate workaround of restarting the sniffer service on the probe if reload fails due to connectivity issues. The guide also explains how to verify the fix through logs and test calls.
| |
| | |
| '''Keywords:''' capture rules troubleshooting, reload not working, getversion, manager api, connectivity, firewall, port 5029, restart voipmonitor, list_active_clients, sensor
| |
| | |
| '''Key Questions:'''
| |
| * Why are capture rules not being applied after I change them in the GUI?
| |
| * How do I test if the GUI can reach the sensor's Manager API?
| |
| * What does the getversion command do?
| |
| * How can I reload capture rules if the sensor is behind NAT?
| |
| * How do I restart the sniffer service on a remote sensor?
| |
| * How do I verify that capture rules have been reloaded?
| |