Sur cette page

La bande passante est toujours a zero

Un Sentinel Agent dont toutes les valeurs de bande passante sont a 0, dont les seuils de trafic ne se declenchent jamais et dont les protocoles sont tous Unidentified n’observe presque jamais un hote inactif : il lui manque son runtime de capture de paquets.

Inactif, ou non mesure ?

Une bande passante a 0 a la meme apparence dans les deux cas. L’agent remonte donc un statut de capture a chaque collecte, et l’interface web l’affiche. Verifiez ces indices avant de conclure a un reseau calme :

Ou Ce que vous voyez
Barre d’outils du graphe de decouverte Un badge ambre No packet capture. Survolez-le : l’infobulle reprend la raison remontee par l’agent lui-meme.
Barre d’outils du graphe de decouverte Un badge bleu Bandwidth from TCP statistics : la bande passante est mesuree, sur un hote Windows sans Npcap. Voir le badge bleu.
Menu deroulant du filtre Proto Une ligne en tete precisant que les protocoles sont deduits du seul port et du nom de processus.
Infobulle d’un lien de la carte « not measured — no packet capture » a la place d’une valeur de bande passante, et aucune mini-courbe.
Rapport processus Une icone d’avertissement sur les pastilles de seuil Traffic In et Traffic Out et sur leurs deux panneaux de graphique.

Si aucun de ces indices n’apparait et que les valeurs sont malgre tout a 0, la capture fonctionne et les liens sont reellement inactifs : un 0.000 kbits/s authentique est une mesure et s’affiche comme telle.

Sur une carte fusionnee (niveau 2), le badge indique « No packet capture on at least one agent ». La carte fusionne plusieurs agents et ne garantit un trafic fiable que si tous les agents contributeurs ont pu capturer : un seul hote sans pilote marque donc toute la vue. Ouvrez la carte propre a chaque hote pour identifier lequel.

Badge bleu (Bandwidth from TCP statistics)

Un hote Windows sans Npcap mesure la bande passante a partir des statistiques TCP que Windows tient pour chaque connexion. Les valeurs sont reelles et les seuils de trafic fonctionnent. Le badge est la parce que ce mode a des restrictions :

Badge bleu Bandwidth from TCP statistics dans la barre du graphe de decouverte
  • les protocoles sont deduits du seul port et du nom de processus, sans detection a partir du contenu ;
  • une connexion plus courte qu’un cycle de collecte n’est pas mesuree ;
  • les valeurs sont inferieures de quelques pour cent a celles de la capture de paquets, car seuls les octets utiles sont comptes ;
  • le service de l’agent doit s’executer en LocalSystem ou sous un compte Administrateur.

Npcap est utilise des qu’il est installe. Pour retirer le badge et les trois premieres restrictions, installez le runtime Npcap et redemarrez le service de l’agent. Details : Windows sans Npcap.

Ce qui fonctionne malgre tout

Seule la bande passante est perdue. L’agent reste actif, le service continue de tourner, et rien d’autre ne se degrade :

  • Conserve — l’inventaire complet des connexions : IP et port local et distant, PID, nom du processus, sens, interface. La carte de topologie est complete.
  • Conserve — les metriques CPU, memoire, disque, systeme de fichiers, processus, ainsi que netBytesRate / netTxDrops par interface, qui proviennent des compteurs de l’OS et non des paquets.
  • Conserve — les libelles de protocole, mais deduits du seul numero de port et du nom de processus. C’est pourquoi la categorie Unidentified grossit : les ports ephemeres ne portent aucun indice de port bien connu et il n’y a aucun contenu a inspecter.
  • Perdu — toutes les valeurs en kbits/s. Le trafic entrant / sortant par processus reste a 0, l’usage des liens de la carte reste a 0, et les seuils de trafic ne peuvent jamais se declencher.

Lire la raison

L’infobulle du badge porte la raison remontee par l’agent. Chacune appelle un correctif different.

« couldn’t load wpcap.dll » / echec de l’enumeration des peripheriques

