Resolució de problemes

Quan alguna cosa falla durant una captura, cal obtenir respostes ràpidament. Aquest capítol organitza els problemes habituals per categories, totes amb la mateixa estructura: què observeu (símptoma), per què passa (causa) i què podeu fer-hi (solució). S’inclouen ordres de diagnòstic per confirmar la causa arrel abans d’aplicar una correcció.

Si encara no heu llegit el Capítol 12: Guia d’operacions, comenceu-hi per trobar comprovacions d’estat i scripts de supervisió. Aquest capítol aprofundeix en modes de fallada específics.

Problemes de captura

Aquests problemes afecten tots els modes de captura: sniff, hunt i tap.

Permís denegat

Símptoma: lippycat es tanca immediatament amb operation not permitted o permission denied.

Causa: la captura de paquets en directe requereix les capacitats Linux CAP_NET_RAW i CAP_NET_ADMIN. Sense aquestes capacitats, el nucli denega l’accés a la interfície de xarxa.

Solució:

Executeu-lo amb sudo:

sudo lc sniff voip -i eth0

O atorgueu capacitats al binari perquè es pugui executar sense root:

sudo setcap cap_net_raw,cap_net_admin=eip /usr/local/bin/lc

Comproveu que les capacitats estan definides:

getcap /usr/local/bin/lc

Sortida esperada: /usr/local/bin/lc cap_net_admin,cap_net_raw=eip.

Després de definir les capacitats, qualsevol usuari que no sigui root pot executar captures. Cal tornar a aplicar setcap després de reinstal·lar o actualitzar el binari.

Atribució de les pèrdues de captura per etapa

Els comptadors de pèrdues són acumulatius dins d’una sessió de captura i es reinicien quan es reinicia aquella font de captura. Classifiqueu la primera etapa local amb un valor diferent de zero abans d’atribuir una causa arrel:

• les pèrdues del nucli/interfície es produeixen abans que lippycat rebi un paquet;
• les pèrdues del búfer de captura ordinari identifiquen pèrdues al canal ordinari;
• les degradacions SIP identifiquen pressió al canal prioritari quan el paquet s’ha conservat al canal ordinari i, per tant, no són pèrdues de paquets;
• les pèrdues del búfer de captura SIP identifiquen paquets SIP rebutjats per tots dos canals d’entrada;
• les pèrdues del canal de lots es produeixen en lliurar els paquets capturats al processament o al reenviament;
• els buits TCP normals/per pressió de pàgines i els de buidatge explícit compten bytes de seqüència TCP absents, però es continuen atribuint per separat;
• les pèrdues de fragments/bytes després del reassemblatge indiquen que la cua del flux SIP s’ha saturat;
• els comptadors de discontinuïtat i recuperació de l’analitzador descriuen la recuperació de l’emmarcament; i
• el mostreig de visualització o les pèrdues de la cua afecten la visibilitat dels detalls dels paquets, no l’entrada.

El comptador agregat compatible de paquets descartats és la suma de les etapes locals de pèrdua de paquets amb nom. No deduïu una fallada externa de la font de captura només perquè falti espai de seqüència TCP: comproveu primer totes les etapes mesurades localment. Els valors dels lots i dels senyals de vida són instantànies acumulatives i no s’han de sumar entre informes.

Quan aparegui pressió al búfer de captura, compareu les longituds dels canals ordinari, SIP i de sortida amb les seves capacitats. Un canal SIP ple amb degradacions però sense pèrdues SIP normalment requereix més marge de prioritat SIP. Un canal de sortida persistentment ple indica que el processament posterior no el buida prou ràpidament. Ampliar una cua finita pot absorbir una ràfega limitada, però la sobrecàrrega sostinguda requereix més cabal de processament/reenviament o un filtre de captura més restringit.

Interfície no trobada

Símptoma: lippycat informa de no such device o no es reconeix el nom de la interfície.

Causa: el nom de la interfície no coincideix amb cap dispositiu de xarxa actiu. Això passa sovint després d’un canvi de nom (p. ex., eth0 passa a ser enp3s0) o quan encara no s’ha creat una interfície virtual.

Diagnòstic:

Llisteu totes les interfícies amb el seu estat actual:

ip link show

O utilitzeu el llistat integrat de lippycat:

lc list interfaces

Solució:

Utilitzeu el nom correcte de la interfície del llistat anterior. Si no sabeu quina interfície transporta el trànsit que voleu, captureu a totes les interfícies:

sudo lc sniff voip --interface any

La pseudointerfície any captura de totes les interfícies actives simultàniament. És útil per al diagnòstic, però pot augmentar la càrrega de CPU en producció: canvieu a una interfície concreta quan hàgiu identificat la correcta.

