Développement d`un module de décodage logiciel WIRESHARK

Transcription

Développement d’un module de
décodage logiciel WIRESHARK
pour le trafic radar au format
ASTERIX
FAVIER Florian
BIKOUO Aubin
IENAC 07 L
ENCADRANTS : N.LARRIEU
J-M FONTAINE
1
I. INTRODUCTION ..............................................................................................................................................3
II. CONTEXTE ......................................................................................................................................................4
II.1ASTERIX ......................................................................................................................................................4
1) Les catégories.............................................................................................................................................4
2) Le message .................................................................................................................................................4
a) Champ fixe ..............................................................................................................................................................4
b) Champ étendu .........................................................................................................................................................5
c) Champ répétitif ........................................................................................................................................................5
d) Message...................................................................................................................................................................5
e) Bloc .........................................................................................................................................................................6
f) Enregistrement .........................................................................................................................................................6
g) Exemple ..................................................................................................................................................................7
Exemple de décodage associé à la catégorie 1 sur de l’éthernet ...................................................................7
II.2WIRESHARK ............................................................................................................................................ 11
III. CAHIER DES CHARGES ............................................................................................................................ 12
LE BESOIN.......................................................................................................................................................... 12
LES CHOIX .......................................................................................................................................................... 13
ASTERIX ....................................................................................................................................................... 15
WIRESHARK ................................................................................................................................................ 15
Environnement de travail. ............................................................................................................................ 15
IV. DEVELOPPEMENT .................................................................................................................................... 14
LE PLUGIN WIRESHARK TYPE ......................................................................................................................... 14
LE PLUGIN ASTERIX ......................................................................................................................................... 15
a) Fonctions .................................................................................................................................................. 15
b) Description des catégories décodées........................................................................................................ 16
c) Mise en place de filtres ............................................................................................................................. 20
d) Detection du protocole ASTERIX ............................................................................................................. 20
V. TESTS .............................................................................................................................................................. 22
VI. CONCLUSION .............................................................................................................................................. 27
VII. TABLE DE REFERENCE ......................................................................................................................... 29
VIII. GLOSSAIRE ............................................................................................................................................... 30
IX. ANNEXE ........................................................................................................................................................ 31
2
I. INTRODUCTION
Un service technique de la DGAC (aéroport de Toulouse) a demandé le
développement d'un module WIRESHARK permettant la lecture et le décodage des messages
au format ASTERIX.
Le protocole ASTERIX assure l’échange des données des capteurs de surveillance
(radars primaires, secondaires, …) sur les réseaux de l’aviation civile. Il a été normalisé au
niveau européen par EUROCONTROL.
Quant au logiciel WIRESHARK, il s’agit d’un analyseur de trafic réseau. Ce dernier
étant un logiciel libre et supportant de très nombreux protocoles, on peut lui en ajouter de
nouveaux.
A l'heure actuelle, les services de la DGAC ne disposent d'aucun outil pour réaliser la
tâche de décodage des messages ASTERIX. Ainsi dès lors que les messages étaient capturés,
si ceux-ci devaient être traités, cela aurait été fait de la manière suivante: analyse de la trame
pour la reconnaissance du protocole ASTERIX et le décodage des informations émises dans le
message capturé. Cette tâche s'avère néanmoins fastidieuse, d'où le besoin d'automatiser le
processus.
Il existe néanmoins un logiciel propriétaire développé par la société COMSOFT qui
permet de détecter le protocole ASTERIX sans pour autant analyser les informations
contenues dans la trame reçue. Ainsi afin de réaliser ces deux tâches WIRESHARK nous a été
imposé.
Dans ce document, nous commencerons par nous familiariser avec la norme
ASTERIX et le logiciel WIRESHARK. Nous poursuivrons par l’analyse du cahier des
charges et les solutions apportées pour y répondre. Enfin nous aborderons les perspectives
d’évolution de notre travail.
3
FAVIER Florian / BIKOUO Aubin
Télécommunications aéronautiques ENAC
II. CONTEXTE
Nous présenterons dans cette section les messages ASTERIX et le logiciel
WIRESHARK. Le paragraphe sur ASTERIX a été inspiré de la documentation « Les
protocoles utilisés dans IRMA », fournie au début du projet.
II.1 ASTERIX
Le format ASTERIX (All Purpose STructured EUROCONTROL SuRveillance
Information EXchange ), est un format utilisé au sein de la DGAC pour la transmission des
données des capteurs de surveillance.
Ce format est aussi bien utilisé pour le CAUTRA (STR) que pour les radars primaires et
secondaires.
ASTERIX est une norme EUROCONTROL. On va donc pouvoir en théorie émettre et
recevoir vers des pays étrangers.
La description exhaustive des messages ASTERIX est consultable à l’adresse suivante :
http://www.EUROCONTROL.int/ASTERIX/public/subsite_homepage/homepage.html.
II.1.1 Les catégories
La catégorie définie le type de données qui vont suivre dans les enregistrements.
Les catégories vont de 0 à 255.
Catégorie 0 à 127
: Applications "standard" civile et militaire
-> Utilisé pour l'Air Traffic Control (ATC) et la météo
Catégorie 128 à 240 : Applications spéciales pour le domaine militaire
Catégorie 241 à 255 : Application non standard civile et militaire
recherche, test, expérimentation …
II.1.2 Le message
Les champs de chaque catégorie ASTERIX sont définis par une norme EUROCONTROL.
Ces champs sont de tailles fixes ou variables. Nous proposons à travers les graphiques suivant
de mieux comprendre la structure du message.
a) Champ fixe
n octets
4
Les champs fixes sont des multiples d’octets.
b) Champ étendu
k octets
1
i octets
1
j octets
0
La valeur du bit de poids faible de l’octet permet d’étendre ou non le champ. S’il vaut 1 le
champ est étendu à l’octet suivant, s’il vaut 0, le champ s’arrête.
c) Champ répétitif
Rep = N
j octets
Octets de répétition
j octets
N fois
Certains champs se répètent plusieurs fois, la valeur d’un octet nous informe alors sur le
nombre de fois où les champs apparaissent dans la trame.
d) Message
Bloc 1
Bloc n
Un message peut contenir plusieurs blocs de données, chaque bloc contenant une catégorie
ASTERIX différente.
5
e) Bloc
BLOC i
CAT
LONG
ENG 1
ENG i
Le champ cat (catégorie) indique sur un octet à quelle catégorie ASTERIX appartiennent les
données du bloc. Il y aura par exemple une catégorie pour le STR, une pour les radars
aviation, une pour les radars météo, …
Le champ long (longueur) indique sur 2 octets la longueur (en nombre d'octets) du bloc.
f) Enregistrement
ENG i
FSPEC
Données1
Données n
Un enregistrement commence par un champ appelé FSPEC (un ou plusieurs octets) signifiant
Field SPECification.
Chaque bit de FSPEC indique la présence ou l'absence de la donnée du rang i pour la
catégorie en cours.
6
g) Exemple
Bloc n°1
CAT
LONG
FSPEC
(1,5,8)
Data1
Data5
Bloc n°2
Data8
Enregistrement n°1
FSPEC
(7,12)
Data7
Data12
CAT
LONG
FSPEC
Data
Enregistrement n°2
Message ASTERIX
Le message ASTERIX peut être composé de plusieurs blocs. Chaque bloc correspond à une
catégorie. La longueur est relative à la taille d’un bloc. Enfin dans chaque bloc nous pouvons
trouver plusieurs enregistrements. Les données des enregistrements sont détaillées dans les
champs FSPEC. Ainsi chaque bit à un du champ FSPEC annonce une donnée particulière
définie par la norme.
FSPEC, Field Special, est un champ étendu, c'est-à-dire que sa taille est variable.
Exemple de décodage associé à la catégorie 1 sur de l’éthernet
La catégorie 1 collecte les informations issues des radars primaires et secondaires
FSPEC
Un octet extensible.
Octet 1:
8
IDEN
7
ESC
6
UM
5
OSU
4
OSX
3
VIT
2
MODA
8
MCD
7
PTU
6
LOT
5
UIS
4
OPP
3
IST
2
UAL
1
EXT
Octet 2:
1
EXT
7
Octet 3:
8
OD2
7
QA
6
QC
5
Q2
4
WEC
3
SP
2
FS
1
EXT
7
0
6
0
5
0
4
0
3
0
2
0
1
EXT
Octet 4 (jamais transmis):
8
0
Par nature même, le champ FSPEC est présent pour chaque plot pisté.
Par principe:
- chaque bit de chaque octet de FSPEC indique, lorsqu'il est positionné à 1, la présence du
champ correspondant dans le plot pisté courant. Certains bits sont fixés à la valeur 0; ils
correspondent à des champs prévus mais qui sont inutilisés dans le cadre de la présente
application radar secondaire mono-impulsion (champs réservés au radar primaire ou
optionnels).
On trouve, dans l'octet No 3, un bit SP et un bit RFS indicateurs de présence respectivement
d'un champ de données non standard et de champs organisés en séquence aléatoire (RFS =
Random field Séquence). Ces bits ne seront jamais positionnés dans le cadre de notre
application, mais leur utilisation est prévue par ASTERIX.
- un octet de FSPEC dont tous les bits sont à 0 (absence des champs correspondants), y
compris le bit d'extension, n'est pas transmis. C'est le cas de l'octet No 4 qui est prévu par
EUROCONTROL mais qui ne sera jamais transmis ici.
8
Voici une capture de trame ethernet enregistrée à l'ENAC
FD FF FF FF 08 02 00 80 02 00 00 15 00 92 34 34 03 01 00 83 F7
84 08 05 A8 01 A8 70
21 BD 88 09 09 26 68 00 89 85 50 68 77
84 A8 00 21 68 BC B9 D4 08 1B A7 28 4D A0 45
C8 48 77 84 A8 01 7D 57 A9 B8 70 08 0E FE 0E 0A E8 05 78 48 77 84 A8 00 88 48 3E
BF 34 08 1F 2A B8 02 06 04 D8 48 77 84 A8 00 8B 4 E B7 BC CC 07 05 82 08 06 E 6 02
0C 48
77 84 A8 01 4F 4A FA BE 00 08 37 7B 00 04 C8 05 C8 48 77 84 A8 00 31 18 3A BC 50
01 E1 07 D0 0D 40 00 70 68 02 00 0C F4 08 05 02 C0 3D 81 AF 20 …
La première chose à faire est d'examiner le FSPEC.
Examen du FSPEC pour connaître les champs de données qui seront présents ou absent dans
les données utiles.
FSPEC = F7 84
F7
1111
84
0111
1000
0100
ext
IDEN
QUAL
DESC
PIST
DOPP
NUM
POSU
PUIS
POSX
PLOT
VIT
HPTU
MODA
MCD
Le Champ IDEN se décompose en deux sous champs très importants :
• Le SAC, Source Area Code qui définit l’origine géographique de l’émetteur,
• Le SIC, Source Identification Code (numéro du radar)
•
Ces deux champs particuliers seront utilisés dans la suite de notre exposé.Nous allons
maintenant détailler chaque champ de données utiles.
9
FD FF FF FF 08 02
00 80 02 00 00 15
00 92
34
34
@ MAC dest
@ MAC source
Long
Ethernet
SSAP
DSAP
03
01
00 83
F7 84
08 05
A8
cmde
CAT
longueur
FSPEC
SAC SIC
DESC
01 A8
70 21 BD 88
09 09 26 68
00 89
85 50
N° piste
POSU
VITESSE
Mode A
Mode C
68
77 84
Piste
FSPEC suivant
A8 00 21 68 BC B9 D4 08 1B A7 28 4D A0 45 C8 48 77 84 A8 01 7D 57 A9 B8 70 08 0E
FE 0E 0A E8 05 78 48 77 84 A8 00 88 48 …..
Champ
Données
SAC SIC 08 05
DESC A8
N° piste
POSU
Vitesse
01 A8
70 21 BD 88
09 09 26 68
Mode A
00 89
Mode C
Piste
85 50
68
commentaires
Monopulse Mont Ventoux
Piste,vraie,secondaire,TPR2,pas SPI,non
transpondeur fixe
Piste n° 424
Rho=224 Nm(7021), Théta=266°(BD88)
Vitesse=508Kts ou 0,14 Nm/s (0909)
cap=54 ° (2668)
Mode A valide, pas de garbling, mode A brut,
mode A= 1120
Mode C valide,pas de garbling, FL=340
Piste confirmée, radar sec, avion en manœuvre ,
TPR2, pas d'association plot/piste douteuse ,ce
n'est pas une piste fantôme
10
II.2 WIRESHARK
WIRESHARK est un logiciel libre permettant l'écoute et le décodage des trames
circulant sur un réseau. Il fonctionne aussi bien sur Windows que Linux.
(Source : site officiel de WIRESHARK : http://www.WIRESHARK.org/docs/wsug_html/wsug_graphics/wsmain.png)
L’affichage se décompose en trois zones :
- zone du haut : affichage des trames reçues dans l’ordre chronologique,
- zone du milieu : décodage des informations, protocoles par protocoles,
- zone du bas : affichage de la trame en hexadécimale.
11
III. CAHIER DES CHARGES
III.1 LE BESOIN
La subdivision radar de l’aéroport de Toulouse Blagnac a exprimé le besoin de
pouvoir décoder des messages ASTERIX grâce à l’analyseur de protocole réseau
WIRESHARK.
Une première phase du projet a été élaborée par un précédent binôme, cette phase
comprenait la détection des messages ASTERIX à partir des SAC et SIC de la trame envoyée,
en effet un fichier était fourni contenant des valeurs connues de SAC et SIC ainsi si ceux de la
trame envoyée étaient présents dans le fichier associé le message était supposé comme étant
de l’ASTERIX. Cette première phase comprenait également le décodage des messages
ASTERIX de catégories 1 et 48 encapsulées dans du 802.3/LLC. Nous avons ainsi pris en
main le projet avec pour tâches principales :
-
Décodage de messages ASTERIX de catégories supplémentaires (2, 30, 32,
34,255) : En effet a partir de l’instant où les catégories 1 et 48 sont terminées, les
catégories 2 et 34 (Messages de service des radars Secondaire & Mode S) deviennent
indispensables car faisant partie des meubles. La catégorie 30 (Pistes Cautra, Dacota,
Artas) quant à elle contient les informations les plus utilisées par les contrôleurs donc
les plus à même à être analysées. Et pour les catégories 32 et 255 (Alertes &
Messages de service Cautra), le traitement de l’information est moins important mais
de par leur existence avec les mêmes adresses réseaux que les messages de catégorie
30, ces messages doivent être reconnus pour ne pas planter l’application. Une des
exigences primordiales est aussi que le programme ne doit pas planter lorsqu'il
rencontre une catégorie qu'il ne sait pas décoder.
-
Filtrage des trames décodées : Le but est de pouvoir filtrer les messages reçus
suivant différents critères par exemple suivant l’adresse émettrice, ou la catégorie du
message reçu.
-
Modifier l’algorithme de détection des messages ASTERIX : En effet le binôme
précédent s’est basé sur l’identification du SIC et du SAC du message reçu et de les
comparer avec une liste de SIC et de SAC stockée dans un fichier pour pouvoir
vérifier si le message est de type ASTERIX ou non, cet algorithme sera donc modifié
pour que les message de type ASTERIX soient détectés sur le champ « Cmde » du
802.3/LLC qui dans le cas d’ASTERIX est égal à « 0x03 ».
12
III.2 LES CHOIX
III.2.1 ASTERIX
Les catégories de message ASTERIX sont nombreuses (256), mais pas toutes
intéressantes pour l’aviation civile. Les catégories 1 et 48 étant déjà implémentées lors de
notre reprise du projet, nous avons donc décidé de décoder les catégories jugées les plus
importantes par la DTI, à savoir les catégories 2 et 34, ainsi que les catégories portant des
informations en approche à savoir la 30, 32 et 255. En effet, le programme est facilement
adaptable à l’ajout de catégories supplémentaires.
Nous faisons l’hypothèse que les trames ASTERIX sont encapsulées dans de
l’Ethernet IEEE802.3. Hypothèse forte qui se fonde sur les exemples de trames et les
documents mis à notre disposition. Cette hypothèse n’est pas généralisable à l’ensemble des
réseaux transportant de l’ASTERIX. En effet, il peut être transporté sur de l'UDP/IP multicast
ou de l’X25 par exemple. Dans ce cas, nous serons aveugles aux messages ASTERIX
transportés.
III.2.2 WIRESHARK
Un décodeur de protocole est appelé dans WIRESHARK un dissecteur, nous
utiliserons cette dénomination dans la suite du rapport. Ainsi, nous développerons un
dissecteur ASTERIX.
Pour décoder un nouveau protocole, WIRESHARK propose 2 options. La première est
d’intégrer directement notre dissecteur dans le logiciel. Cette méthode a l’inconvénient d’être
lourde lors de la compilation car c’est tout le logiciel qui sera recompilé lors des
modifications sur notre dissecteur. La deuxième est d’intégrer notre dissecteur en tant que
Plugin. Ainsi, seul notre dissecteur sera compilé lors de nos modifications.
Le dissecteur ASTERIX a été intégré en tant que plugin dans WIRESHARK par
le binôme précédent, nous continuerons ainsi le développement dans ce sens.
Une autre exigence de la part de la DTI est le filtrage des données décodées par
WIRESHARK, que ce soit un filtrage par couleur ou un filtrage en visualisation.
WIRESHARK possède des capacités de filtrage puissantes dans ces deux domaines ainsi que
des capacités de filtrage en réception, ce qui permettra un filtrage performant.
III.2.3 Environnement de travail.
Le développement sous Linux du plugin a été choisi pour des raisons de simplicité de
programmation et de compilation. De plus WIRESHARK fait partie de la suite logiciel
fournie de base avec les distributions les plus courantes de Linux.
13
IV. DEVELOPPEMENT
Tout d'abord voici la composition type d'un plug-in WIRESHARK. Des
renseignements supplémentaires sont apportés dans l’annexe technique en vue de
développements ultérieurs.
IV. 1 LE PLUGIN WIRESHARK TYPE
L’architecture d’un plugin WIRESHARK est figée. Elle est décrite dans le manuel du
développeur WIRESHARK qui explique dans les paragraphes 8 et 9 comment ajouter un
plugin (http://www.WIRESHARK.org/docs/wsdg_html_chunked/). Ces explications sont
reprises partiellement dans les README du logiciel.
Pour WIRESHARK, un plugin est un répertoire qui contient au moins les fichiers suivants :
- Makefile.am
- Makefile.common
- Makefile.nmake
- moduleinfo.h
- moduleinfo.nmake
- packet-nom_du_plugin.c
- plugin.rc.in
(pour Unix/Linux)
(pour Windows)
(pour Windows)
(pour Windows)
Les fichiers Makefile sont des fichiers exécutables, ils permettent de compiler
l’ensemble du code grâce à une commande unique.
Les fichiers moduleinfo contiennent des informations sur la version du plugin.
Le fichier packet-nom_du_plugin.c contient le code permettant le découpage du
message ASTERIX.
14
IV. 2 LE PLUGIN ASTERIX
a) Fonctions
Pour développer le plugin ˝ASTERIX˝, les Makefiles ont été modifié afin d'y ajouter
la présence de notre plugin.
Pour ce qui concerne le fichier « .c », qui contient le code du dissecteur ASTERIX et
qui est appelé : ˝packet-ASTERIX.c˝, la structure du code est elle aussi imposée.
Pour coder un plugin, l’interface WIRESHARK propose 3 fonctions :
- proto_register_ASTERIX( )
- proto_reg_handoff_ASTERIX( )
- dissect_ASTERIX( )
La fonction proto_register_ASTERIX( ) enregistre le protocole ASTERIX, son nom,
différentes variables et leurs propriétés d’affichage dans WIRESHARK. C’est dans cette
fonction que nous déclarons la structure des champs du protocole ASTERIX.
La fonction proto_reg_handoff_ASTERIX( ) recueille les cas où le dissecteur
ASTERIX doit être appelé.
La fonction dissect_ASTERIX( ) contient la façon de découper la trame. Nous réalisons
la lecture des champs et leur attribuons le décodage qui leur correspond en fonction des
variables enregistrées dans la fonction proto_register_ASTERIX.
Les catégories que nous avons décodées le sont grâce à différentes fonctions ( une par
catégorie ) appelées à partir de dissect_ASTERIX( ).
15
b) Description des catégories décodées
Description des catégories (ajoutées) décodées par notre plug-in :
Catégorie 2 et 34
La catégorie 34 est la nouvelle version de la catégorie 2, mais n'est pas encore pleinement
utilisée. Nous avons donc dû les décoder de manière distincte, même si de nombreux champs
sont semblables. L'un des nouveaux champs est par exemple le positionnement 3D de la cible.
Ces deux catégories sont utilisées pour les messages de service des monoradars, qu'ils soient
primaire, secondaire, monopulse, Mode S etc...
Les messages transmis dans ces catégories peuvent être répartis dans 3 types :
1. Message des secteurs traversés
2. Message de marqueur de Nord ou Sud
3. Message d'activation ou de stop du filtrage de certaines zones
Les principales informations transmises dans ces catégories sont :
- l'identification du centre émetteur
- L'heure d'envoi du message ainsi que le type de message
- Le numéro du secteur observé
- La période de rotation de l'antenne radar
- Les différentes configurations du radar
- Des informations de warning ou d'erreur
Les informations APPROCHES sont diffusées sur le double réseau local Ethernet des
grandes approches (RESPRI, RESSEC) avec le protocole MAC/LLC1.
Le format des données "pistes" utilise la catégorie 30 d'ASTERIX (Exchange of Air Situation
Pictures) utilisé par ARTAS, la catégorie 32 pour les alertes et une catégorie non normalisée
(255) pour les informations de supervision.
Catégorie 30 : informations piste
La catégorie 30 est utilisée pour coder les données « pistes ». La description logique des
messages piste selon le modèle utilisé par la DAGC est la suivante :
Message Piste
16
Message mort de Piste (DACOTA)
Message informations périodiques
(STR+DACOTA)
Identité serveur
Numéro de piste
statut piste
Identité serveur
Numéro de piste
Position piste
Vitesse piste
Heure m aj piste
Mode A piste
Mode C brut piste
Mode C calculé
taux évolution piste
Tendance niveau piste
statut piste
Identité radar
Aéroport destination
Aéroport de départ
Type de l'aéronef
Indicatif compacté
Numéro PLN
Qualité piste
Catégorie de turbulence
Marquage
Les données codées dans la catégorie 30 contiennent les informations les plus utilisées par
les contrôleurs aériens. Dans sa spécification DGAC le FSPEC de la catégorie 30 peut avoir la
taille maximum de 4 octets, qui peut contenir au maximum 23 champs transmissibles, parmi
eux :
L’identification du système émetteur qui sera présente seulement dans la première piste de
chaque bloc (au sens transmission, c'est-à-dire ensemble de plusieurs enregistrements de
même catégorie) afin d'indiquer l'origine commune de toutes les données du bloc. Par contre
l’heure ne sera transmise que pour chaque premier enregistrement (i.e. piste) d'un bloc de
données, puis dans le premier enregistrement du bloc dont la datation diffère. Cette méthode
permet de ne transmettre l'heure qu'une fois pour toutes les pistes concernées transmises dans
le même bloc. D’autres informations peuvent être importantes car toujours transmises entre
autres : la qualité de la piste (La qualité piste est d'autant meilleure que sa valeur est grande.
Ce champ sera toujours transmis. Il pourrait d'ailleurs servir très prochainement dans
l'affichage d'une piste afin de prévenir le contrôleur de la pertinence des informations
présentées.), la Vitesse calculée dans le plan (correspond à la vitesse calculée à l'heure de
diffusion de la piste, exprimée en coordonnées cartésiennes dans le repère de visualisation.).
Catégorie 32 : alertes
Son champ FSPEC ne contient qu'un seul octet :
8
IDEN
7
6
5
HEM MSAW STCA
4
3
2
1
AD
0
0
EXT
17
A noter que ceci est le FSPEC de la catégorie 32 selon la DGAC. Celui définit par
EUROCONTROL contient les mêmes informations mais dans un ordre différent.
Les deux 1er champs sont classiques et représentent l'identité du centre émetteur
(SAC et SIC), suivi de l'heure d'émission du message.
Le champ MSAW ( Minimum Safe Altitude Warning ) est un champ critique. Il est
émis dès l’apparition de l’alerte et pendant toute sa durée, avec un renouvellement périodique
de 2 secondes.
Le champ STCA ( Short Term Conflict Alert ) contient les Informations filet de
sauvegarde. Ce message est émis à chaque déclenchement d’alertes du filet de sauvegarde. Il
est prioritaire à l’émission par rapport à tout autre message. Si une paire de pistes est en alerte
STCA, un premier message est donc envoyé suivi toutes les deux secondes d’une
confirmation de cette alerte (période de rafraîchissement du filet de sauvegarde).
Figure 1 : Dynamique de la détection d’atterrissage
Détection d'atterrissage de deuxième
niveau niveau
Détection d'atterrissage de
premier niveau
Détection de remise de gaz
Enfin le dernier champ est celui concernant le décollage ou l'atterrissage, et est émis à
chaque détection de décollage ou d’atterrissage.
Le message détection d’atterrissage est émis d’abord toutes les minutes lors d’une
présomption d’atterrissage environ dix minutes avant l’atterrissage effectif (détection
d’atterrissage de premier niveau) puis lors de la détection d’atterrissage de deuxième niveau.
Cependant, il est possible après réception d’un message de présomption d’atterrissage de
recevoir un message indiquant une détection de remise de gaz. Dans ce cas, la détection
d’atterrissage de premier niveau est annulée. Chaque message est émis trois fois de suite à 5
secondes d’intervalle.
catégorie 255 : informations de supervision
18
La Trame est émise périodiquement toutes les 4 secondes.
Son champ FSPEC ne contient qu'un seul octet :
Octet 1 :
Octet 1
8
7
6
5
4
3
2
1
IDEN
HEM
SPE
NIVC
TXTC CART BIAIS EXT
Hormis l'identité et l'heure, les suivants renseignent sur l'état du serveur émettant ces
trames et l'état de la carte dynamique. Le champ le plus intéressant pour les contrôleurs, est
celui renseignant sur les différentes valeurs de biais lors de la poursuite radar, à savoir le gain
et le biais en distance, le biais en azimut et le biais de datation.
Différence entre Catégories suivant le modèle DGAC et le
modèle EUROCONTROL
On observe une différence de spécification entre les standards définis par
EUROCONTROL et ceux utilisés par la DGAC pour les messages ASTERIX de catégories
30,32, et 255. En effet ceux-ci sont des messages d'approche.
Le standard EUROCONTROL de la catégorie 30 permet de coder des données avec un
FSPEC pouvant atteindre au maximum 8 octets, avec un maximum de 52 champs possibles à
transmettre, contrairement à celui utilisé au sein de la DGAC. Il est à noter aussi que l'ordre
d'apparition des champs n'est pas le même. Cependant, la spécification ASTERIX
EUROCONTROL pour la catégorie 30 en plus de contenir tous les champs contenus dans le
modèle utilisé par la DGAC, contient aussi d'autres champs tels que : le mode de vol (mode of
Flight),la catégorie de vol (Flight catégorie), ou encore le type de message.
Pour ce qui est de la catégorie 32, le standard EUROCONTROL permet de coder des
données avec un FSPEC pouvant atteindre au maximum 3 octets, avec un maximum de 18
champs possibles à transmettre, contrairement à celui utilisé au sein de la DGAC, qui contient
un FSPEC de longueur maximale de 1 octet permettant de transmettre au maximum 5
champs. L'ordre d'apparition des champs est aussi différent dans cette catégorie pour les deux
spécifications.
La catégorie 255 quant à n'a pas été définie par EUROCONTROL donc nous avons
utilisé directement la spécification fournie par la DGAC. Cependant il y a un problème au
niveau du décodage des trames de SPIP qui ont un FSPEC de longueurs 2 octets, ce qui n'est
pas conforme à la norme du fichier de la DGAC. Par conséquent en présence des trames de
SPIP notre programme détecte une malformation du paquet ASTERIX correspondant, étant
donné que le décodage de ces trames provenant de SPIP n'a pas été demandé.
Finalement, notre plugin se présentera suivant 2 versions, les différences essentielles
étant faites sur les catégories 30 et 32 qui sont codées dans une version suivant la norme
DGAC et dans l'autre suivant la norme EUROCONTROL.
19
c) Mise en place de filtres
Le cahier des charge spécifiait l'introduction de 2 types de filtres : ceux en
visualisation et ceux en ceux en couleurs.
Le filtrage en couleurs a consisté à modifier le fichier texte « color_filters.txt » afin
d'associer à chaque catégorie décodée une couleur dans la fenêtre du haut de WIRESHARK.
Cette distinction des catégories est possible en testant la valeur de « ASTERIX.categorie »
que l'on a définit dans notre plug-in.
Le filtrage en visualisation consiste à n'afficher dans la fenêtre du haut uniquement les
champs que l'on souhaite. Ainsi, grâce aux fonctionnalités performantes de WIRESHARK, on
peut filtrer les trames en fonction de leur adresse MAC de provenance ou de destination, ou
en fonction de leur catégorie. Par exemple si l'on ne souhaite garder que les trames de
catégorie 30 et 255, il suffit d'utiliser ce filtre :
(asterix.categorie == 0x1E) && (asterix.categorie == 0xFF)
De plus, la mise en place d’autres filtres permet de ne sélectionner que les champs contenant
des données spécifiques. Si l'on ne souhaite visualiser que les trames contenant une
information sur le mode A, le filtre ASTERIX.modeA le permettra.
d) Détection du protocole ASTERIX
Comment reconnaitre qu’une trame reçue est de type ASTERIX ?
Lorsque nous avons pris en main le projet, la détection du protocole ASTERIX se
faisait sur les champs SAC et SIC comme expliqué ci-dessous :
WIRESHARK analyse les paquets circulant sur le réseau et commence par analyser les
protocoles de plus bas niveau. Avec notre hypothèse, les paquets auront la structure suivante :
SSAP
DSAP
cmde
ethernet
cat
long
fspec
SAC
SIC
Message Asterix
20
Le premier protocole décodé est donc l’Ethernet.
Pour annoncer des protocoles de niveau supérieur, le champ SSAP est utilisé. Pour le
protocole ASTERIX, nous avons :
SSAP = DSAP
Les valeurs de SSAP et de DSAP sont normalisées au sein de la DGAC. Cependant, les
valeurs ne sont pas normalisées par une norme internationale. Une valeur de SSAP ne
conditionne pas que la suite du message soit spécifiquement de l’ASTERIX.
Le problème est que le test sur les SSAP et DSAP se faisant dans le dissecteur LLC de
WIRESHARK, ce test n'était pas réalisé. La détection de l'ASTERIX se faisait donc
seulement sur les champs lus (SAC et SIC) correspondant à des valeurs normées, connues et
stockées dans un fichier.
Si les valeurs SAC et SIC ne correspondaient pas, le protocole analysé était considéré
comme non ASTERIX et resté sous WIRESHARK comme un Paquet LLC.
Cette technique était très peu efficace, car la mise en place d'un tel fichier comprenant
les SAC et SIC imposait de connaître toutes ces valeurs pour tous les radars, et sa
modification en cas de rajout d'un radar ou d'une modification autre. De plus à chaque appel
du dissecteur ASTERIX, des tests sur ces SAC et SIC étaient effectués, et donc ce dissecteur
pouvait avoir été appelé inutilement si les critères n'étaient pas vérifiés.
Or il s'avère que, après plusieurs vérifications et une confirmation de la part de la
DGAC, une valeur de 0x03 dans le champ cmde ci-dessus annonce de l'ASTERIX, et cette
valeur est exclusive à ce protocole au sein de la DGAC. Une détection reposant sur le champ
cmde était donc à prévoir, cependant la condition sur ce champ ne suffisait pas car certaines
trames possédaient en plus un DSAP et un SSAP différents, donc nous avons aussi intégré le
test d’égalité des champs SSAP et DSAP.
L'avantage de cette technique est de pouvoir appeler directement le dissecteur
ASTERIX à partir du dissecteur LLC, lorsque le champ cmde est égal à 0x03 et
SSAP=DSAP, on évite ainsi les appels inutiles de notre dissecteur.
Un des inconvénients à cette implémentation est qu'il a fallu étudier le code du
dissecteur LLC afin de le modifier convenablement. Alors que notre dissecteur ASTERIX a
été intégré en tant que plug-in, le dissecteur LLC est lui implémenté au cœur de
WIRESHARK, étant donné que le protocole LLC est un protocole courant. Ainsi la moindre
modification maladroite risquait d'entraîner une erreur de segmentation lors du lancement de
WIRESHARK. De plus, la recompilation du logiciel en tenant compte des modifications
apportées au cœur de WIRESHARK était plus longue que la recompilation du logiciel avec le
dissecteur sous forme de plug-in.
Un des problèmes rencontrés lors de la mise en place de cette seule technique de
détection fut l’arrêt brutal de l'application lors du test de certains fichiers. Finalement nous
avons donc décidé de combiner les trois étages de vérification à savoir l’égalité des champs
SSAP et DSAP, la valeur 0x03 sur le champ cmde, et les valeurs SAC et SIC vérifiées dans
un fichier, ceci a pu résoudre le problème de l’arrêt brutal de l’application lors du test de
certains fichiers. Même si la mise à jour du fichier SAC et SIC sera nécessaire, il vaut mieux
vérifier le protocole trois fois plutôt qu'une.
21
V. TESTS
Pour tester la validité et la cohérence du dissecteur ASTERIX, ainsi que le bon
décodage de chaque catégorie, nous avons d'une part créé des trames ASTERIX particulières
grâce à un éditeur de code hexadécimal (Khexedit), ainsi qu'utilisé des captures de trames
réelles que notre correspondant à Blagnac nous a envoyé.
Capture d’écran de Khexedit.
22
Notre procédure de tests s'est déroulée en 2 phases majeures.
La première phase a consisté à tester chaque catégorie une fois son codage terminé, à
l'aide des trames de capture réelles. Ce premier test nous a permis de corriger les erreurs de
gestion du pointeur utilisé pour décoder chaque trame, et qui annonçait que la trame était
malformée. Cette phase a aussi permis l'amélioration de l'affichage dans la zone centrale de
WIRESHARK.
Durant la deuxième phase où nous avons créé des trames à la main avec Khexedit, la
méthode a été fastidieuse mais a porté ses fruits. En effet cette étape de création a été assez
longue puisqu'elle a consisté à refaire toute la démarche inverse à WIRESHARK, à savoir
l'encodage de trames au format ASTERIX. Ainsi, en choisissant les valeurs que l'on voulait
décoder, on a pu s'assurer du bon décodage de notre plug-in, et si les valeurs ne
correspondaient pas les corriger. Ces fichiers de test ont été créés de façon a être les plus
complet possibles, c'est à dire que tous les champs possibles de la catégorie y ont été intégrés.
Ceci a d'autant été plus important que parmi les fichiers de capture dont nous disposions,
beaucoup de champs n'y étaient pas représentés du tout, et donc par conséquent non vérifiés
lors de la première phase.
Par exemple si certains octets étaient signés, nous avons pu alors nous assurer grâce aux
fichiers de test que le signe « - » était bien présent devant les valeurs en question. La
vérification de la bonne conversion des mètres en pieds ou en Flight Level ou une attention
particulière à la justesse de la traduction de l’hexadécimal vers le décimal a été apportée.
23
Démarche suivie :
A l'aide du fichier de test complet crée avec Hexedit, on ouvre celui-ci dans WIRESHARK, et
apparaît comme malformé. Cela veut donc dire qu'il reste des octets en fin de trame que le
dissecteur n'a pas lu, ou que le dissecteur ASTERIX essait de lire des octets alors que la trame
a déjà été toute lue. Le problème vient donc d'un défaut de décalage de notre pointeur associé
à la trame, ce qui peut se poduire si on ne le décale que de 2 par exemple alors que le champ à
lire en question comporte 3 octets. Les valeurs suivant ce décalage ne sont donc pas valables (
l'heure par exemple est censée être 12h00).
24
Après correction de la malformation, on peut donc vérifier les valeurs de chaque champs,
étant donné que l'on connaît ces valeurs puisque nous avons crée ce fichier de test.
Ici la période de rotation de l'antenne est beaucoup trop élevée. On peut donc retourner dans
le code et corriger ce problème de conversion, qui était une multiplication au lieu d'une
division par un facteur 128 de la donnée binaire transmise dans le protocole.
25
Ainsi après toutes les corrections et les nouveaux tests, on obtient le décodage final ci
dessous, où on peut bien voir que la période de rotation est correcte et est de 30 secondes.
26
VI. CONCLUSION
Déroulement du projet
Notre projet s’est déroulé en plusieurs étapes.
La première partie de notre projet a consisté en une analyse globale du problème. Il a
fallu s'imprégner du format des messages ASTERIX, comprendre l'architecture de
WIRESHARK et ensuite, comprendre le programme déjà écrit, en s'imprégnant de
l'algorithmique utilisée et des fonctions particulières à WIRESHARK.
Dans un deuxième temps, nous avons appris à recompiler et à réinstallé WIRESHARK
afin de comprendre tous les mécanismes utilisés.
Ensuite après avoir pris connaissance des catégories prioritaires à décoder, nous avons
développées leurs fonctions de décodage à la suite du fichier créé par le binôme précédent, car
le programme du plug-in ne doit résider que dans un seul fichier « .c ».Les phases de tests ont
ensuite été essentielles dans le développement de notre module.
Enfin la modification de la détection du protocole ASTERIX et la mise en place de
filtres a terminé la partie développement de ce projet.
Notre module détecte donc maintenant les catégories 1, 48, 2, 34, 32, 30 et 255 en se
basant sur le champ cmde égal à 0x03 et sur le SIC et SAC, avec une version conforme à la
norme EUROCONTROL et une version utilisée au sein de la DGAC et donc à Blagnac.
Problèmes rencontrés et Solutions apportées
La prise en main d’un code informatique n’est pas toujours une procédure facile,
néanmoins suite à une analyse poussée nous avons pu comprendre le fonctionnement et les
idées mises en place par nos prédécesseurs. Aussi pour chaque catégorie développée il fallait
la tester au moyen d’un fichier, or il s’est avéré que les fichiers de capture fournis par la
DGAC ne contiennent pas tous les champs transmissibles, à cet effet nous avons donc dû
écrire des fichiers de test.
Le projet a aussi un peu été allongé par la découverte de l'utilisation d'une spécification
spéciale DGAC pour les informations d'approche, après avoir déjà ces catégories suivant la
norme EUROCONTROL ce qui nous rendait les trames malformées. L'échange d'information
avec le responsable du projet au sein de la DGAC et certains experts du protocole ASTERIX
nous a permis d'obtenir les informations et la documentation nécessaires pour résoudre ce
problème.
Nous avons aussi rencontré un problème majeur lorsque nous avons entreprit de modifier
l’algorithme détection de la trame ASTERIX, ce qui implique donc une modification des
fonctions de base du logiciel ASTERIX et plus précisément le fichier « packet-llc.c ». A la
suite d’une recherche et de l’analyse du dit code qui faut le noter a été écrit par une
communauté de développeurs, nous avons néanmoins pu arriver à réaliser la tâche.
Perspectives
Le module ASTERIX implémenté contient déjà le décodage des principales catégories
utilisées au sein de la DGAC. Ce décodage se faisant sur de l’ASTERIX encapsulé dans de
l’Ethernet, une étape suivante serait d’envisager le décodage de l’ASTERIX encapsulé dans
de l’UDP/IP, en effet le logiciel ELVIRA réalisé par la DTI permet d’enregistrer les
informations radar dans le but de les relire ou de les réémettre sur le réseau. Ce logiciel
permet de réémettre en UDP/IP des données préalablement enregistrées en LLC.
27
Le module logiciel intégré a été développé dans un environnement LINUX, porter le
module sous Windows sera une nécessité par la suite étant donné que tous les outils d’analyse
au sein de la DGAC dont WIRESHARK sont installés sur l'OS Microsoft Windows XP.
Une amélioration du filtrage consisterait à colorier dans la partie du milieu de
WIRESHARK le champ filtré.
28
VII. TABLE DE REFERENCE
-
http://www.EUROCONTROL.int/ASTERIX/public/subsite_homepage/homepage.htm
l.
Documentation EUROCONTROL sur le protocole ASTERIX
-
www.comsoft.de/download/atc/product/english/ASTERIX.pdf
Documentation des produits ASTERIX de la société COMSOFT
-
http://www.WIRESHARK.org/docs/wsdg_html_chunked/
Manuel du développeur WIRESHARK
-
DDIAPPROCHE_V3R6
Auteur : EQUIPE STR (DTI)
Document de description des flux de données logiques et physiques diffusés par le
STR ou DACOTA.
-
ARTAS V62 (Cat30_31_32_252)
Auteur : EUROCONTROL
Standard EUROCONTROL pour l’échange des données entre ARTAS V6 et ses
utilisateurs (catégorie messages 30, 31, 32 et 255).
-
« Développement d’un module de décodage logiciel WIRESHARK pour le trafic radar
au format ASTERIX » Première partie
Auteurs : DREVON Bertrand, ZONCO Vincent
Standard EUROCONTROL pour l’échange des données entre ARTAS V6 et ses
utilisateurs (catégorie messages 30, 31, 32 et 255).
29
VIII. GLOSSAIRE
ARTAS : Air Traffic Management Surveillance Tracker and Server System, c'est le système
conçu pour établir une précision du traffic aérien au dessus d'une zone géographique définie,
et de distribuer les informations de surveillance à une communauté d'utilisateurs système.
ASTERIX : All Purpose STructured EUROCONTROL suRveillance Information eXchange
CAUTRA : Coordination Automatique du Trafic Aérien, c'est le système informatique de
contrôle et surveillance que le Service Technique de la Navigation Aérienne met en place et
fait évoluer dans les différents centres régionaux.
DACOTA : Dispositif d'Association, de COrrélation et de Traitement radar pour les
Approches :
Le système de traitement radar DACOTA a pour but de présenter aux contrôleurs une image
de la situation aérienne adaptée aux besoins spécifiques des approches.
DTI : Direction de la technique et de l'innovation
EUROCONTROL: The European Organisation for the Safety of Air Navigation
FSPEC : Field Specification
LLC : Logical Link Control (couche 2 Liaison)
OS : Operating system ou système d'exploitation
SAC : Source Area Code (0x08 pour la France)
SIC : Source Identification Code - numéro du radar source (0 à 255). Ce numéro est
européen.
STR : Système de Traitement Radar
SNA/S : Service de la Navigation Aérienne section SUD
UDP : User Datagram Protocol (couche 4 Transport)
X25 : le protocole X25 n'est pas un protocole de communication mais plutôt une
recommandation normalisé par commutation de paquets en mode point à point offrant de
nombreux services. Bien qu’il tende à disparaitre, il est encore utilisé dans des réseaux tel que
le réseau de la navigation aérienne, dans le protocole radio AX.25
30
IX. ANNEXE
Compilation et installation
Avant de se lancer dans la création de plugin, il est fortement conseiller de lire le
fichier WIRESHARK/doc/README.plugins. En effet, il nous est expliqué comment ajouter
un plugin et comment le compiler.
Après avoir téléchargé les fichiers WIRESHARK, nous allons les compiler. Les
fichiers à copiers sont :
« packet-llc.c » à copier dans le repertoire « ./epan/dissectors/ »
« colorfilters » à copier dans le repertoire « ./ »
le dossier « ASTERIX » et les makefile « Makefile », « Makefile.am », « Makefile.in»,
« Makefile.nmake» à copier dans le repertoire « ./plugins », la racine étant le repertoire
principale de WIRESHARK.
Dans le dossier « ASTERIX » doivent figurer un certain nombre de fichiers. Ils sont
explicités dans le README.plugins. En particulier, le fichier packet-ASTERIX.c qui
correspond à la programmation du « dissecteur » ASTERIX.
Ensuite, pour que notre plugin puisse être compilé, il faut modifier quelques fichiers,
en particulier des MakeFile. Là encore, le fichier README.plugins est invoqué.
La compilation se passe en 3 commandes, à la racine du dossier WIRESHARK :
autogen.sh, positionne les variables d'environnement.
./configure
./make (en cas de problème de mise à jour de fichiers faire make clean avant de faire make)
./make install, commande très importante.
Le fichier « liste_sac_sic » se trouvant dans le dossier « ASTERIX » doit être modifié
lors de mise à jour des paramètres SAP, SAC et SIC.
Les paramètres sont écrits en décimal de la façon suivante dans le fichier :
32 08 23
32 08 14
Les entiers sont séparés par des espaces. Il est indispensable d’avoir les 3 champs présents sur
une ligne.
Organisation du fichier « packet-ASTERIX.c »
Voici maintenant l’algorithme simplifié de quelques fonctions importantes :
Dissect_asterix( )
Début
…
On récupère les couples (SAC,SIC) ;
TANT QUE ( on n’a pas fini de lire la trame )
SI ( il s’agit du protocole Asterix )
Lire le bloc ;
SINON …
Fin Tant Que
…
Fin
31
Lire_bloc( )
Début …
TANT QUE ( on n’a pas fini de lire le bloc )
Lire les enregistrements
FIN Tant Que
…
Fin
Lire_enregistrement( )
Début …
SWITCH( catégorie )
On décode les champs de l’enregistrement ;
/* 1 enregistrement = 1 fspec et les champs correspondants */
Fin Switch
Fin
Liste des commandes de Filtrage
Pour filtrer les trames reçues venant d'une adresse particulière « addr_source » il suffit
de saisir l'expression suivante dans la barre de Filtre :
« eth.src == addr_source »
Le filtrage se faisant directement au niveau du protocole Ethernet.
La syntaxe « ASTERIX » permet de limiter l'affichage à des trames de type
ASTERIX.
Pour filtrer une catégorie particulière il suffit de saisir:
« ASTERIX.categorie == categorie_a_filtrer »
categorie_a_filtrer pouvant prendre les valeurs (0x01, 0x02, 0x1e, 0x20, 0x22, 0xFF)
« ASTERIX.modeA » permet de filtrer toutes les trames contenant le champ
mode A quelque soit la catégorie.
« ASTERIX.modeS » permet de filtrer toutes les trames contenant le champ
mode S quelque soit la catégorie.
« ASTERIX.track_number » permet de filtrer toutes les trames
contenant le champ numéro de piste quelque soit la catégorie.
32

Développement d`un module de décodage logiciel WIRESHARK

Transcription

Documents pareils

PARC ASTERIX Dimanche 22 mai 2016

PARC ASTERIX

ASTERIX ET LE TOUR DE GAULE (EN RUSSE

Billetterie Parc Astérix Saison 2014 et 2015

FCI Certificat

Thème : FAIS MOI PEUR !

Box Office in France (in Million entrances)

Voici une vignette d`une B.D d`Asterix et Obelix crée par Uderzo et