Sniffer upgrade

This guide provides step-by-step instructions for upgrading or downgrading the VoIPmonitor sensor (sniffer). There are two primary methods: using the Web GUI for simplicity, or performing a manual update via the command line for more control.

Method 1: Upgrading via the Web GUI (Recommended)

This is the easiest and safest way to manage your sensor versions. This method only works for sensors that are currently running and connected to the GUI.

1. Navigate to Settings -> Sensors in the VoIPmonitor GUI.
2. Find the sensor you wish to update. If you need to see more details or older versions, click the [+] icon to expand the sensor's information.
3. Click the blue UPGRADE button. A dropdown menu will appear.
4. Select the desired version from the list. The list will contain the latest stable release as well as several previous versions for downgrading.
5. The GUI will automatically handle the download and restart of the remote sensor service.

Method 2: Manual Upgrade/Downgrade (via Command Line)

This method gives you full control and is necessary if the GUI method is not available or unresponsive. Use this method if the "upgrade sensor" button in the GUI is unresponsive or does not work properly. It is also useful when you need to install a specific development build.

Step 1: Stop the Running Sniffer

First, log in to the sensor's server via SSH and stop the service. For modern systems using systemd:

systemctl stop voipmonitor

For older systems using SysV init:

/etc/init.d/voipmonitor stop

Tip: If the service fails to stop, you may need to terminate the process manually as a last resort: `killall -9 voipmonitor`

Step 2: Download the Sniffer Archive

Download the latest stable static binary from the official VoIPmonitor website. This package contains all necessary files.

# This command downloads the latest stable 64-bit static sniffer
wget https://www.voipmonitor.org/current-stable-sniffer-static-64bit.tar.gz -O voipmonitor-sniffer.tar.gz

Alternative: Direct Gzipped Binary Download

You can also download the raw gzipped binary directly from the download server. This method downloads a smaller file and does not require extracting from an archive:

# For a specific version (replace with desired version)
wget https://download.voipmonitor.org/senzor/download/2025.04.4/voipmonitor.gz.64 -O ./voipmonitor.gz

# Unzip the file
gunzip ./voipmonitor.gz

# Copy to correct location (preserving executable attributes)
cp voipmonitor /usr/local/sbin/voipmonitor

# Ensure it is executable
chmod +x /usr/local/sbin/voipmonitor

If you need a specific older version or a special build (like one with SS7 support), you must get the direct download link from the support team or historical archives and use it with the `wget` command.

Step 3: Install the New Binary

# Extract the downloaded archive
tar xzf voipmonitor-sniffer.tar.gz

# Navigate into the new directory. The wildcard (*) handles any version number.
cd voipmonitor-*-static

# (Recommended) Back up your old binary
mv /usr/local/sbin/voipmonitor /usr/local/sbin/voipmonitor.backup

# Copy the new binary into place
cp ./voipmonitor /usr/local/sbin/voipmonitor

# Ensure the new binary is executable
chmod +x /usr/local/sbin/voipmonitor

Step 4: Start the Service

Finally, start the sniffer service again.

systemctl start voipmonitor

Or for older systems:

/etc/init.d/voipmonitor start

Verifying the Version

After an upgrade or downgrade, it's important to verify that the correct version is running.

Local Check

You can check the version directly from the binary on the sensor's server:

/usr/local/sbin/voipmonitor --version

Or, for more detail:

/usr/local/sbin/voipmonitor | head

Remote Check (via Manager API)

If the sniffer is running, you can query its version remotely using its manager API (default port 5029):

echo 'sniffer_version' | nc 127.0.0.1 5029

Reinstalling After Operating System Upgrades

After a major operating system upgrade (for example, upgrading from Debian 10 to Debian 11 or Debian 11 to Debian 12), the VoIPmonitor sniffer service may stop working or report errors such as "sensor is not registered" or fail to start properly. This occurs because system libraries, kernel interfaces, or service management systems (systemd) may have changed incompatibly with the existing installation.

When the sensor fails after an OS upgrade, the recommended solution is to perform a fresh installation using the static binary method rather than attempting to upgrade the existing installation.

Fresh Installation After OS Upgrade

Follow these steps to perform a fresh clean installation:

1. Stop and disable the old service

sudo systemctl stop voipmonitor
sudo systemctl disable voipmonitor

