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.

IMPORTANT: This is a TEMPORARY workaround only. You must disable this option after the upgrade completes.

# Method 1: 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

Method 2: Configure via the Web GUI

1. Navigate to Settings -> Sensors in the VoIPmonitor GUI
2. Click the Edit icon (pencil) next to the sensor you want to upgrade
3. Scroll down or search for the upgrade_try_http_if_https_fail option
4. Set it to yes
5. Click Save

After restarting the service (or saving in the GUI), attempt the upgrade again. 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.

After the Upgrade Completes:

Once the upgrade is successful, DISABLE the upgrade_try_http_if_https_fail option to restore secure HTTPS-only downloads:

# Edit voipmonitor.conf and remove or comment out this line:
# upgrade_try_http_if_https_fail = yes

# Or set it explicitly to no:
upgrade_try_http_if_https_fail = no

# Restart the service
systemctl restart voipmonitor

Or via the GUI:

1. Navigate to Settings -> Sensors
2. Edit the sensor
3. Set upgrade_try_http_if_https_fail to no
4. Click Save

Security Note: HTTP downloads are less secure than HTTPS because they are unencrypted. Use the HTTP fallback option only as a temporary workaround for legacy sensors that cannot connect via modern TLS protocols. After upgrading to a sensor version 31.8 or newer (which supports TLS 1.3), always disable 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.

Service Fails to Start After Upgrade Due to Missing Database Table

If the VoIPmonitor sensor service fails to start after an upgrade with an error message like Table 'voipmonitor.cdr_audio_transcribe' doesn't exist, this indicates that new database tables introduced in the upgraded version were not created during the upgrade process.

This typically occurs when:

• The sensor binary was manually updated without updating the database schema
• The database schema update step was skipped or failed
• A new feature (such as audio transcription) was added that requires a new table

Symptoms:

• Service fails to start after upgrade
• Error log shows: Table 'voipmonitor.TABLE_NAME' doesn't exist (e.g., cdr_audio_transcribe, cdr_whisper, or other new tables)
• The error message identifies a specific missing table

Resolution: Create the Missing Table Manually

To fix this issue, you need to execute the SQL statement to create the missing table in your VoIPmonitor database.

1. Connect to the MySQL server used by the affected sensor host

mysql -h your_db_host -u your_db_user -p voipmonitor

Replace Template:Code and Template:Code with your actual database host and username. You will be prompted for the database password.

2. Execute the appropriate SQL statement for the missing table

For example, if the missing table is Template:Code (introduced in version 2024.11.2 for audio transcription features):

