Sniffer upgrade: Difference between revisions

Revision as of 11:28, 6 January 2026

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.

Navigate to Settings -> Sensors in the VoIPmonitor GUI.
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.
Click the blue UPGRADE button. A dropdown menu will appear.
Select the desired version from the list. The list will contain the latest stable release as well as several previous versions for downgrading.
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: Template:Code

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:

Log in to the local GUI
Navigate to System settings -> System configuration
Disable the AES-related encryption options
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
systemctl restart voipmonitor

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 Template:Code 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 Template:Code 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

Navigate to Settings -> Sensors in the VoIPmonitor GUI
Click the Edit icon (pencil) next to the sensor you want to upgrade
Scroll down or search for the upgrade_try_http_if_https_fail option
Set it to yes
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:

Navigate to Settings -> Sensors
Edit the sensor
Set upgrade_try_http_if_https_fail to no
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: Guide for upgrading/downgrading the VoIPmonitor sensor. Two methods: 1) GUI upgrade (recommended) - Settings -> Sensors -> UPGRADE button. 2) Manual CLI upgrade - stop service, download binary with wget, backup old binary, copy new to Template:Code, set permissions with Template:Code, start service. Includes version verification (Template:Code or Manager API port 5029). Covers reinstalling after OS upgrades (Debian 10→11→12) using fresh installation with config backup. Troubleshooting sections: duplicate Manager IP causing multiple sensors to upgrade, "need AES!" error (fix with Template:Code or Template:Code), deprecated options in v2025.09.1 (vxlan, sipdefrag, etc. replaced by udp_port_vxlan, snaplen), "Permission denied" during upgrade (Template:Code on /tmp - remount with exec), "Could not resolve host" (use Template:Code or manual SCP), TLS protocol errors (Template:Code temporarily), missing database tables after upgrade (manually CREATE TABLE).

Keywords: upgrade, downgrade, sniffer, sensor, GUI upgrade, manual upgrade, wget, tar.gz, systemctl, chmod +x, version check, Manager API, OS upgrade, reinstall, fresh installation, need AES, delete_aes_key, manager_enable_unencrypted, deprecated options, 2025.09.1, vxlan, sipdefrag, snaplen, permission denied, noexec, /tmp, fstab, curlproxy, proxy, scp, TLS error, upgrade_try_http_if_https_fail, HTTP fallback, missing table, cdr_audio_transcribe, database schema

Key Questions:

How do I upgrade the VoIPmonitor sniffer?
How can I downgrade the sensor to a previous version?
How do I perform a manual upgrade via command line?
How can I check the current sniffer version?
What should I do after upgrading the operating system?
Why does upgrading one sensor upgrade multiple sensors?
How do I fix "sniffer error: need AES!" after upgrade?
Which configuration options are deprecated in version 2025.09.1?
How do I fix "Permission denied" during sensor upgrade?
How do I fix "Could not resolve host" during GUI upgrade?
How do I fix SSL/TLS protocol version error during upgrade?
How do I fix missing database table error after upgrade?