2. Back up your configuration file (important!)

sudo cp /etc/voipmonitor.conf /etc/voipmonitor.conf.backup

This preserves your database connection settings, network interface configuration, and sensor ID.

3. Download the latest stable static binary

wget https://www.voipmonitor.org/current-stable-sniffer-static-64bit.tar.gz -O voipmonitor-sniffer.tar.gz

Use the appropriate URL for your architecture (32-bit or ARM) if needed.

4. Extract and run the installation script

tar xzf voipmonitor-sniffer.tar.gz
cd voipmonitor-*-static
sudo ./install-script.sh

5. Restore your configuration file

sudo cp /etc/voipmonitor.conf.backup /etc/voipmonitor.conf

6. Start and enable the service

sudo systemctl enable voipmonitor
sudo systemctl start voipmonitor

7. Verify the sensor is working

• Check service status: sudo systemctl status voipmonitor
• View logs: sudo journalctl -u voipmonitor -f
• If using client-server mode, verify the sensor appears in the GUI under Settings -> Sensors

For Client-Server deployments, you may need to update firewall rules on the new operating system to allow traffic on the manager port (default 5029) and packet buffer sender port (default 60024).

The fresh installation ensures that all service files, systemd configurations, and dependencies are compatible with the new operating system version, while preserving your original configuration settings.

Troubleshooting

Upgrading One Sensor Upgrades Multiple Sensors

If attempting to upgrade a single sensor causes another sensor (or the entire GUI) to upgrade unexpectedly, the issue is likely due to duplicate sensor configuration.

Symptoms:

• Clicking the UPGRADE button for Sensor A causes Sensor B to update instead
• A sensor configured with 127.0.0.1 (localhost) affects multiple other sensors
• All sensors on the Settings > Sensors page show identical version after upgrade

Root Cause: This occurs when multiple sensor entries in the GUI are configured with the same Manager IP and Manager Port. The GUI sends upgrade commands to a specific endpoint (IP + Port), and any sensor entry pointing to that endpoint will reflect the change.

In particular, if one sensor is configured with 127.0.0.1 (localhost) instead of its actual IP address, it will point to the GUI server itself. This causes unexpected behavior where operations on other sensors may affect the GUI server's local sensor if it exists.

Resolution:

1. Navigate to Settings → Sensors in the GUI 2. Examine the Manager IP and Manager Port columns for each sensor 3. Look for sensors configured with 127.0.0.1 or duplicate IP/Port combinations 4. For any sensor using 127.0.0.1, change it to the actual IP address of that sensor 5. Ensure each sensor has a unique Manager IP (or unique Manager Port if multiple instances run on the same host) 6. Click Save to apply the changes

Verification: After correcting the configuration, attempt the upgrade again on the target sensor. Verify that only that specific sensor updates its version.

For more information on configuring sensors, see GUI Settings.

"New Sensor Version Available" Notification Persists After Upgrade

If the GUI continues to display a "new sensor version available" notification even after all sensors have been updated to the latest version, this is typically caused by the development version upgrade setting.

Symptoms:

• All sensors show the latest version (e.g., 30.4) in Settings > Sensors
• GUI still displays "New sniffer version available" notification
• Clicking the notification shows no newer versions available

root Cause: The GUI may be comparing against development/snapshot versions when the development version option is enabled.

Resolution:

1. Navigate to System Configuration -> Advanced in the GUI 2. Ensure the option "enable upgrade sniffer to development version" is disabled 3. Log out of the GUI and log back in to refresh the session 4. If the notification persists, wait for a period of time as the system may need time to propagate the version information to all components

Prevention: Keep the "enable upgrade sniffer to development version" setting disabled unless you specifically need to test prerelease or snapshot builds. Development versions are not recommended for production use.

"sniffer error: need AES!" After Sensor Upgrade

If you see the error message "sniffer error: need AES!" when accessing sensor configuration from a local GUI after a sensor upgrade, this indicates that the sensor is now enforcing AES encryption for the manager API communication channel, and the local GUI has outdated encryption keys in its database.

This commonly occurs when:

• You are managing a sensor through a dedicated local GUI rather than the main GUI
• After upgrading the sensor, the encryption requirements or keys have changed
• The local GUI database contains the old encryption key that no longer matches the upgraded sensor

Symptoms:

• Local GUI cannot read or write sensor configuration
• Error message: "sniffer error: need AES!" appears in the GUI
• Issue occurs only after a sensor upgrade

Solution 1: Remove AES Encryption Key (Recommended for Local GUIs)

Remove the AES encryption key from the local GUI database so the GUI can re-establish communication with the sensor:

# Navigate to the GUI directory
cd /var/www/voipmonitor

# Remove the old AES encryption key
php php/run.php delete_aes_key

This clears the encryption key from the local GUI database. The GUI will then attempt to communicate with the sensor using the current authentication settings.

Solution 2: Disable AES Encryption via GUI

If you prefer to disable AES encryption entirely for this sensor:

1. Log in to the local GUI
2. Navigate to System settings -> System configuration
3. Disable the AES-related encryption options
4. Save the settings

Note: Disabling AES encryption reduces security but may simplify local management in certain scenarios.

Solution 3: Disable AES Encryption in Sensor Configuration

If you need to allow unencrypted communication at the sensor level (for example, when accessing the manager API via command line tools or scripts), you can disable the encryption requirement directly in the sensor's configuration file:

# Edit the sensor's voipmonitor.conf file
nano /etc/voipmonitor.conf

# Add this line to disable encryption for the manager API:
manager_enable_unencrypted = yes

# Restart the VoIPmonitor sensor service
service voipmonitor restart

This configuration option disables encryption enforcement for the manager API (port 5029), allowing unencrypted commands such as listcalls, listregisters, and other manager commands to be executed without authentication requirements.

Warning: This option reduces security as it allows unencrypted configuration access to the sensor. Only use this in trusted network environments or for testing/debugging purposes. For production environments, use proper encryption whenever possible.

Prevention: Main GUI vs Local GUI

To avoid this issue in the future, consider managing sensors through the main GUI rather than using dedicated local GUIs:

• Main GUI approach: Manage all sensors centrally from the primary GUI. When upgrading sensors through the main GUI (Settings -> Sensors), the GUI and sensor configurations stay synchronized.
• Local GUI approach: If you must use a dedicated local GUI for a sensor, be aware that sensor upgrades may require running `delete_aes_key` to clear stale encryption keys from the local database.

Technical Background:

The "need AES!" error means the sensor's manager API is rejecting unencrypted or improperly encrypted commands from the GUI. This security feature protects against unauthorized configuration changes. After an upgrade, if the encryption keys do not match (either due to changed defaults or required password settings), the communication fails until the mismatch is resolved.

For more information on sensor communication and security settings, see Settings and Sniffer_configuration.

Deprecated Configuration Options

When upgrading to sensor version 2025.09.1 or newer, certain configuration options that were supported in older versions have been removed or deprecated. While the sniffer will automatically ignore unknown options, it is recommended to remove these obsolete directives from your `voipmonitor.conf` file for clarity and to avoid confusion.

Options Removed in 2025.09.1

The following configuration options are no longer supported in sensor version 2025.09.1 and should be removed from your configuration file:

• vxlan
• vxlan_port
• vxlan_skipcrc
• packet_buffer_total_size
• udp_reassembly
• udp_reassembly_max_size
• sipdefrag
• sipdefrag_maxpacket
• defragment_max_size
• defragment_timeout
• ignore_sip_parsing_errors
• sip_auto_clean
• max_sip_size
• sip_force_content_length
• sanity_checks
• check_sip_header
• interface_snaplen

Recommended Replacements

If you were previously using any of the removed options, consider the following alternatives:

• VXLAN support: The old `vxlan` family of options has been replaced with `udp_port_vxlan = 4789` (default: 4789) for VXLAN tunnel detection in cloud environments like AWS.

• Packet buffer sizing: The `packet_buffer_total_size` option is no longer needed. Packet buffer memory is now managed automatically via `max_buffer_mem` (default: 2000 MB) and `ringbuffer` (default: 50 MB, increase to 500+ for >100 Mbit traffic).

• UDP reassembly and SIP defragmentation: These features are now handled internally by the sniffer. The `udp_reassembly*` and `sipdefrag*` options are no longer configurable.

• SIP sanitization options: Options like `max_sip_size`, `sip_force_content_length`, `sanity_checks`, and `check_sip_header` have been removed as the sniffer now includes built-in improvements for handling malformed SIP packets.