CREATE TABLE `cdr_audio_transcribe` (
  `ID` bigint unsigned NOT NULL AUTO_INCREMENT,
  `calldate` datetime NOT NULL,
  `fbasename` varchar(255) DEFAULT NULL,
  `a_language` varchar(10) DEFAULT NULL,
  `b_language` varchar(10) DEFAULT NULL,
  `a_text` mediumtext,
  `b_text` mediumtext,
  `a_segments` mediumtext,
  `b_segments` mediumtext,
  PRIMARY KEY (`ID`,`calldate`),
  KEY `fbasename` (`fbasename`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3 COMPRESSION='lz4'
/*!50500 PARTITION BY RANGE COLUMNS(calldate)
(PARTITION p202411 VALUES LESS THAN ('2024-12-01') ENGINE = InnoDB,
 PARTITION p202412 VALUES LESS THAN ('2025-01-01') ENGINE = InnoDB,
 PARTITION p_future VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */

3. Adjust the partition definitions as needed for your current date

The example above shows partitions for November and December 2024. When creating the table:

• Create partitions covering historical data periods that exist in your Template:Code table
• Ensure the last partition uses Template:Code to handle future data automatically
• You can add more partitions as your data grows using Template:Code

4. Restart the VoIPmonitor service

systemctl restart voipmonitor

Or on older systems:

service voipmonitor restart

Alternative Solution: Import Complete Schema File

If you prefer a simpler approach (use with caution on production databases), you can import the complete schema creation file. This is designed to add missing tables without affecting existing data:

# Import the schema, which will add missing tables
mysql -u root -p voipmonitor < /usr/local/share/voipmonitor/sql/create_tables.sql

However, this method is generally NOT recommended for production databases because:

• It may try to recreate existing tables (though most SQL scripts use Template:Code)
• It takes longer than creating just the missing table
• You have less control over partition configuration

Verification:

After creating the missing table and restarting the service, verify that the service starts successfully:

# Check service status
systemctl status voipmonitor

You should see output indicating the service is Template:Code.

Check the service log to confirm no more table-related errors:

journalctl -u voipmonitor -n 50 | grep -i "table\|error"

If no errors appear, the issue is resolved.

Prevention:

To avoid this issue in future upgrades:

• Always follow the complete upgrade procedure, which includes database schema updates
• For GUI upgrades, ensure the sensor can execute SQL schema updates (check database permissions)
• For manual upgrades, check the release notes for any required database changes
• Test upgrades in a staging environment before applying to production

For more information on audio transcription features, see Whisper or Audio_transcription documentation.

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 (Template:Code). 2) Downloading the desired static binary Template:Code package using Template:Code. 3) Backing up the old binary, copying the new one to Template:Code, and setting execute permissions with Template:Code. 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 Template:Code is mounted with the Template:Code flag (with resolution steps: check mount options, remount Template:Code with Template:Code, edit Template:Code to remove Template:Code 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 Template:Code 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 Template:Code to the sensor's Template:Code 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 Template:Code configuration option in Template:Code to specify a proxy server for HTTP/HTTPS downloads (syntax: Template:Code or with authentication). 2) Manually copy the upgraded sniffer binary from another working sensor using Template:Code, then overwrite the old binary on the failing sensor. Troubleshooting tips include checking DNS resolution (Template:Code), network connectivity (Template:Code), 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 Template:Code to Template:Code and restarting the service (or via GUI: Settings -> Sensors -> Edit sensor -> search for option and set to yes) - this allows the sensor to automatically fall back to HTTP if HTTPS fails due to TLS version issues (recommended for old sensors). CRITICAL: This is a TEMPORARY workaround only - you MUST disable this option after the upgrade completes by removing the line from Template:Code or setting it to Template:Code (or via GUI: Settings -> Sensors -> Edit -> set to no). HTTP downloads are less secure than HTTPS and should only be used as a temporary measure. 2) Use the manual upgrade procedure (Method 2) to transfer the binary manually via SCP from another machine. 3) Use the Template:Code option to route connections through a proxy server that supports modern TLS protocols (for corporate networks). 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 Template:Code lacks the execute permission bit AFTER the upgrade completes, causing the service to fail with Permission denied when starting. This can happen if the Template:Code command was omitted during the upgrade process or if permissions were not preserved when copying the binary. Diagnosis involves checking file permissions with Template:Code (look for missing 'x' flags in Template:Code vs executable Template:Code). Resolution steps: 1) Ensure logged in as root (Template:Code or Template:Code), 2) Add execute permissions with Template:Code, 3) Verify permissions with Template:Code, 4) Start service with Template:Code, 5) Verify running with Template:Code. Prevention: Always include Template:Code after copying the binary during manual upgrades. GUI upgrade method handles this automatically. The document also includes a troubleshooting section for "Service Fails to Start After Upgrade Due to Missing Database Table". This error occurs when the service fails after an upgrade with an error like "Table 'voipmonitor.cdr_audio_transcribe' doesn't exist", indicating that new database tables introduced in the upgraded version were not created during the upgrade process. This happens when the sensor binary was manually updated without updating the database schema, the database schema update step was skipped or failed, or a new feature was added that requires a new table (such as audio transcription). Resolution: Connect to the MySQL server used by the sensor host and execute the SQL statement to create the missing table. For example, if the missing table is cdr_audio_transcribe (introduced in version 2024.11.2), create it with the full schema including columns (ID, calldate, fbasename, a_language, b_language, a_text, b_text, a_segments, b_segments), primary key (ID, calldate), KEY on fbasename, ENGINE=InnoDB, DEFAULT CHARSET=utf8mb3, COMPRESSION=lz4, and PARTITION BY RANGE COLUMNS(calldate). Adjust the partition definitions as needed for the current date, creating partitions for historical data periods and ensuring the last partition uses LESS THAN MAXVALUE. Alternatively, import the complete schema file (/usr/local/share/voipmonitor/sql/create_tables.sql), but this is NOT recommended for production databases because it may be slower and gives less control over partition configuration. After creating the table, restart the voipmonitor service. Verification includes checking service status with systemctl status voipmonitor and checking logs with journalctl -u voipmonitor -n 50 | grep -i "table\|error". Prevention: Always follow the complete upgrade procedure including database schema updates, ensure the sensor has database permissions to execute schema updates for GUI upgrades, check release notes for required database changes for manual upgrades, and test upgrades in staging environments first. 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, missing database table, table doesn't exist, cdr_audio_transcribe, cdr_whisper, database schema update, CREATE TABLE, MySQL table creation, partition configuration, RANGE COLUMNS, utf8mb3, lz4 compression, InnoDB, manual table creation, database upgrade, schema file, create_tables.sql, 2024.11.2 upgrade, audio transcription table, Whisper table, service startup error, database error, missing table after upgrade 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?
• How do I fix a missing database table error after upgrade?
• What does "Table 'voipmonitor.cdr_audio_transcribe' doesn't exist" mean?
• How do I create the cdr_audio_transcribe table manually?
• What SQL do I run to fix missing table after sensor upgrade?
• Why does the service fail to start after upgrade with missing table?
• How do I create missing database partitions for cdr_audio_transcribe?
• What is the schema for cdr_audio_transcribe table?
• Should I import create_tables.sql after sensor upgrade?
• How do I adjust partition definitions for cdr_audio_transcribe?
• What version introduced cdr_audio_transcribe table?