No es capturen paquets

Símptoma: lippycat s’inicia sense errors però mostra zero paquets.

Causa: hi ha diverses possibilitats:

1. Interfície incorrecta: el trànsit passa per una interfície diferent de la seleccionada.
2. Filtre BPF massa restrictiu: l’expressió del filtre exclou el trànsit que espereu.
3. Regles del tallafoc: iptables o nftables descarta paquets abans que arribin a la capa de captura.
4. Cal mode promiscu: el trànsit no s’adreça a aquest amfitrió i la interfície no està en mode promiscu.

Diagnòstic:

Confirmeu amb tcpdump que hi ha trànsit a la interfície:

sudo tcpdump -i eth0 -c 10 -n

Si captureu VoIP, comproveu específicament el trànsit SIP:

sudo tcpdump -i eth0 -n port 5060

Comproveu les regles del tallafoc:

sudo iptables -L -n -v

Per a nftables:

sudo nft list ruleset

Solució:

• Si tcpdump veu trànsit però lippycat no, comproveu el filtre BPF. Comenceu sense filtre i afegiu restriccions gradualment.

• Activeu el mode promiscu si captureu trànsit no adreçat a aquest amfitrió:

  sudo lc sniff -i eth0 --promisc
  

• Si un tallafoc descarta paquets, afegiu una excepció per a la interfície de captura o situeu el punt de captura abans de les regles del tallafoc (p. ex., amb un dispositiu TAP o un port de rèplica).

Problemes amb fitxers PCAP

Símptoma: els fitxers PCAP no es creen, són buits o semblen corruptes.

Causa: espai de disc esgotat, permisos del directori incorrectes o el procés s’ha terminat abans de finalitzar el fitxer.

Diagnòstic:

Comproveu l’espai de disc:

df -h /var/capture/

Comproveu els permisos del directori:

ls -la /var/capture/

Verifiqueu la integritat del fitxer amb capinfos (eines de Wireshark):

capinfos capture.pcap

Solució:

• Assegureu-vos que el directori de sortida existeix i que l’usuari que executa lippycat hi pot escriure.
• Per a PCAP per trucada en mode VoIP, comproveu que el directori --per-call-pcap-dir té prou espai. Cada trucada genera un fitxer independent; un desplegament amb milers de trucades simultànies pot consumir disc ràpidament.
• Si un fitxer PCAP sembla truncat, és probable que el procés de captura s’hagi bloquejat o s’hagi terminat amb SIGKILL. Utilitzeu SIGTERM o SIGINT (Ctrl+C) per a una aturada ordenada que buidi i tanqui tots els fitxers PCAP oberts.
• Per als fitxers PCAP amb rotació automàtica, comproveu que la configuració de rotació no crea fitxers més ràpidament del que el disc pot gestionar.

Problemes de reassemblatge TCP

Els problemes de reassemblatge TCP afecten principalment la captura SIP sobre TCP. Consulteu el Capítol 4 per saber com funcionen els modes de rendiment TCP.

No es capturen missatges SIP TCP

Símptoma: zero fluxos TCP actius. No es detecten trucades SIP tot i que hi ha trànsit SIP TCP a la xarxa.

Causa: la captura pot no veure trànsit TCP al port 5060, o la configuració d’interfície/filtre l’exclou.

Diagnòstic:

Verifiqueu que el trànsit SIP TCP arriba a la interfície:

sudo tcpdump -i eth0 -n port 5060 and tcp -c 5

Executeu lippycat amb registres de depuració per seguir el processament:

LOG_LEVEL=debug sudo lc sniff voip -i eth0 --tcp-performance-mode latency 2> debug.log

Cerqueu missatges relacionats amb TCP:

grep -i "tcp\|sip\|stream" debug.log

Solució:

Si tcpdump mostra trànsit SIP TCP:

1. Assegureu-vos que el filtre BPF i la configuració de --sip-port inclouen el port SIP TCP.
2. Proveu --interface any per descartar la selecció d’interfície.
3. Comproveu que cap filtre BPF exclou TCP.

Si tcpdump no mostra trànsit:

1. SIP pot utilitzar un port no estàndard. Comproveu la configuració de la centraleta.
2. Un tallafoc pot bloquejar el port 5060. Comproveu iptables -L -n.

Es creen fluxos però no es detecta SIP

Símptoma: els fluxos TCP apareixen a les mètriques però no s’extreuen Call-IDs. Els búfers s’acumulen sense buidar-se.

Causa: els missatges SIP estan fragmentats entre segments TCP i no es reassemblen correctament, o tenen un format no estàndard.