• Interface snap length: `interface_snaplen` has been removed. Use the `snaplen parameter instead (default: 3200, increase to 65535 or 20000 for large SIP packets with extensive SDP or custom headers).

Remaining Supported Options

The following options mentioned in the upgrade context remain supported and should be kept if needed in your environment:

• udp_port_vxlan = 4789 - VXLAN tunnel detection
• auto_enable_use_blocks = yes - Required for deduplication and correct RTP association
• deduplicate = yes - Packet deduplication
• snaplen = 3200 - Packet capture length

Verification

After removing deprecated options and adding any needed replacements, restart the sensor and verify it starts without warnings about unknown options:

systemctl restart voipmonitor
journalctl -u voipmonitor -n 50 | grep -i "unknown\|option"

If you see warnings about unknown options, identify and remove those directives from your configuration file.

"Permission denied" During Manual Upgrade

If you encounter "Permission denied" errors when trying to execute the upgrade binary or installation scripts from the `/tmp` directory, this is typically caused by the `/tmp` partition being mounted with the `noexec` flag. Many modern Linux distributions (Debian, Ubuntu, RHEL, CentOS 8+) mount `/tmp` with `noexec` for security reasons, which prevents the execution of binaries or scripts located in that directory.

Symptoms:

• Permission denied error when running the downloaded binary or install script from `/tmp`
• Error occurs immediately after downloading and extracting the archive in `/tmp`
• Service fails to restart after the upgrade attempt

Resolution:

The proper fix is to remount the `/tmp` partition with execute permissions rather than avoiding `/tmp` entirely:

1. Check the current mount options

mount | grep "/tmp"

Look for the noexec flag in the output (e.g., /dev/sda1 on /tmp type ext4 (rw,nosuid,nodev,noexec,relatime)).

2. Remount /tmp with execute permissions (temporary fix)

mount -o remount,exec /tmp

3. Re-run the upgrade process from Step 3 above

cd /tmp/voipmonitor-*-static
cp ./voipmonitor /usr/local/sbin/voipmonitor
chmod +x /usr/local/sbin/voipmonitor

4. Make the change permanent by editing /etc/fstab

sudo nano /etc/fstab
# OR
sudo vi /etc/fstab

Find the line corresponding to the `/tmp` mount point and remove the noexec option. For example, change:

tmpfs    /tmp    tmpfs    defaults,nosuid,nodev,noexec    0    0

To:

tmpfs    /tmp    tmpfs    defaults,nosuid,nodev    0    0

5. Apply the permanent fix by remounting all filesystems

sudo mount -a

6. Verify the fix

mount | grep "/tmp"
# Should no longer show "noexec" in the options

7. Start the service

systemctl start voipmonitor

Important Notes:

• The remount,exec command only applies until the next reboot. Editing /etc/fstab is required for a permanent solution.
• Removing noexec from `/tmp` is a standard practice for VoIPmonitor sensors that need to execute upgrade scripts in the temporary directory.
• If security policies strictly require noexec on `/tmp`, download and extract the archive to an alternative directory like `/usr/src/voipmonitor-upgrade` instead.

For more information on system hardening options, consult your operating system's security documentation.

Service Fails to Start After Upgrade Due to "Permission denied"

If the VoIPmonitor sensor service fails to start with a "Permission denied" error AFTER the upgrade has completed, this typically indicates that the installed binary at `/usr/local/sbin/voipmonitor` lacks the execute permission bit. This can happen if the `chmod +x` command was omitted during the upgrade process, or if permissions were not preserved when copying the binary.

Symptoms:

• Service fails to start after running `systemctl start voipmonitor`
• System logs show "Permission denied" when attempting to execute `/usr/local/sbin/voipmonitor`
• The upgrade appears to complete successfully, but the service will not run
• When manually running `/usr/local/sbin/voipmonitor --version`, you get a "Permission denied" error

Diagnosis:

Check the file permissions on the binary:

ls -l /usr/local/sbin/voipmonitor

Look for the executable flags in the permission string:

• If you see -rw-r--r-- (no 'x' flags), the file lacks execute permissions
• If you see -rwxr-xr-x (with 'x' flags), the file is executable

Also verify the user running the service has permission to execute the file:

# Check which user runs the voipmonitor service
systemctl cat voipmonitor.service | grep "User="

If no User is specified, it runs as root by default.

Resolution:

1. Ensure you are logged in as root

If you are not root, switch to the root user:

sudo -i
# OR
su -

2. Add execute permissions to the binary

chmod +x /usr/local/sbin/voipmonitor

3. Verify the permissions are correct

ls -l /usr/local/sbin/voipmonitor
# Should now show: -rwxr-xr-x (with 'x' flags)

4. Start the service

systemctl start voipmonitor
systemctl status voipmonitor

5. Verify the service is running

ps aux | grep voipmonitor
usr/local/sbin/voipmonitor --version

Prevention:

This issue highlights the importance of including the `chmod +x` step during manual upgrades. When performing manual command-line upgrades, always follow the complete procedure:

# After copying the new binary:
cp ./voipmonitor /usr/local/sbin/voipmonitor
chmod +x /usr/local/sbin/voipmonitor  # CRITICAL STEP
systemctl start voipmonitor

The upgrade procedure is documented in Method 2: Manual Upgrade/Downgrade.

If using the GUI upgrade method (recommended), the system handles this automatically and this issue should not occur.

"Could not resolve host: download.voipmonitor.org" During GUI Upgrade

If the GUI upgrade fails with the error sniffer error: failed download upgrade: Could not resolve host: download.voipmonitor.org, this indicates that the sensor cannot reach the VoIPmonitor download server. This is typically a DNS, network, or proxy configuration issue.

Workaround 1: Use curlproxy Configuration

If the sensor requires a proxy server to access the Internet (common in corporate networks), configure the proxy settings in the sensor's voipmonitor.conf file:

# Edit the sensor's voipmonitor.conf file
nano /etc/voipmonitor.conf

# Add this line to configure the proxy (replace with your proxy address and port)
curlproxy = http://proxy.example.com:3128

# For authenticated proxy, use: curlproxy = http://username:password@proxy.example.com:3128

# Restart the VoIPmonitor service
systemctl restart voipmonitor

After configuring the proxy, retry the GUI upgrade. The curlproxy option tells the sensor to use the specified proxy server for all HTTP/HTTPS download operations, including upgrades.

Workaround 2: Manual Binary Copy from Another Sensor

If the sensor cannot reach the download server at all (no Internet connectivity or strict firewall rules), you can manually copy the upgraded sniffer binary from another working sensor in your deployment:

# Step 1: Stop the service on the failing sensor
systemctl stop voipmonitor

# Step 2: Copy the new voipmonitor binary from a working sensor to the failing sensor
# Run this command from your management station or from the failing sensor:
scp working-sensor:/usr/local/sbin/voipmonitor /tmp/voipmonitor

# Step 3: Overwrite the old binary on the failing sensor
cp /tmp/voipmonitor /usr/local/sbin/voipmonitor

# Step 4: Ensure the new binary has execute permissions
chmod +x /usr/local/sbin/voipmonitor

# Step 5: Start the service
systemctl start voipmonitor

# Step 6: Verify the version has updated
/usr/local/sbin/voipmonitor --version

Replace working-sensor with the hostname or IP address of a sensor that has the desired version installed. You can verify the version on the source sensor before copying.

After the upgrade, verify the new version appears in the GUI under Settings -> Sensors.

Troubleshooting Tips:

• DNS Resolution:** Check /etc/resolv.conf for valid DNS nameservers (e.g., nameserver 8.8.8.8).
• Network Connectivity:** Test if the sensor can reach the download server: ping -c 4 download.voipmonitor.org
• Firewall Rules:** Ensure outbound HTTPS (port 443) traffic is allowed to *.voipmonitor.org.

For information on other configuration options, see Sniffer_configuration.

SSL/TLS Protocol Version Error During Sensor Upgrade

If the sensor upgrade fails with an SSL/TLS protocol error such as:

sniffer error: failed download upgrade: error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version

This indicates that the sensor binary is attempting to connect to the VoIPmonitor download server using an outdated TLS protocol version (usually TLS 1.0 or 1.1), but the server requires a modern protocol (TLS 1.2 or higher). This typically occurs when the sensor binary is very old and lacks support for modern TLS versions.

Solution 1: Enable HTTP Fallback (Recommended for Old Sensors)

The simplest solution is to enable HTTP fallback for upgrade downloads. This allows the sensor to automatically fall back to HTTP if the HTTPS connection fails:

# Edit the sensor's voipmonitor.conf file
nano /etc/voipmonitor.conf

# Add this line to enable HTTP fallback for upgrades
upgrade_try_http_if_https_fail = yes

# Restart the VoIPmonitor sensor service
systemctl restart voipmonitor

After restarting the service, attempt the upgrade again via the GUI. The system will now try HTTPS first, and if it fails due to TLS version issues, it will automatically fall back to an HTTP connection.

Note: HTTP downloads are less secure than HTTPS but provide a practical workaround for legacy sensors that cannot be connected to the download server using modern protocols. Once upgraded to a sensor version 31.8 or newer (which supports TLS 1.3), you can consider removing this option to restore HTTPS-only downloads.

Solution 2: Manual Binary Transfer (For Sensors Without Internet Access)

If the HTTP fallback solution does not work or if the sensor does not have direct Internet access, use the manual upgrade procedure described in Method 2 above. This method involves downloading the binary on another machine and transferring it via SCP, which bypasses the sensor's internal downloader entirely.

Solution 3: Using curlproxy with Modern Proxy (For Corporate Networks)

If the sensor is behind a corporate firewall or proxy that enforces TLS versions, the sensor may need to route connections through a proxy server that supports modern TLS protocols:

# Edit the sensor's voipmonitor.conf file
nano /etc/voipmonitor.conf

# Add this line to configure a proxy server
curlproxy = http://proxy.example.com:3128

# Restart the VoIPmonitor sensor service
systemctl restart voipmonitor

Ensure that the proxy server can connect to download.voipmonitor.org using modern TLS protocols. The proxy handles the HTTPS connection on behalf of the legacy sensor.

AI Summary for RAG

Summary: This guide details the procedures for upgrading or downgrading the VoIPmonitor sensor. It presents two primary methods. The first and recommended method is using the Web GUI, by navigating to "Settings -> Sensors" and selecting a new version from the upgrade dropdown menu. The second method is a manual update via the command line, which involves four steps: 1) Stopping the voipmonitor service (`systemctl stop voipmonitor`). 2) Downloading the desired static binary `tar.gz` package using `wget`. 3) Backing up the old binary, copying the new one to `/usr/local/sbin/`, and setting execute permissions with `chmod`. 4) Starting the service again. The article also covers version verification methods, includes troubleshooting for sensor upgrade issues (duplicate Manager IP, localhost 127.0.0.1 configuration), troubleshooting for persistent "new sensor version available" notifications (caused by "enable upgrade sniffer to development version" setting), includes a specific section on encountering "Permission denied" errors during manual upgrades when `/tmp` is mounted with the `noexec` flag (with resolution steps: check mount options, remount `/tmp` with `exec`, edit `/etc/fstab` to remove `noexec` permanently), and provides a specific section on reinstalling after operating system upgrades (such as Debian 10 to 11 or 11 to 12). After a major OS upgrade when the sensor stops working or reports "sensor is not registered", the recommended solution is to perform a fresh installation using the static binary method while preserving the configuration file backup. Additionally, the document includes a troubleshooting section about the "sniffer error: need AES!" message that can occur after sensor upgrades when using local GUIs. This error happens when the sensor enforces AES encryption for the manager API and the local GUI database contains outdated encryption keys. The solutions are: 1) Run `php php/run.php delete_aes_key` in the GUI directory to remove the old encryption key, 2) Disable AES encryption via System settings -> System configuration in the GUI, or 3) Add `manager_enable_unencrypted = yes` to the sensor's voipmonitor.conf file to allow unencrypted manager API communication. To prevent this issue, it is recommended to manage sensors through the main GUI rather than dedicated local GUIs. The document also includes a "Deprecated Configuration Options" section for sensor version 2025.09.1 and newer, which lists 17 options that have been removed (vxlan, vxlan_port, vxlan_skipcrc, packet_buffer_total_size, udp_reassembly, udp_reassembly_max_size, sipdefrag, sipdefrag_maxpacket, defragment_max_size, defragment_timeout, ignore_sip_parsing_errors, sip_auto_clean, max_sip_size, sip_force_content_length, sanity_checks, check_sip_header, interface_snaplen) and provides recommended replacements where applicable (udp_port_vxlan, max_buffer_mem, ringbuffer, snaplen). The section also lists options that remain supported (udp_port_vxlan, auto_enable_use_blocks, deduplicate, snaplen) and provides verification commands to check for unknown options after configuration changes. The document further includes a troubleshooting section for the specific error: "sniffer error: failed download upgrade: Could not resolve host: download.voipmonitor.org". This error indicates the sensor cannot reach the VoIPmonitor download server. There are two workarounds: 1) Use the `curlproxy` configuration option in `/etc/voipmonitor.conf` to specify a proxy server for HTTP/HTTPS downloads (syntax: `curlproxy = http://proxy.example.com:3128` or with authentication). 2) Manually copy the upgraded sniffer binary from another working sensor using `scp`, then overwrite the old binary on the failing sensor. Troubleshooting tips include checking DNS resolution (`/etc/resolv.conf`), network connectivity (`ping download.voipmonitor.org`), and firewall rules (allow HTTPS port 443 to *voipmonitor.org). The document also includes a troubleshooting section for SSL/TLS protocol version errors during sensor upgrades (error message examples: "error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version"). This error occurs when an old sensor binary attempts to connect to the download server using outdated TLS protocols (TLS 1.0/1.1) while the server requires modern protocols (TLS 1.2+). There are three solutions: 1) Enable HTTP fallback by adding `upgrade_try_http_if_https_fail = yes` to `/etc/voipmonitor.conf` and restarting the service - this allows the sensor to automatically fall back to HTTP if HTTPS fails due to TLS version issues (recommended for old sensors). 2) Use the manual upgrade procedure (Method 2) to transfer the binary manually via SCP from another machine. 3) Use the `curlproxy` option to route connections through a proxy server that supports modern TLS protocols (for corporate networks). Note that HTTP downloads are less secure than HTTPS but provide a practical workaround for legacy sensors. Once upgraded to sensor version 31.8 or newer, which supports TLS 1.3, the option can be removed to restore HTTPS-only downloads. The document also includes a troubleshooting section for "Service Fails to Start After Upgrade Due to 'Permission denied'". This error occurs when the installed binary at `/usr/local/sbin/voipmonitor` lacks the execute permission bit AFTER the upgrade completes, causing the service to fail with Permission denied when starting. This can happen if the `chmod +x` command was omitted during the upgrade process or if permissions were not preserved when copying the binary. Diagnosis involves checking file permissions with `ls -l /usr/local/sbin/voipmonitor` (look for missing 'x' flags in `-rw-r--r--` vs executable `-rwxr-xr-x`). Resolution steps: 1) Ensure logged in as root (`sudo -i` or `su -`), 2) Add execute permissions with `chmod +x /usr/local/sbin/voipmonitor`, 3) Verify permissions with `ls -l`, 4) Start service with `systemctl start voipmonitor`, 5) Verify running with `ps aux | grep voipmonitor`. Prevention: Always include `chmod +x /usr/local/sbin/voipmonitor` after copying the binary during manual upgrades. GUI upgrade method handles this automatically. Keywords: upgrade, downgrade, update, sniffer, sensor, install, new version, old version, GUI upgrade, manual upgrade, command line, CLI, wget, tar.gz, systemctl, service, check version, verify, voipmonitor.org/download, troubleshooting, multiple sensors, duplicate IP, localhost, 127.0.0.1, Manager IP, operating system upgrade, OS upgrade, Debian 10, Debian 11, Debian 12, reinstall, fresh installation, sensor not registered, new sensor version available, notification persists, development version, enable upgrade sniffer to development version, System Configuration Advanced, System Configuration, need AES, AES error, AES encryption, encryption key, delete_aes_key, php run.php, local GUI, main GUI, sensor configuration upgrade, manager API, encryption mismatch, deprecated options, unsupported options, 2025.09.1, voipmonitor.conf, vxlan, vxlan_port, vxlan_skipcrc, packet_buffer_total_size, udp_reassembly, udp_reassembly_max_size, sipdefrag, sipdefrag_maxpacket, defragment_max_size, defragment_timeout, ignore_sip_parsing_errors, sip_auto_clean, max_sip_size, sip_force_content_length, sanity_checks, check_sip_header, interface_snaplen, udp_port_vxlan, auto_enable_use_blocks, deduplicate, snaplen, max_buffer_mem, ringbuffer, configuration cleanup, permission denied, noexec, /tmp, temporary directory, mount options, remount, exec, fstab, Debian, Ubuntu, RHEL, CentOS, security hardening, manager_enable_unencrypted, unencrypted manager API, Could not resolve host, download.voipmonitor.org, DNS error, network error, proxy configuration, curlproxy, authenticated proxy, manual binary copy, scp, copy from another sensor, offline upgrade, TLS protocol version error, SSL error, tlsv1 alert protocol version, upgrade_try_http_if_https_fail, HTTP fallback, HTTPS download failed, SSL routines:ssl3_read_bytes:tlsv1, certificate error, TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3, outdated TLS, modern TLS, download server TLS, old sensor, legacy sensor, failed download upgrade, service fails to start after upgrade, permission denied after upgrade, binary lacks execute permissions, chmod +x, /usr/local/sbin/voipmonitor, missing execute bit, file permissions, ls -l, -rwxr-xr-x, -rw-r--r--, executable flags, systemctl start fails Key Questions:

• How do I upgrade the VoIPmonitor sniffer?
• How can I downgrade the sensor to a previous version?
• What is the easiest way to update my remote sensors?
• How do I perform a manual upgrade of the sniffer using the command line?
• How can I check which version of the sniffer I am currently running?
• Where can I download the latest stable sniffer binary?
• Why does upgrading one sensor upgrade multiple sensors?
• How do I fix a sensor configured with 127.0.0.1?
• Why are all sensors updating when I upgrade only one?
• What should I do after upgrading the operating system (e.g., Debian 11 to Debian 12)?
• How do I fix a "sensor is not registered" error after an OS upgrade?
• How do I perform a fresh installation of the sniffer after an operating system upgrade?
• Why does the GUI still show "new sensor version available" after all sensors are updated?
• Which configuration options are deprecated in sensor version 2025.09.1?
• What options should I remove from voipmonitor.conf after upgrading to 2025.09.1?
• What are the deprecated options for the latest sniffer version?
• How do I clean up unsupported options from my voipmonitor.conf?
• What is the replacement for the vxlan configuration options?
• What replaced the deprecated interface_snaplen option?
• How do I verify my configuration file has no deprecated options?
• How do I fix "sniffer error: need AES!" after sensor upgrade?
• Why does my local GUI show "need AES!" error after sensor upgrade?
• How do I remove AES encryption key from GUI database?
• What is the delete_aes_key command for?
• How do I fix AES encryption mismatch between GUI and sensor?
• How do I disable encryption for manager API in sensor configuration?
• What is manager_enable_unencrypted used for?
• How do I fix "Could not resolve host: download.voipmonitor.org" during GUI upgrade?
• Why does the sensor upgrade fail with DNS or network errors?
• How do I configure proxy settings for sensor upgrades?
• What is curlproxy used for?
• How do I upgrade a sensor when it cannot download from the internet?
• How do I manually copy the sniffer binary from another sensor?
• Why do I get "Permission denied" errors when upgrading the sniffer?
• How do I fix "Permission denied" during sensor upgrade from /tmp?
• What causes "Permission denied" errors during manual upgrade?
• How do I remount /tmp with exec permissions?
• How do I remove noexec from /tmp mount?
• How do I permanently fix /tmp noexec issue?
• How do I edit fstab to allow execution in /tmp?
• How do I fix SSL/TLS protocol version error during sensor upgrade?
• What does "error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version" mean?
• Why does the sensor upgrade fail with TLS version errors?
• How do I enable HTTP fallback for sensor upgrades?
• What is upgrade_try_http_if_https_fail used for?
• How do I fix tlsv1 alert protocol version error?
• How do I upgrade an old sensor that uses outdated TLS protocols?
• Why does the voipmonitor service fail to start after an upgrade with "Permission denied"?
• How do I fix "Permission denied" when starting voipmonitor service after upgrade?
• What causes service startup failure after sensor upgrade?
• How do I check if the voipmonitor binary has execute permissions?
• How do I add execute permissions to /usr/local/sbin/voipmonitor?
• Why does systemctl start voipmonitor fail with Permission denied after upgrade?
• What file permissions does the voipmonitor binary need?
• Why does my upgraded sniffer binary lack execute permissions?
• How do I fix missing execute bit on voipmonitor binary?