Provided by: manpages-fr_3.57d1p1-1_all bug

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> ».