Diagnòstic:

LOG_LEVEL=debug sudo lc sniff voip -i eth0 --tcp-performance-mode latency 2> debug.log

Després, cerqueu al registre errors de fragmentació, reassemblatge, content-length o missatges mal formats:

grep -i "fragment\|reassembl\|content-length\|malform" debug.log

Solució:

1. Augmenteu el temps d’espera del flux per donar més temps als missatges fragmentats per completar-se:

   voip:
     tcp_stream_timeout: 120s
   

2. Canvieu al mode latency per accelerar el processament de cada segment:

   sudo lc sniff voip -i eth0 --tcp-performance-mode latency
   

3. Verifiqueu el format dels missatges SIP amb una captura de paquets. Comproveu que les capçaleres Content-Length coincideixen amb la mida real del cos. Un buit en el reassemblatge o un cos truncat fa que l’analitzador del flux descarti la trama incompleta i cerqui més endavant una línia d’inici SIP creïble; un Content-Length ben emmarcat però prohibit continua sent un rebuig estricte de la política.

Comptadors de recuperació de l’analitzador SIP

Una pèrdua TCP, un buidatge forçat del reassemblatge o una cua de flux posterior al reassemblatge plena poden deixar l’analitzador a mig camí d’una capçalera o cos SIP. El flux es rearma en aquella discontinuïtat i fa una cerca limitada de la següent línia d’inici creïble d’una petició o resposta SIP. La recuperació està limitada intencionadament a 16 KiB per cerca i a 64 KiB acumulats sense un missatge SIP complet. Analitzar un missatge complet reinicia el marge acumulat; el trànsit que supera el límit es descarta en lloc de consumir CPU o memòria sense límit.

Premeu B a la TUI per inspeccionar la notificació de diagnòstic SIP TCP i el registre de depuració. Llegiu els comptadors en aquest ordre:

• reassembly_normal_* atribueix els buits alliberats durant el reassemblatge normal/per pressió de pàgines;
• reassembly_explicit_flush_* atribueix els buits exposats per un buidatge explícit;
• post_reassembly_dropped_chunks i post_reassembly_dropped_bytes identifiquen pèrdues a la cua limitada del flux;
• parser_framing_discontinuities compta els rearmaments de l’analitzador quan l’emmarcament ja no és fiable; i
• stream_recovery_successes i stream_recovery_failures indiquen si la cerca limitada ha trobat un límit SIP vàlid posterior.

Una recuperació correcta significa que s’han analitzat missatges SIP posteriors; no restaura el missatge danyat ni els bytes que hi falten. L’augment de les fallades de recuperació normalment indica que la pèrdua ha persistit més enllà del límit de cerca, que la captura ha començat a mig flux sense cap límit SIP posterior o que el flux no és SIP. Correlacioneu els comptadors de l’analitzador amb les etapes de pèrdua anteriors abans de canviar les hipòtesis de l’analitzador.

La recuperació no relaxa mai la política de seguretat de mida del cos SIP. Els valors Content-Length negatius, mal formats, desbordats, contradictoris o superiors al límit en missatges que, altrament, estan correctament emmarcats amb CRLF es rebutgen, en lloc de saltar-los per cercar un missatge posterior. Corregiu o filtreu l’emissor responsable; no interpreteu aquests rebutjos estrictes com una recuperació ordinària de pèrdues.

Ús elevat de memòria durant la captura TCP

Símptoma: l’ús de memòria creix contínuament. El sistema deixa de respondre o el mecanisme OOM termina el procés.

Causa: els fluxos TCP de llarga durada o abandonats acumulen búfers. És habitual en entorns amb moltes connexions de curta durada que no es tanquen correctament (sense FIN/RST).

Diagnòstic:

Superviseu l’ús de memòria:

watch -n 2 'ps -o pid,rss,vsz,comm -p $(pgrep lc)'

Solució:

Canvieu al mode optimitzat per a memòria i establiu límits explícits:

voip:
  tcp_performance_mode: "memory"
  memory_optimization: true
  tcp_memory_limit: 52428800    # 50 MB cap
  max_tcp_buffers: 1000
  tcp_buffer_max_age: 120s
  tcp_cleanup_interval: 30s

Per a entorns amb una càrrega molt variable, utilitzeu emmagatzematge en búfer adaptatiu:

voip:
  tcp_buffer_strategy: "adaptive"

Ús elevat de CPU durant la captura TCP

Símptoma: l’ús de CPU satura un o diversos nuclis. Comencen les pèrdues de paquets.