Aucun runtime pcap n’est installe.

  • Windows — depuis la 4.2.0, cette raison seule ne met plus la bande passante a zero : l’agent se replie sur les statistiques TCP et le badge est bleu. Quand le badge est ambre et que la raison se termine par TCP statistics need Administrator/LocalSystem, executez le service de l’agent en LocalSystem ou sous un compte administrateur, ou installez le runtime Npcap (le SDK n’est pas necessaire).
  • Linux — depuis la 4.2.0, libpcap est integre a l’agent : cette raison ne devrait pas apparaitre. Si elle apparait, l’hote execute un agent plus ancien : mettez-le a jour.

L’agent ne demarre pas : “libpcap.so.0.8: cannot open shared object file”

Seuls les agents anterieurs a la 4.2.0 affichent cette erreur : ils chargent libpcap dynamiquement, et l’hote n’a pas de bibliotheque sous le nom qu’ils recherchent.

  • Debian / Ubuntu : apt install libpcap0.8
  • RHEL / CentOS / Fedora : dnf install libpcap, puis creez le nom recherche par l’ancien binaire :
ln -s /usr/lib64/libpcap.so.1 /usr/lib64/libpcap.so.0.8

Mettre l’agent a jour en 4.2.0 ou plus supprime ces deux besoins ; le paquet et le lien peuvent rester, ils ne sont plus utilises.

Echec de OpenLive / permission refusee

Le runtime est present mais l’agent n’a pas le droit de l’ouvrir.

  • Linux — accordez la capacite au binaire de l’agent lui-meme, puis redemarrez le service :

setcap cap_net_raw+ep /opt/mugnsoft/discovery_agent
  • Windows — les installeurs Npcap recents activent par defaut Restrict driver access to Administrators only. Executez le service en LocalSystem / sous un compte administrateur, ou reinstallez Npcap avec cette option decochee.
La capacite se pose sur le binaire de l’agent, et non sur un processus auxiliaire : la capture de paquets s’execute au sein de l’agent. Le remplacement du binaire lors d’une mise a jour efface la capacite : reappliquez setcap apres chaque montee de version.

Aucune interface de capture exploitable

Le runtime est charge et les permissions sont correctes, mais toutes les interfaces ont ete ecartees — typiquement un conteneur ou un hote dont les seules interfaces sont des peripheriques docker/veth, qui sont ignores.

Si le trafic recherche est de l’IPC local a l’hote, activez plutot la capture du bouclage :


{
  "discoCaptureLoopbackEnabled": "true"
}

Attendez-vous a une hausse des valeurs de bande passante une fois active, puisque le trafic local commence a etre comptabilise. Ce drapeau ne fonctionne aujourd’hui que sous Linux.

Verifier depuis les journaux

L’agent journalise l’etat de la capture uniquement lors d’un changement — un avertissement quand la capture devient indisponible, une ligne d’information quand elle revient — de sorte qu’un hote durablement sans pilote journalise une fois au lieu de le faire a chaque cycle. Recherchez capture dans le journal de l’agent :


grep -i "capture" /opt/mugnsoft/discovery_agent/log/*.log

Comme la journalisation n’a lieu qu’au changement, l’absence de lignes recentes ne prouve pas que la capture fonctionne. Le badge de l’interface web reflete la derniere collecte : c’est la verification fiable.

Tous les protocoles sont « Unidentified »

C’est la consequence attendue de ce qui precede, et non une panne distincte. Sans contenu capture, une connexion n’est etiquetee que si son port est bien connu. Les connexions cote client sur des ports ephemeres — navigateurs, IPC, la majorite du trafic sortant — n’ont aucun indice de ce type et se retrouvent dans Unidentified.

Deux parametres influent :

  • discoProtocolDetectionEnabled (defaut "true") — inspection approfondie du contenu des paquets. Si vous le passez deliberement a "false", attendez-vous a la meme croissance d’Unidentified, meme sur un hote qui capture normalement.
  • discoCaptureLoopbackEnabled (defaut "false") — l’IPC local a l’hote reste invisible tant qu’il n’est pas active.

Les deux sont relus au debut de chaque cycle de collecte : une modification s’applique au cycle suivant, sans redemarrer l’agent.

Voir aussi

Traductions

Le composant ne demarre pas