Provided by: manpages-fr_3.57d1p1-1_all 
NOM
packet - Interface par paquet au niveau du périphérique
SYNOPSIS
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h> /* les protocoles L2 */
packet_socket = socket(AF_PACKET, int type_socket, int protocole);
DESCRIPTION
Les sockets paquet sont utilisées pour envoyer ou recevoir des paquets de données bruts au
pilote de périphérique (couche 2 OSI). Elles permettent d'implémenter des modules
protocoles dans l'espace utilisateur au dessus de la couche physique.
L'argument type_socket est soit SOCK_RAW pour les paquets incluant l'en-tête de couche
liaison, soit SOCK_DGRAM pour les paquets préparés sans en-tête de couche liaison. Les
informations d’en-tête de couche liaison sont disponibles dans un format commun, par
l'intermédiaire d'un sockaddr_ll. protocole est un numéro de protocole IEEE 802.3 dans
l'ordre des octets du réseau. Consultez le fichier d'en-tête <linux/if_ether.h> pour avoir
une liste des protocoles autorisés. Lorsque le numéro demandé est htons(ETH_P_ALL) alors
tous les protocoles sont reçus. Tous les paquets entrants du protocole indiqué seront
passés à la socket paquet avant d'être transmis aux protocoles implémentés dans le noyau.
Seuls les processus avec un UID effectif nul ou la capacité CAP_NET_RAW peuvent ouvrir des
sockets paquet.
Les paquets SOCK_RAW sont transmis depuis et vers le pilote de périphérique sans aucune
modification des données des paquets. Lors de la réception, l'adresse est toujours
examinée et fournie dans une structure standard sockaddr_ll. Lors de l'émission d'un
paquet, le tampon fourni par l'utilisateur doit contenir l'en-tête de couche physique. Le
paquet est alors mis en attente sans modification à l'attention du pilote de périphérique
correspondant à l'interface définie par l'adresse de destination. Certains pilotes de
périphérique ajoutent toujours d'autres en-têtes. SOCK_RAW est similaire mais non
compatible avec l'ancien AF_INET/SOCK_PACKET de Linux 2.0.
SOCK_DGRAM opère à un niveau légèrement plus élevé. L'en-tête de couche physique est
supprimé avant que le paquet ne soit transmis à l'utilisateur. Les paquets envoyés par une
socket paquet SOCK_DGRAM reçoivent un en-tête de couche physique correct, en fonction des
informations dans l'adresse destination sockaddr_ll avant d'être mis en attente.
Par défaut, tous les paquets du type de protocole indiqué sont passés à la socket paquet.
Pour ne recevoir que les paquets d'une interface donnée, utilisez bind(2) en indiquant une
adresse dans une struct sockaddr_ll pour attacher la socket à une interface. Seuls les
champs d'adresse sll_protocol et sll_ifindex sont utilisés pour l'attachement.
L'opération connect(2) n'est pas prise en charge avec les sockets paquet.
Lorsque l'attribut MSG_TRUNC est transmis à recvmsg(2), recv(2), recvfrom(2) la véritable
longueur du paquet sur le réseau est toujours renvoyée, même si elle est plus grande que
le tampon.
Types d’adresses
La structure sockaddr_ll est une adresse de couche physique dépendant du périphérique.
struct sockaddr_ll {
unsigned short sll_family; /* Toujours AF_PACKET */
unsigned short sll_protocol; /* Protocole couche physique */
int sll_ifindex; /* Numéro d'interface */
unsigned short sll_hatype; /* Type de matériel ARP */
unsigned char sll_pkttype; /* Type de paquet */
unsigned char sll_halen; /* Longueur de l'adresse */
unsigned char sll_addr[8]; /* Adresse couche physique */
};
sll_protocol est le type de protocole standard ethernet, dans l'ordre des octets du
réseau, comme défini dans le fichier d'en-tête <linux/if_ether.h>. Par défaut il s'agit du
protocole de la socket. sll_ifindex est le numéro de l'interface (consultez
netdevice(7)) ; 0 correspond à n'importe quelle interface (autorisé uniquement pour
l'attachement). sll_hatype est un type ARP, comme défini dans le fichier d'en-tête
<linux/if_arp.h>. Le champ sll_pkttype contient le type de paquet. Les types valables sont
PACKET_HOST pour un paquet destiné à l'hôte local, PACKET_BROADCAST pour un paquet
broadcast de couche physique, PACKET_MULTICAST pour un paquet envoyé à une adresse
multicast de couche physique, PACKET_OTHERHOST pour un paquet destiné à un autre hôte
capturé par un pilote de périphérique en mode promiscuous, et PACKET_OUTGOING pour un
paquet provenant de l'hôte local rebouclé sur une socket paquet. Ça n'a de signification
qu'en réception. sll_addr et sll_halen contiennent l'adresse de couche physique (par
exemple IEEE 802.3) et sa longueur. L'interprétation exacte dépend du périphérique.
Lorsque des paquets sont envoyés, il suffit d'indiquer sll_family, sll_addr, sll_halen,
sll_ifindex. Les autres champs devraient être à zéro. sll_hatype et sll_pkttype sont
remplis en réception pour information. Pour l'attachement, seuls sll_protocol et
sll_ifindex sont utilisés.
Options de sockets
Les options de la socket paquet sont configurées en appelant setsockopt(2) avec le niveau
SOL_PACKET.
PACKET_ADD_MEMBERSHIP
PACKET_DROP_MEMBERSHIP
Les options des sockets paquet permettent de configurer le multicasting de couche
physique et le mode promiscuous. PACKET_ADD_MEMBERSHIP ajoute un attachement et
PACKET_DROP_MEMBERSHIP le supprime. Les deux options attendent une structure
packet_mreq en paramètre :
struct packet_mreq {
int mr_ifindex; /* Numéro d'interface */
unsigned short mr_type; /* Action */
unsigned short mr_alen; /* Longueur d'adresse */
unsigned char mr_address[8]; /* Adr. couche physique */
};
mr_ifindex contient le numéro de l'interface dont l'état doit être modifié. Le
paramètre mr_type indique l'action à effectuer. PACKET_MR_PROMISC valide la
réception de tous les paquets circulant sur le segment de réseau commun (souvent
appelé « mode promiscuous »), PACKET_MR_MULTICAST attache la socket au groupe
multicast de couche physique indiqué dans mr_address et mr_alen, et
PACKET_MR_ALLMULTI demande à la socket de recevoir tous les paquets multicast
arrivant sur l'interface.
De plus, les ioctls classiques SIOCSIFFLAGS, SIOCADDMULTI et SIOCDELMULTI peuvent
donner les mêmes résultats.
PACKET_AUXDATA (depuis Linux 2.6.21)
Si cette option est activée, la socket paquet fournit avec chaque paquet une
structure de métadonnées à l’aide du champ de contrôle de recvmsg(2). La structure
peut être lue avec cmsg(3). Elle est définie ci-dessous :
struct tpacket_auxdata {
__u32 tp_status;
__u32 tp_len; /* longueur du paquet */
__u32 tp_snaplen; /* longueur capturée */
__u16 tp_mac;
__u16 tp_net;
__u16 tp_vlan_tci;
__u16 tp_padding;
};
PACKET_FANOUT (depuis Linux 3.1)
Pour s’adapter aux nombre de traitements des threads, les sockets paquet peuvent
former un groupe de déploiement. Dans ce mode, tous les paquets correspondants sont
mis en attente dans une seule socket du groupe. Une socket rejoint un groupe de
déploiement en appelant setsockopt(2) avec le niveau SOL_PACKET et l’option
PACKET_FANOUT. Tous les espaces de noms réseau peuvent avoir jusqu’à 65536 groupes
indépendants. Une socket sélectionne un groupe en encodant l’identifiant dans les
16 premiers bits du paramètre entier de cette option. La première socket paquet à
rejoindre un groupe le crée implicitement. Pour réussir à rejoindre un groupe
existant, les sockets paquet suivantes doivent avoir les mêmes protocole,
configurations de périphérique, mode de déploiement et attributs (voir ci-dessous).
Les sockets paquet ne peuvent quitter un groupe de déploiement qu’en fermant la
socket. Le groupe est supprimé quand la dernière socket est fermée.
Le déploiement permet à de nombreux algorithme de diffuser le trafic entre socket.
Le mode par défaut, PACKET_FANOUT_HASH, envoie les paquets du même flux à la même
socket pour conserver l’ordre par flux. Pour chaque paquet, il choisit une socket
en prenant le hachage de flux de paquet modulo le nombre de sockets dans le groupe,
où le hachage de flux est un hachage de l’adresse de couche réseau et
facultativement des champs de port de couche de transport. Le mode de répartition
de charge PACKET_FANOUT_LB met en place un algorithme tourniquet (« round-robin »).
PACKET_FANOUT_CPU sélectionne la socket en fonction du processeur sur lequel le
paquet est arrivé. PACKET_FANOUT_ROLLOVER traite toutes les données sur une seule
socket et se déplace vers la suivante quand elle a du retard. PACKET_FANOUT_RND
sélectionne la socket en utilisant un générateur de nombres pseudoaléatoires.
Les modes de déploiement acceptent des options facultatives. La fragmentation d’IP
force les paquets du même flux à avoir des hachages de flux différents. L’attribut
PACKET_FANOUT_FLAG_DEFRAG, si défini, force la défragmentation de paquets avant
d’appliquer le déploiement, pour conserver l’ordre même dans ce cas. Le mode de
déploiement et les options sont communiquées sur les 16 bits suivants du paramètre
entier de cette option. L’attribut PACKET_FANOUT_FLAG_ROLLOVER active le mécanisme
de recouvrement comme une stratégie de sauvegarde : si l’algorithme de déploiement
original sélectionne une socket avec du retard, le paquet se retourne vers la
suivante disponible.
PACKET_LOSS (avec PACKET_TX_RING)
Ne pas jeter silencieusement un paquet en cas d'erreur de transmission, mais le
renvoyer avec l'état TP_STATUS_WRONG_FORMAT.
PACKET_RESERVE (avec PACKET_RX_RING)
Par défaut, un tampon circulaire de réception des paquets écrit les paquets juste
après la structure de métadonnées et le bourrage dû à l'alignement. Le paramètre
entier de cette option réserve de la place au début du paquet (« headroom »).
PACKET_RX_RING
Créer un tampon circulaire projeté en mémoire pour la réception asynchrone de
paquets. La socket paquet réserve une zone contiguë d’espace d’adresses
d’application, la dispose dans un tableau d’emplacements de paquet et copie les
paquets (jusqu’à tp_snaplen) dans les emplacements suivants. Tous les paquets sont
précédés d’une structure de métadonnées similaire à tpacket_auxdata. Les champs de
protocole encodent la position des données dès le début de l’en-tête de
métadonnées. tp_net stocke la position de couche réseau. Si la socket paquet est de
type SOCK_DGRAM, alors tp_mac est la même. Si elle est de type SOCK_RAW, alors ce
champ stocke la position de la trame de couche lien. La socket paquet et
l’application communiquent le début et la fin du tampon circulaire à l’aide du
champ tp_status. Tous les emplacements avec l’état TP_STATUS_KERNEL appartiennent à
la socket paquet. Après avoir rempli un emplacement, elle modifie l’état de
l’emplacement pour qu’il appartienne à l’application. Lors d’une opération normale,
le nouvel état est TP_STATUS_USER, pour signaler qu’un paquet reçu correctement a
été stocké. Lorsque l’application a terminé de traiter un paquet, elle redéfinit
l’état de l’emplacement à TP_STATUS_KERNEL pour le rendre à la socket. Les sockets
paquet mettent en place plusieurs variantes du tampon circulaire de paquets. Des
précisions sur cette mise en place sont disponibles dans
Documentation/networking/packet_mmap.txt dans l'arborescence des sources du noyau
Linux.
PACKET_STATISTICS
Récupérer les statistiques de la socket paquet sous la forme d'une structure
struct tpacket_stats {
unsigned int tp_packets; /* Décompte total des paquets */
unsigned int tp_drops; /* Décompte des paquets jetés */
};
Recevoir les statistiques réinitialise les compteurs internes. La structure de
statistiques est différente lorsque le tampon circulaire utilisé est de type
TPACKET_V3.
PACKET_TIMESTAMP (avec PACKET_RX_RING ; depuis Linux 2.6.36)
Le tampon circulaire de réception des paquets stocke un horodatage dans l’en-tête
de métadonnées. Par défaut, c’est un horodatage logiciel généré quand le paquet est
copié dans le tampon circulaire. Le paramètre entier de cette option sélectionne le
type d’horodatage. En plus du fonctionnement par défaut, deux formats matériels
existent et sont décrits dans Documentation/networking/timestamping.txt dans
l'arborescence des sources du noyau Linux.
PACKET_TX_RING (depuis Linux 2.6.31)
Créer un tampon circulaire projeté en mémoire pour la transmission de paquets.
Cette option est similaire à PACKET_RX_RING et accepte les mêmes arguments.
L’application écrit des paquets dans des emplacements avec l’état
TP_STATUS_AVAILABLE et les programme pour transmission en modifiant l’état de
TP_STATUS_SEND_REQUEST. Quand les paquets sont prêts à être transmis, l’application
appelle send(2) ou une de ses variantes. Les champs buf et len de cet appel sont
ignorés. Si une adresse est passée en utilisant sendto(2) ou sendmsg(2), alors cela
écrase la socket par défaut. En cas de transmission réussie, la socket réinitialise
l’emplacement à TP_STATUS_AVAILABLE. Elle rejette silencieusement les paquets en
cas d’erreur sauf si PACKET_LOSS est définie.
PACKET_VERSION (avec PACKET_RX_RING ; depuis Linux 2.6.27)
Par défaut, PACKET_RX_RING crée un tampon circulaire de réception des paquets de
variante TPACKET_V1. Pour créer une autre variante, configurer la variante voulue
en définissant le paramètre entier de cette option avant de créer le tampon
circulaire.
Ioctls
SIOCGSTAMP peut servir à obtenir l'horodatage du dernier paquet reçu. Le paramètre est une
variable struct timeval.
De plus, les ioctls standards définis dans netdevice(7) et socket(7) sont valables sur les
sockets paquet.
Traitement des erreurs
Les sockets paquet ne gèrent pas d'autres erreurs que celles se produisant durant la
transmission des paquets au pilote de périphérique. Elles ne traitent pas le concept de
file d'erreurs.
ERREURS
EADDRNOTAVAIL
Adresse de groupe multicast inconnue.
EFAULT Adresse mémoire incorrecte.
EINVAL Argument incorrect.
EMSGSIZE
Le paquet est plus grand que le MTU de l'interface.
ENETDOWN
L'interface n'est pas active.
ENOBUFS
Pas assez de mémoire pour le paquet.
ENODEV Le nom du périphérique ou l'index d’interface indiqué dans l'adresse de l'interface
est inconnu.
ENOENT Pas de paquet reçu.
ENOTCONN
Aucune adresse d'interface n'a été passée.
ENXIO Numéro d'interface non valable.
EPERM L'utilisateur n'a pas les privilèges nécessaires pour l'opération.
De plus, d'autres erreurs peuvent être engendrées par le pilote bas niveau.
VERSIONS
AF_PACKET est une nouveauté de Linux 2.2. Les versions précédentes de Linux ne prenaient
en charge que SOCK_PACKET.
Le fichier d'inclusion <netpacket/packet.h> existe depuis glibc 2.1. Les systèmes plus
anciens ont besoin de :
#include <asm/types.h>
#include <linux/if_packet.h>
#include <linux/if_ether.h> /* Les protocoles L2 */
NOTES
Pour la portabilité, il est conseillé d'utiliser les fonctionnalités AF_PACKET par
l'intermédiaire de l'interface pcap(3), bien que cela ne couvre qu'un sous-ensembles des
possibilités de AF_PACKET.
Les sockets paquet SOCK_DGRAM n'essayent pas de créer ou de traiter les en-têtes
IEEE 802.2 LLC pour une trame IEEE 802.3. Lorsque le protocole ETH_P_802_3 est indiqué en
émission, le noyau crée la trame 802.3 et remplit le champ de longueur. L'utilisateur doit
fournir l'en-tête LLC pour obtenir un paquet entièrement conforme. Les paquets 802.3
entrants ne sont pas multiplexés sur les champs du protocole DSAP/SSAP. À la place, ils
sont fournis à l'utilisateur sous le protocole ETH_P_802_2 avec un en-tête LLC ajouté.
L’attachement ETH_P_802_3 n’est donc pas possible, l'attachement ETH_P_802_2 doit être
utilisé à la place, et vous devez réaliser le multiplexage de protocole vous-même. Le
comportement par défaut en émission est l'encapsulation Ethernet DIX standard, avec le
protocole renseigné.
Les sockets paquet ne sont pas soumises aux chaînes de pare-feu en entrée ou sortie.
Compatibilité
Sous Linux 2.0, la seule manière d'obtenir une socket paquet était l'appel socket(AF_INET,
SOCK_PACKET, protocole). C’est encore pris en charge mais fortement déconseillé. La
principale différence entre les deux méthodes est que SOCK_PACKET utilise l'ancienne
struct sockaddr_pkt pour indiquer l'interface, ce qui ne fournit aucune indépendance
vis-à-vis de la couche physique.
struct sockaddr_pkt {
unsigned short spkt_family;
unsigned char spkt_device[14];
unsigned short spkt_protocol;
};
spkt_family contient le type de périphérique, spkt_protocol est le type de protocole
IEEE 802.3 comme défini dans <sys/if_ether.h> et spkt_device est le nom du périphérique
sous forme de chaîne terminée par un caractère nul, par exemple eth0.
Cette structure est obsolète et ne doit pas être employée dans des nouveaux programmes.
BOGUES
La glibc 2.1 ne définit pas la constante symbolique SOL_PACKET. Pour contourner ce
problème, il est conseillé d'écrire :
#ifndef SOL_PACKET
#define SOL_PACKET 263
#endif
C’est corrigé dans les dernières versions de la glibc et ne se produit pas sur les LibC5.
La gestion des en-têtes LLC IEEE 802.2/802.3 devrait être considérée comme un bogue.
Les filtres des sockets ne sont pas documentés.
L'extension MSG_TRUNC de recvmsg(2) est une bidouille horrible et devrait être remplacée
par un message de commande. Il n'y a actuellement aucun moyen d'obtenir l'adresse de
destination originale des paquets à l’aide de SOCK_DGRAM.
VOIR AUSSI
socket(2), pcap(3), capabilities(7), ip(7), raw(7), socket(7)
RFC 894 pour l'encapsulation IP Ethernet standard. RFC 1700 pour l'encapsulation IP
IEEE 802.3.
Le fichier d'en-tête <linux/if_ether.h> pour les protocoles de couche physique.
COLOPHON
Cette page fait partie de la publication 3.57 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies peuvent être trouvées à
l'adresse http://www.kernel.org/doc/man-pages/.
TRADUCTION
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Christophe Blaess <http://www.blaess.fr/christophe/> (1996-2003), Alain Portal
<http://manpagesfr.free.fr/> (2003-2006). Julien Cristau et l'équipe francophone de
traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le paquet
manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la
commande « man -L C <section> <page_de_man> ».