Causa: massa goroutines simultànies processen fluxos TCP, o la mida dels lots és massa petita i provoca una sobrecàrrega excessiva per paquet.

Solució:

Reduïu la concurrència de les goroutines i activeu la contrapressió:

voip:
  max_goroutines: 500
  enable_backpressure: true

Per a entorns de volum elevat, canvieu al mode de cabal amb lots més grans:

voip:
  tcp_performance_mode: "throughput"
  tcp_batch_size: 64

Pèrdues de paquets i trucades absents

Símptoma: augmenta la mètrica de fluxos descartats. A la sortida falten trucades conegudes.

Causa: el processament no pot seguir la taxa d’arribada. Els búfers de les cues es desborden.

Solució:

Augmenteu la capacitat de la cua i el cabal de processament:

voip:
  stream_queue_buffer: 1000
  tcp_performance_mode: "throughput"
  max_goroutines: 2000
  tcp_buffer_strategy: "ring"

Si les pèrdues persisteixen, considereu traslladar la càrrega a un desplegament distribuït amb Hunters dedicats (Capítol 7) per repartir el processament entre màquines.

Codis d’error TCP

Connectivitat distribuïda

Aquests problemes afecten la comunicació entre Hunter i processador i entre processadors. Consulteu el Capítol 6 per obtenir una visió general de l’arquitectura distribuïda.

Fallada de la negociació TLS

Símptoma: el Hunter no es pot connectar i mostra transport: authentication handshake failed o certificate verify failed.

Causa: problemes amb els certificats TLS. Els més habituals són:

1. Certificat caducat: el període de validesa del certificat ha expirat.
2. CA incorrecta: --tls-ca del Hunter no coincideix amb la CA que ha signat el certificat del processador.
3. SAN absents: el certificat del processador no conté cap Subject Alternative Name que coincideixi amb l’adreça a la qual es connecta el Hunter.
4. Discrepància de nom d’amfitrió: el Hunter es connecta per IP però el certificat només conté noms DNS (o a l’inrevés).

Diagnòstic:

Comproveu la caducitat del certificat i els SAN:

openssl x509 -in server.crt -noout -dates -ext subjectAltName

Proveu la connexió TLS manualment:

openssl s_client -connect processor.example.com:55555 -CAfile ca.crt

Comproveu si la CA coincideix:

openssl verify -CAfile ca.crt server.crt

Solució:

Si els certificats han caducat, regenereu-los. Consulteu el Capítol 13: Seguretat per veure els procediments de generació de certificats.

Si falten SAN, regenereu el certificat del servidor amb les entrades correctes. El SAN ha d’incloure tots els noms o IP que els Hunters utilitzen per connectar-se:

Exemple: fitxer d’extensions del certificat amb SAN:

cat > server-ext.conf <<EOF
subjectAltName = DNS:processor.example.com,DNS:processor,IP:10.0.1.50,IP:127.0.0.1
extendedKeyUsage = serverAuth
EOF

Si hi ha una discrepància de nom d’amfitrió, regenereu el certificat amb els SAN correctes o canvieu l’adreça --processor del Hunter perquè coincideixi amb el contingut del certificat.

Rebuig de TLS mutu (mTLS)

Símptoma: el Hunter es connecta però es desconnecta immediatament. Els registres del processador mostren client certificate required o bad certificate.

Causa: el processador està configurat per a TLS mutu (--tls-client-auth amb --tls-ca), però el Hunter no ha proporcionat cap certificat de client o el certificat de client no està signat per la CA esperada.

Solució:

Proporcioneu certificats de client al Hunter:

sudo lc hunt voip -i eth0 \
  --processor processor:55555 \
  --tls-cert hunter.crt \
  --tls-key hunter.key \
  --tls-ca ca.crt

Assegureu-vos que el certificat del Hunter està signat per la CA especificada a --tls-ca del processador.

El Hunter no pot arribar al processador

Símptoma: el Hunter informa de connection refused o context deadline exceeded.

Causa: problema de connectivitat de xarxa: el processador no escolta, un tallafoc bloqueja el port o falla la resolució DNS.

Diagnòstic:

Proveu la connectivitat bàsica:

nc -zv processor.example.com 55555

Comproveu la resolució DNS:

dig processor.example.com

Comproveu si el processador escolta:

ss -tlnp | grep 55555

Solució:

• Verifiqueu que el processador està en execució i escolta a l’adreça i port esperats.
• Comproveu les regles del tallafoc a totes dues bandes. El port gRPC per defecte és 55555.
• Si utilitzeu Docker o Kubernetes, verifiqueu les assignacions de ports i el descobriment de serveis.

El Hunter s’atura (control de flux)

