Sniffer troubleshooting

This guide provides a systematic, step-by-step process to diagnose why the VoIPmonitor sensor might not be capturing any calls. Follow these steps in order to quickly identify and resolve the most common issues.

Step 1: Is the VoIPmonitor Service Running Correctly?

First, confirm that the sensor process is active and loaded the correct configuration file.

1. Check the service status (for modern systemd systems)

systemctl status voipmonitor

Look for a line that says Active: active (running). If it is inactive or failed, try restarting it with `systemctl restart voipmonitor` and check the status again.

2. Verify the running process

ps aux | grep voipmonitor

This command will show the running process and the exact command line arguments it was started with. Critically, ensure it is using the correct configuration file, for example: --config-file /etc/voipmonitor.conf. If it is not, there may be an issue with your startup script.

Step 2: Is Network Traffic Reaching the Server?

If the service is running, the next step is to verify if the VoIP packets (SIP/RTP) are actually arriving at the server's network interface. The best tool for this is `tshark` (the command-line version of Wireshark).

1. Install tshark

# For Debian/Ubuntu
apt-get update && apt-get install tshark

# For CentOS/RHEL/AlmaLinux
yum install wireshark

2. Listen for SIP traffic on the correct interface

Replace `eth0` with the interface name you have configured in `voipmonitor.conf`.

tshark -i eth0 -Y "sip || rtp" -n

• If you see a continuous stream of SIP and RTP packets, it means traffic is reaching the server, and the problem is likely in VoIPmonitor's configuration (see Step 4).
• If you see NO packets, the problem lies with your network configuration. Proceed to Step 3.

Step 3: Troubleshoot Network and Interface Configuration

If `tshark` shows no traffic, it means the packets are not being delivered to the operating system correctly.

1. Check if the interface is UP

Ensure the network interface is active.

ip link show eth0

The output should contain the word `UP`. If it doesn't, bring it up with:

ip link set dev eth0 up

2. Check for Promiscuous Mode (for Mirrored Traffic)

If you are using a dedicated sensor with a SPAN/mirror port, the network interface must be in promiscuous mode to see traffic not directly addressed to it.

• Check the current status:

ip link show eth0

Look for the `PROMISC` flag.

• Enable promiscuous mode manually:

ip link set dev eth0 promisc on

If this solves the problem, you should make the change permanent. The `install-script.sh` for the sensor usually attempts to do this, but it can fail.

3. Verify Your SPAN/Mirror/TAP Configuration

This is the most common cause of no traffic. Double-check your network switch or hardware tap configuration to ensure:

• The correct source ports (where your PBX/SBC is connected) are being monitored.
• The correct destination port (where your VoIPmonitor sensor is connected) is configured.
• If you are monitoring traffic across different VLANs, ensure your mirror port is configured to carry all necessary VLAN tags (often called "trunk" mode).

Step 4: Check the VoIPmonitor Configuration

If `tshark` sees traffic but VoIPmonitor does not, the problem is almost certainly in `voipmonitor.conf`.

1. Check the `interface` directive

Make sure the `interface` parameter in `/etc/voipmonitor.conf` exactly matches the interface where you see traffic with `tshark`. For example: `interface = eth0`.

2. Check the `sipport` directive

By default, VoIPmonitor only listens on port 5060. If your PBX uses a different port for SIP, you must add it. For example:

sipport = 5060,5080

3. Check for a restrictive `filter`

If you have a BPF `filter` configured, ensure it is not accidentally excluding the traffic you want to see. For debugging, try commenting out the `filter` line entirely and restarting the sensor.

Step 5: Check VoIPmonitor Logs for Errors

Finally, VoIPmonitor's own logs are the best source for clues. Check the system log for any error messages generated by the sensor on startup or during operation.

# For Debian/Ubuntu
tail -f /var/log/syslog | grep voipmonitor

# For CentOS/RHEL/AlmaLinux
tail -f /var/log/messages | grep voipmonitor

Look for errors like:

• "pcap_open_live(eth0) error: eth0: No such device" (Wrong interface name)
• "Permission denied" (The sensor is not running with sufficient privileges)
• Errors related to database connectivity.
• Messages about dropping packets.

AI Summary for RAG

Summary: This document provides a step-by-step troubleshooting guide for when the VoIPmonitor sensor is not capturing any calls. The process is broken down into five logical steps. Step 1 is to verify the service is running correctly using `systemctl status` and `ps`. Step 2 is to use `tshark` to confirm if SIP/RTP traffic is actually arriving at the server's network interface. Step 3 covers network-level issues, such as ensuring the interface is "UP" and in "promiscuous mode" for mirrored traffic, and verifying the physical SPAN/mirror port configuration. Step 4 focuses on checking the `voipmonitor.conf` file for common misconfigurations like the `interface`, `sipport`, or `filter` parameters. Finally, Step 5 instructs the user on how to check the system logs (`syslog` or `messages`) for specific error messages from the sensor. Keywords: troubleshooting, no calls, not sniffing, no data, no CDRs, tshark, wireshark, promiscuous mode, promisc, ifconfig, ip link, SPAN, port mirroring, voipmonitor.conf, interface, sipport, filter, syslog, logs, permission denied Key Questions:

• Why is VoIPmonitor not recording any calls?
• How can I check if VoIP traffic is reaching my sensor server?
• What command can I use to see live SIP traffic on the command line?
• How do I enable promiscuous mode on my network card?
• VoIPmonitor is running but I have no new calls in the GUI, what should I check first?
• Where can I find the log files for the VoIPmonitor sniffer?
• What are the most common reasons for VoIPmonitor not capturing data?