Si vous avez déjà branché Wireshark sur un segment du bus de processus d'un véritable poste numérique, la scène vous est familière : peu après le démarrage de la capture, Wireshark se fige — c'est un problème bien connu. Il se manifeste particulièrement dans les postes véhiculant du trafic Sampled Values.
La raison est prosaïque : un seul flux Sampled Values à 4000 trames par seconde (80 échantillons par cycle, 50 Hz) génère déjà une charge considérable. Dans un segment réel du bus de processus, on en compte des dizaines — auxquels s'ajoutent GOOSE, PTP, le trafic broadcast et de service. Wireshark ne « n'arrive pas » à analyser : il n'arrive simplement pas à enregistrer et afficher tous ces paquets en temps réel.
Le wiki de Wireshark donne une recommandation directe à ce sujet :
Si vous ne vous intéressez pas à tous les paquets, un filtre de capture qui ne sélectionne que les paquets qui vous intéressent peut réduire le temps de traitement total, car les paquets peuvent être éliminés par le filtre de capture avant même d'être écrits dans le fichier de capture — et, sur les systèmes dotés d'un filtrage de capture au niveau du noyau, ils sont éliminés avant même d'être copiés du noyau vers Wireshark.
Idée clé : le filtre de capture rejette les paquets avant qu'ils n'atteignent Wireshark. Contrairement au filtre d'affichage, qui travaille sur du trafic déjà enregistré. Donc si vous savez à l'avance ce que vous cherchez, le filtre de capture est votre meilleur allié.
Filtre de capture vs Filtre d'affichage : ne les confondez pas !
Wireshark propose deux types de filtres souvent confondus. La différence est essentielle :
| Paramètre | Capture Filter | Display Filter |
|---|---|---|
| Quand est-il appliqué | Avant l'écriture du paquet | Après l'écriture du paquet |
| Modifiable à la volée | Non (capture à arrêter) | Oui, en temps réel |
| Syntaxe | BPF (comme dans tcpdump) |
Syntaxe propre à Wireshark |
| Impact sur les performances | Réduit charge disque et mémoire | Aucun sur la capture |
| Effet sur les données | Élimine définitivement | Cache simplement, ne supprime pas |
Le filtre de capture décide ce qui entre dans votre « collection » de données ; le filtre d'affichage décide ce que vous examinerez dans la collection déjà constituée.
Pour les tâches du type « voyons un peu ce qu'il y a sur le réseau » sur un segment chargé, il est quasiment impossible de se passer d'un filtre de capture.
Comment appliquer un filtre de capture dans Wireshark
Trois méthodes standard :
Méthode 1. Écran d'accueil.
Sur l'écran d'accueil, avant de choisir l'interface, saisissez l'expression du filtre de capture.
Méthode 2. Menu Capture.
Capture → Options → champ Capture Filter for selected interfaces en regard de l'interface choisie.
Il existe d'autres méthodes, mais ces deux-là suffisent pour commencer :)
En cas d'erreur de syntaxe, Wireshark colore le champ en rouge et empêche le démarrage de la capture. Le vert indique que le filtre est syntaxiquement valide — mais cela ne garantit pas qu'il fasse ce que vous aviez en tête. Il faut quand même vérifier.
Quelques particularités de BPF à garder en tête
Les expressions de filtre de capture s'écrivent en BPF — le même langage que tcpdump. La syntaxe est compacte, mais avec le trafic de poste électrique il y a quelques subtilités peu évidentes.
VLAN casse les offsets
Le mot-clé vlan dans un filtre BPF n'est pas un simple prédicat « il y a un tag VLAN ». C'est une directive qui décale tous les offsets suivants du filtre comme si le tag VLAN n'était pas là. Autrement dit, ether proto 0x88b8 avant la directive vlan capture les trames non taguées, et après — les trames taguées.
Cas classique : vous voulez attraper tout le trafic GOOSE, dont une partie est taguée VLAN et l'autre non. L'approche intuitive
(vlan and ether proto 0x88b8) or ether proto 0x88b8
ne fonctionne pas comme prévu. Le trafic non tagué ne passe pas, parce qu'après vlan les offsets sont déjà décalés et la deuxième branche cherche l'EtherType au mauvais endroit.
Le bon ordre : cas non tagué d'abord, tagué ensuite :
ether proto 0x88b8 or (vlan and ether proto 0x88b8)
Règle générale : toutes les expressions sans VLAN doivent figurer avant la première occurrence de vlan dans le filtre.
Adresse MAC partielle
ether host xx:xx:xx:xx:xx:xx exige le MAC complet. Mais si vous devez par exemple capturer le trafic de tous les appareils d'un fabricant ayant l'OUI 00:0C:22, il faut écrire un filtre par offset d'octet :
(ether[0:4] & 0xffffff00 = 0x000c2200) or (ether[6:4] & 0xffffff00 = 0x000c2200)
Ici ether[0:4] désigne quatre octets à partir de l'offset 0 (champ MAC de destination), et ether[6:4] quatre octets à partir de l'offset 6 (champ MAC source). L'opérateur : de BPF n'accepte que des tailles 1, 2 ou 4 — trois octets ne peuvent pas être sélectionnés — d'où la prise de quatre et la mise à zéro du quatrième superflu via le masque 0xffffff00.
Variante : comparer octet par octet — plus long mais plus lisible :
(ether[0]=0x00 and ether[1]=0x0c and ether[2]=0x22) or (ether[6]=0x00 and ether[7]=0x0c and ether[8]=0x22)
Cheatsheet : filtres de capture pour IEC 61850
Voici l'essentiel. Ci-dessous — des recettes prêtes à l'emploi pour les tâches typiques en poste numérique.
GOOSE
Tout le GOOSE (sans VLAN) :
ether proto 0x88b8
Tout le GOOSE y compris les trames VLAN :
ether proto 0x88b8 or (vlan and ether proto 0x88b8)
GOOSE depuis un IED particulier (filtre par MAC source) :
ether proto 0x88b8 and ether src 00:0c:22:12:34:56
GOOSE vers une adresse multicast précise :
ether proto 0x88b8 and ether dst 01:0c:cd:01:00:01
GOOSE depuis tous les appareils d'un fabricant (par OUI, ex. 00:0C:22) :
ether proto 0x88b8 and (ether[6:4] & 0xffffff00 = 0x000c2200)
GOOSE avec un APPID précis (ex. 0x1000).
APPID, ce sont les deux octets juste après l'EtherType, à l'offset 14–15 dans une trame non taguée :
ether proto 0x88b8 and ether[14:2] = 0x1000
Avec VLAN :
(ether proto 0x88b8 and ether[14:2] = 0x1000) or (vlan and ether proto 0x88b8 and ether[14:2] = 0x1000)
Plage d'APPID GOOSE (ex. de 0x1000 à 0x10FF) :
ether proto 0x88b8 and ether[14:2] & 0xff00 = 0x1000
Plage de destinations multicast GOOSE :
ether proto 0x88b8 and (ether[0:4] & 0xffffff00 = 0x010ccd00) and (ether[4:2] & 0xff00 = 0x0100)
Sampled Values
Tous les SV (sans VLAN) :
ether proto 0x88ba
Tous les SV y compris VLAN :
ether proto 0x88ba or (vlan and ether proto 0x88ba)
SV depuis une MU particulière (par MAC source) :
ether proto 0x88ba and ether src 00:0c:22:aa:bb:cc
SV vers une adresse multicast précise :
ether proto 0x88ba and ether dst 01:0c:cd:04:00:01
SV avec un APPID précis (ex. 0x4000) :
ether proto 0x88ba and ether[14:2] = 0x4000
SV depuis toutes les MU d'un fabricant (par OUI) :
ether proto 0x88ba and (ether[6:4] & 0xffffff00 = 0x000c2200)
SV de la plage 01:0C:CD:04:xx:xx :
ether proto 0x88ba and (ether[0:4] & 0xffffff00 = 0x010ccd00) and (ether[4:2] & 0xff00 = 0x0400)
À propos du filtrage par goID et svID
Mauvaise nouvelle ici : on ne peut pas filtrer de manière fiable GOOSE par goID ni SV par svID à l'aide d'un filtre de capture. Ces champs vivent à l'intérieur d'un APDU encodé BER, et leur offset depuis le début de la trame dépend de la longueur des champs précédents (gocbRef / en-tête svID, etc.). Or BPF ne travaille qu'avec des offsets fixes.
Ce qu'on peut faire en pratique :
- Utiliser l'APPID comme proxy. Avec un publisher correctement configuré, l'APPID est unique et correspond à un seul
gocbRef/svCB. Filtrer par APPID est le moyen le plus fiable de capturer un flux précis au niveau capture. - Utiliser le MAC multicast de destination. On recommande aussi de le garder unique par flux dans un système bien conçu et mis en service.
- Capturer d'abord tout le trafic d'un type, puis filtrer en filtre d'affichage. Si le flux n'est pas trop volumineux, ça marche. Pour les SV sur un bus de processus chargé — pas terrible.
- Écrire un filtre par offset d'octet pour le cas particulier. Capturez quelques trames du flux cible sans filtre, regardez à quel offset se trouve la chaîne qui vous intéresse, écrivez un filtre du type
ether[N:4] = 0xXXXXXXXX. La méthode marche mais reste extrêmement fragile — tout changement dans les champs APDU précédents décale l'offset et le filtre cesse de capturer.
Dans 90 % des cas, la combinaison « EtherType + APPID » ou « EtherType + MAC dst » règle l'affaire.
Filtres d'exclusion — quand il est plus simple de couper le bruit
Autre astuce utile : capturer tout sauf un ou deux flux particulièrement bruyants. Par exemple, prendre tout le bus de processus sans deux flux SV précis pour que Wireshark ne s'étouffe pas :
not (ether proto 0x88ba and ether dst 01:0c:cd:04:00:01) and not (ether proto 0x88ba and ether dst 01:0c:cd:04:00:02)
Ou, à l'inverse, capturer GOOSE et PTP mais pas SV :
ether proto 0x88b8 or ether proto 0x88f7
Pour les cas du type « tout sauf les communications MMS avec un serveur précis » :
not (tcp port 102 and host 192.168.1.10)
Quelques conseils pratiques pour finir
- Commencez toujours par un filtre de capture quand vous travaillez sur le bus de processus. « Voyons ce qu'il y a là, on verra après » se solde par un Wireshark figé.
- Gardez la cheatsheet sous la main. BPF n'est pas un langage qui s'imprime du premier coup. Un tableau d'expressions prêtes vous épargne des dizaines de minutes par session de débogage.
- Pour diagnostiquer les vrais problèmes GOOSE/SV, le combo « filtre de capture par EtherType + filtre d'affichage » fonctionne le mieux. Un filtre de capture grossier coupe 95 % du bruit ; un filtre d'affichage précis permet de basculer rapidement entre flux dans la trace déjà collectée.
BPF n'est pas le langage le plus accueillant, mais maîtriser une dizaine de constructions tirées de cet article suffit à couvrir pratiquement toutes les tâches de capture de trafic IEC 61850 — et accessoirement, à arrêter de regarder Wireshark se débattre et mourir sur le bus de processus.