Símptoma: el Hunter està connectat però deixa d’enviar paquets. Els registres mostren canvis de l’estat del control de flux a PAUSE o SLOW.

Causa: el processador està sobrecarregat. El control de flux funciona com està previst: el processador indica als Hunters que redueixin el ritme o facin una pausa quan les cues internes s’omplen. Els desencadenants habituals són escriptures PCAP lentes (coll d’ampolla d’E/S de disc) o acumulació de dades cap al processador ascendent.

Diagnòstic:

Comproveu l’estat del processador:

lc show status -P processor:55555 --tls-ca ca.crt

Comproveu l’E/S de disc al processador:

iostat -x 1 5

Comproveu la profunditat de la cua d’escriptura PCAP als registres del processador:

journalctl -u lippycat-processor --since "10 minutes ago" | grep -i "queue\|flow"

Solució:

Estats del control de flux i els seus llindars:

Per resoldre-ho:

1. Coll d’ampolla de disc: moveu la sortida PCAP a un emmagatzematge més ràpid (SSD, tmpfs per a captures temporals).
2. Coll d’ampolla de processament: escaleu horitzontalment afegint nodes processadors en una topologia jeràrquica (vegeu el Capítol 6).
3. Pic temporal: espereu; el control de flux es reprendrà automàticament quan es buidi la cua.

Nota: la lentitud dels clients TUI no provoca control de flux als Hunters. Cada subscriptor TUI té un búfer independent i els clients lents es gestionen amb descarts selectius de paquets al canal del subscriptor. Consulteu el Capítol 8 per veure l’arquitectura del control de flux.

Reconnexió després d’una partició de xarxa

Símptoma: després d’una interrupció de xarxa, els Hunters no es reconnecten o es reconnecten però perden paquets durant la interrupció.

Causa: els Hunters es reconnecten automàticament amb espera exponencial (objectiu < 100 ms per a una reconnexió ràpida). Els paquets que arriben durant la desconnexió es perden tret que s’hagi activat l’emmagatzematge en búfer al disc.

Solució:

Activeu l’emmagatzematge en búfer al disc als Hunters per superar les interrupcions de xarxa:

sudo lc hunt voip -i eth0 \
  --processor processor:55555 \
  --disk-buffer \
  --tls-ca ca.crt

Amb l’emmagatzematge en búfer al disc, el Hunter escriu en un búfer local de desbordament quan el processador és inaccessible i el buida després de la reconnexió.

Si els Hunters no es reconnecten en absolut, comproveu si s’han produït canvis persistents de DNS o encaminament durant la interrupció.

Resolució de problemes de GPU

L’acceleració GPU és opcional. El motor SIMD de CPU està sempre disponible i ofereix aproximadament 30.000 paquets/segon per a la cerca de patrons. Consulteu el Capítol 14: Optimització del rendiment per seleccionar el motor GPU.

Compatibilitat dels motors

lippycat recorre automàticament a SIMD si no hi ha cap motor GPU disponible. No necessiteu una GPU per executar lippycat.

“No CUDA-capable device is detected”

Símptoma: lippycat compilat amb CUDA informa que no hi ha cap GPU disponible, especialment en portàtils amb gràfics híbrids (Intel + NVIDIA).

Causa: en portàtils NVIDIA Optimus, la gestió d’energia en temps d’execució del nucli pot apagar la GPU dedicada. La GPU existeix però no està inicialitzada.

Diagnòstic:

Comproveu si els mòduls NVIDIA del nucli estan carregats:

lsmod | grep nvidia

Comproveu si existeixen els nodes de dispositiu:

ls -l /dev/nvidia*

Comproveu la visibilitat del dispositiu PCI:

lspci | grep -i nvidia

Comproveu l’estat de la GPU (si nvidia-smi està disponible):

nvidia-smi

Solució (ràpida, sense reinici):

Forceu l’activació de la GPU mitjançant sysfs:

echo on | sudo tee /sys/bus/pci/devices/0000:01:00.0/power/control

Inicieu el dimoni de persistència NVIDIA:

sudo nvidia-persistenced --verbose

Activeu el mode de càlcul:

sudo nvidia-smi -pm 1

Substituïu 0000:01:00.0 per l’adreça PCI de la vostra GPU obtinguda amb lspci.

Solució (permanent, requereix reinici):

Desactiveu la gestió dinàmica d’energia. Creeu /etc/modprobe.d/nvidia-power.conf:

options nvidia NVreg_DynamicPowerManagement=0x00

Després regenereu initramfs i reinicieu:

Arch Linux / Manjaro:

sudo mkinitcpio -P

Debian / Ubuntu:

sudo update-initramfs -u

sudo reboot

Es detecta la GPU NVIDIA però CUDA falla

Símptoma: nvidia-smi mostra la GPU, però el motor CUDA de lippycat continua fallant.

Causa: pot estar carregat el controlador de codi obert nouveau en lloc del controlador propietari NVIDIA, o la versió del conjunt d’eines CUDA és incompatible.

Diagnòstic:

Comproveu si nouveau està carregat (entra en conflicte amb nvidia):

lsmod | grep nouveau

Comproveu l’entorn CUDA:

echo $CUDA_VISIBLE_DEVICES

Solució:

Si nouveau està carregat, bloquegeu-lo:

echo "blacklist nouveau" | sudo tee /etc/modprobe.d/blacklist-nouveau.conf

Reconstruïu initramfs a Arch Linux o Manjaro:

sudo mkinitcpio -P

A Debian o Ubuntu, utilitzeu sudo update-initramfs -u. Després reinicieu:

sudo reboot

Definiu les variables d’entorn CUDA:

export __NV_PRIME_RENDER_OFFLOAD=1

export __GLX_VENDOR_LIBRARY_NAME=nvidia

export CUDA_VISIBLE_DEVICES=0

Afegiu-les al perfil del vostre intèrpret d’ordres perquè siguin persistents.

Motor OpenCL no disponible

Símptoma: hi ha una GPU AMD o Intel però no es detecta el motor OpenCL.

Causa: les biblioteques d’execució OpenCL no estan instal·lades.

Solució:

Instal·leu l’entorn d’execució OpenCL adequat per a la vostra GPU:

AMD (ROCr):

sudo apt install rocm-opencl-runtime

A Arch Linux:

sudo pacman -S rocm-opencl-runtime

Intel:

sudo apt install intel-opencl-icd

A Arch Linux:

sudo pacman -S intel-compute-runtime

Verifiqueu-ho amb:

clinfo | head -20

Recurs a SIMD com a alternativa

Símptoma: s’esperava un motor GPU però lippycat utilitza SIMD de CPU.

Causa: el motor GPU no s’ha pogut inicialitzar i lippycat ha recorregut silenciosament a l’alternativa. És el comportament normal: SIMD és una alternativa fiable.

Diagnòstic:

Executeu-lo amb registres de depuració per veure la selecció del motor:

LOG_LEVEL=debug sudo lc sniff voip -i eth0 --gpu-backend auto 2>&1 | grep -i "gpu\|cuda\|opencl\|simd\|backend"

Solució:

Si necessiteu acceleració GPU, corregiu el problema subjacent de la GPU seguint les seccions anteriors. Si el rendiment SIMD és suficient (30K paquets/segon en cerca de patrons), no cal fer res. Per forçar explícitament un motor i veure l’error:

sudo lc sniff voip -i eth0 --gpu-backend cuda

Això fallarà amb un error descriptiu en lloc de recórrer silenciosament a l’alternativa.

Problemes específics de VoIP

La captura VoIP implica correlacionar la senyalització SIP amb els fluxos multimèdia RTP. Aquests problemes són específics dels modes sniff voip, hunt voip i tap voip. Consulteu el Capítol 4 per conèixer els fonaments de la captura VoIP.

Falten coincidències d’identitat LI en alguns paquets RTP

Si la intercepció directa per IP/CIDR funciona però una tasca LI basada en identitat omet RTP, comproveu els comptadors de resolució multimèdia i de supressió d’herència. Un punt final exacte que pertany a diverses trucades actives és ambigu; un punt final que no pertany a cap és desconegut. Tots dos resultats suprimeixen deliberadament l’herència d’identitat i preserven les coincidències directes IP/CIDR a nivell de paquet. Captureu tot l’intercanvi SIP/SDP i els dos trams multimèdia, i comproveu la reutilització dels punts finals NAT/SBC. No ho compenseu mai triant la trucada més nova o combinant tots els possibles propietaris.

Si augmenten x3_finalized_or_stale_suppressed o x3_buffered_discarded, ha arribat contingut o ha quedat emmagatzemat al búfer després de finalitzar la generació de la trucada. Comproveu la latència dels lots ascendents i la pressió de reordenació. Les marques de trucada tancada duren una hora per defecte i estan limitades a 100.000; l’augment de les expulsions per capacitat implica que la protecció pot durar menys sota pressió. Els avisos amb freqüència limitada contenen identificadors depurats o amb hash, de manera que cal utilitzar les diferències dels comptadors, i no el nombre d’avisos, per quantificar la situació.

Fluxos RTP absents

Símptoma: es detecten trucades SIP (INVITE, 200 OK visibles) però no es capturen paquets RTP. Els fitxers PCAP per trucada només contenen senyalització.

Causa:

1. Filtre BPF massa restrictiu: el filtre captura SIP però exclou l’interval de ports RTP.
2. RTP en ports inesperats: la negociació SDP especifica ports fora de l’interval esperat.
3. Mode només UDP no activat: RTP utilitza UDP però la captura processa innecessàriament la sobrecàrrega TCP.

Diagnòstic:

Comproveu quins ports negocia SDP (mireu les línies m=):

sudo tcpdump -i eth0 -n -A port 5060 | grep "m=audio"

Comproveu si hi ha trànsit RTP en aquests ports:

sudo tcpdump -i eth0 -n udp portrange 10000-20000 -c 10

Solució:

Assegureu-vos que l’interval de ports RTP inclou els ports que utilitza la vostra centraleta:

sudo lc sniff voip -i eth0 --rtp-port-range 10000-20000

Si heu aplicat un filtre BPF personalitzat amb -f, verifiqueu que no exclou trànsit UDP a l’interval de ports RTP. En cas de dubte, elimineu el filtre BPF i deixeu que la detecció de protocols de lippycat gestioni el filtratge.

Àudio unidireccional (RTP només en una direcció)

Símptoma: el PCAP per trucada mostra paquets RTP en una sola direcció. L’altra direcció falta completament.

Causa:

1. Travessa de NAT: un punt final es troba darrere de NAT i els seus paquets RTP tenen una IP d’origen diferent de l’anunciada a SDP. lippycat correlaciona RTP per parells IP:port de SDP; si NAT reescriu l’origen, la correlació falla.
2. Encaminament asimètric: RTP circula per camins de xarxa diferents i el trànsit de retorn no passa pel punt de captura.
3. Interfície incorrecta: l’RTP sortint utilitza una interfície diferent de la que s’està capturant.

Diagnòstic:

Compareu les línies SDP c= (connexió) amb les IP d’origen reals dels paquets:

Examineu les línies de connexió SDP:

sudo tcpdump -i eth0 -n -A port 5060 | grep "c=IN"

Compareu-les amb les IP d’origen reals d’RTP:

sudo tcpdump -i eth0 -n udp portrange 10000-20000 | head -20

Si SDP indica c=IN IP4 10.0.1.100 però l’RTP real prové de 203.0.113.50, hi intervé NAT.

Solució:

• Captureu amb --interface any per cobrir totes les interfícies.
• Si el problema és NAT, captureu en un punt de la xarxa on totes dues direccions siguin visibles (p. ex., al mateix SBC o passarel·la multimèdia, o en un port de rèplica que vegi tots dos trams).
• En entorns amb NAT complex, considereu desplegar Hunters a totes dues bandes del límit NAT i agregar les dades en un processador.

No es detecta SIP sobre TCP

Símptoma: no es detecten les trucades SIP que utilitzen transport TCP, però SIP UDP funciona correctament.

Causa: SIP TCP requereix reassemblatge. Si un filtre BPF exclou TCP o només s’admeten ports SIP UDP, no es pot detectar SIP TCP. Altrament, el motor de reassemblatge TCP ha de funcionar correctament.

Solució:

1. Assegureu-vos que el filtre BPF i la configuració de --sip-port inclouen el trànsit SIP TCP.

2. Seleccioneu un mode de rendiment TCP adequat:

   sudo lc sniff voip -i eth0 --tcp-performance-mode balanced
   

3. Si el problema persisteix, consulteu la secció anterior Problemes de reassemblatge TCP.

Pèrdues de paquets amb un volum elevat de trucades

Símptoma: en entorns amb centenars de trucades simultànies, algunes trucades falten o són incompletes.

Causa: la cadena de processament de paquets no pot seguir la taxa d’arribada. Això es manifesta en desbordaments del búfer circular del nucli (es descarten paquets abans que lippycat els vegi) o saturació de les cues internes.

Diagnòstic:

Comproveu les estadístiques de pèrdues del nucli:

cat /proc/net/dev | grep eth0

Cerqueu desbordaments del búfer circular als registres del sistema:

dmesg | grep -i "drop\|overflow"

Solució:

1. Restringiu la captura als ports SIP i RTP coneguts perquè el nucli descarti el trànsit no relacionat:

   sudo lc sniff voip -i eth0 --sip-port 5060 --rtp-port-range 10000-20000
   

2. En compilacions CUDA, activeu l’acceleració GPU per a la detecció de protocols:

   sudo lc sniff voip -i eth0 --gpu-backend auto
   

3. Per a un volum elevat sostingut, canvieu a una arquitectura distribuïda amb Hunters dedicats:

   # Hunter handles capture and filtering
   sudo lc hunt voip -i eth0 --processor central:55555 --sip-port 5060 --tls-ca ca.crt
   
   # Processor handles analysis and PCAP writing
   lc process --listen :55555 --per-call-pcap --per-call-pcap-dir /var/capture/calls \
     --tls-cert server.crt --tls-key server.key
   

4. Augmenteu la mida del búfer circular del nucli per a la interfície de captura:

   sudo ethtool -G eth0 rx 4096
   

Problemes de configuració

La configuració no té efecte

Símptoma: els canvis al fitxer de configuració no modifiquen el comportament de lippycat. Es continuen utilitzant els valors per defecte.

Causa: lippycat carrega la configuració en iniciar-se des d’un conjunt específic de camins. Si el fitxer és a la ubicació incorrecta, té errors de sintaxi YAML o s’ha modificat després de l’inici, els canvis no s’aplicaran.

Diagnòstic:

Comproveu quin fitxer de configuració s’està carregant:

lc show config

Valideu la sintaxi YAML:

python3 -c "import yaml; yaml.safe_load(open('config.yaml'))"

Solució:

1. Col·loqueu el fitxer de configuració en una de les ubicacions esperades (en ordre de prioritat):

   • $HOME/.config/lippycat/config.yaml
   • $HOME/.config/lippycat.yaml
   • $HOME/.lippycat.yaml

2. O especifiqueu-lo explícitament:

   sudo lc sniff voip --config /etc/lippycat/config.yaml
   

3. Reinicieu lippycat després de qualsevol canvi de configuració. La configuració es llegeix una sola vegada en iniciar.

Eines de diagnòstic

Registre de depuració

Activeu els registres detallats per a qualsevol ordre de lippycat:

LOG_LEVEL=debug sudo lc sniff voip -i eth0 2> debug.log

Filtreu la sortida dels registres per subsistemes concrets:

Problemes de reassemblatge TCP:

grep -i "tcp\|stream\|reassembl" debug.log

Anàlisi de SIP:

grep -i "sip\|invite\|call.id" debug.log

gRPC / connectivitat distribuïda:

grep -i "grpc\|connect\|tls\|handshake" debug.log

Selecció del motor GPU:

grep -i "gpu\|cuda\|opencl\|simd" debug.log

Supervisió dels recursos del sistema

Superviseu l’ús de recursos de lippycat:

watch -n 2 'ps -o pid,rss,vsz,%cpu,%mem,comm -p $(pgrep lc)'

Superviseu les estadístiques de la interfície de xarxa (pèrdues, errors):

watch -n 1 'ip -s link show eth0'

Superviseu l’E/S de disc (rellevant per a l’escriptura PCAP):

iostat -x 1

Superviseu els descriptors de fitxer oberts:

ls /proc/$(pgrep -f "lc ")/fd | wc -l

Diagnòstic de desplegaments distribuïts

Visió general de l’estat del processador:

lc show status -P processor:55555 --tls-ca ca.crt

Llisteu els Hunters connectats:

lc list hunters -P processor:55555 --tls-ca ca.crt

Mostreu la topologia de xarxa:

lc show topology -P processor:55555 --tls-ca ca.crt

Comproveu els filtres actius:

lc show filter -P processor:55555 --tls-ca ca.crt

Script de comprovació de l’estat

Un script bàsic de comprovació de l’estat per a la supervisió automatitzada:

#!/bin/bash
# lippycat-health-check.sh

PROC_NAME="lc"

# Check if lippycat is running
if ! pgrep -f "$PROC_NAME" > /dev/null; then
    echo "CRITICAL: lippycat not running"
    exit 2
fi

PID=$(pgrep -f "$PROC_NAME" | head -1)

# Check memory usage (threshold: 500 MB)
MEM_KB=$(ps -o rss= -p "$PID" | tr -d ' ')
MEM_MB=$((MEM_KB / 1024))

if [ "$MEM_MB" -gt 500 ]; then
    echo "WARNING: High memory usage: ${MEM_MB} MB"
    exit 1
fi

# Check CPU usage (threshold: 80%)
CPU=$(ps -o pcpu= -p "$PID" | tr -d ' ' | cut -d. -f1)

if [ "$CPU" -gt 80 ]; then
    echo "WARNING: High CPU usage: ${CPU}%"
    exit 1
fi

echo "OK: lippycat healthy (Memory: ${MEM_MB} MB, CPU: ${CPU}%)"
exit 0

Referència ràpida