Provided by: manpages-fr_4.19.0-7_all bug

NOM

       packet – Interface de paquets au niveau du périphérique

SYNOPSIS

       #include <sys/socket.h>
       #include <linux/if_packet.h>
       #include <net/ethernet.h> /* Les protocoles L2 */

       packet_socket = socket(AF_PACKET, int type_socket, int protocole);

DESCRIPTION

       Les  sockets  packet sont utilisés pour envoyer ou recevoir des paquets bruts au pilote de
       périphérique (couche 2 OSI). Ils permettent d'implémenter des modules  de  protocole  dans
       l'espace utilisateur au-dessus de la couche physique.

       The  socket_type  is  either  SOCK_RAW  for raw packets including the link-level header or
       SOCK_DGRAM for cooked packets with the link-level header removed.  The  link-level  header
       information  is  available  in a common format in a sockaddr_ll structure. protocol is the
       IEEE 802.3 protocol number in network byte order. See the <linux/if_ether.h> include  file
       for  a  list  of  allowed  protocols.  When  protocol is set to htons(ETH_P_ALL), then all
       protocols are received. All incoming packets of that protocol type will be passed  to  the
       packet  socket  before  they  are  passed  to  the protocols implemented in the kernel. If
       protocol is set to zero, no packets are received. bind(2) can optionally be called with  a
       nonzero sll_protocol to start receiving packets for the protocols specified.

       Pour  pouvoir créer des sockets packet, un processus doit posséder la capacité CAP_NET_RAW
       dans l’espace de noms utilisateur qui régit son espace de noms réseau.

       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 d’un paquet, l'adresse est
       toujours examinée et fournie dans une structure standard d’adresse  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  un
       socket  packet  SOCK_DGRAM  reçoivent  un  en-tête de couche physique correct basé sur les
       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  au  socket  packet.
       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 le socket à une  interface.  Les  champs
       utilisés  pour  la  liaison  sont  sll_family  (devrait  être  AF_PACKET), sll_protocol et
       sll_ifindex.

       L'opération connect(2) n'est pas prise en charge sur les sockets packet.

       Lorsque l'attribut MSG_TRUNC  est  transmis  à  recvmsg(2),  recv(2)  ou  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 indépendante 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 */
           };

       Les membres de cette structure sont les suivants :

       sll_protocol
              is the standard ethernet protocol type in network byte  order  as  defined  in  the
              <linux/if_ether.h> include file. It defaults to the socket's protocol.

       sll_ifindex
              is the interface index of the interface (see netdevice(7)); 0 matches any interface
              (only permitted for  binding).  sll_hatype  is  an  ARP  type  as  defined  in  the
              <linux/if_arp.h> include file.

       sll_pkttype
              contains the packet type. Valid types are PACKET_HOST for a packet addressed to the
              local   host,   PACKET_BROADCAST   for   a   physical-layer    broadcast    packet,
              PACKET_MULTICAST   for  a  packet  sent  to  a  physical-layer  multicast  address,
              PACKET_OTHERHOST for a packet to some other host that has been caught by  a  device
              driver  in  promiscuous mode, and PACKET_OUTGOING for a packet originating from the
              local host that is looped back to a packet socket. These types make sense only  for
              receiving.

       sll_addr
       sll_halen
              contain  the  physical-layer  (e.g.,  IEEE 802.3) address and its length. The exact
              interpretation depends on the device.

       Lorsque des paquets sont envoyés, il suffit d'indiquer  sll_family,  sll_addr,  sll_halen,
       sll_ifindex  et  sll_protocol.  Les  autres  champs  devraient  être à zéro. sll_hatype et
       sll_pkttype sont remplis en réception pour information.

   Options de socket
       Les options du socket packet sont configurées en appelant  setsockopt(2)  avec  le  niveau
       SOL_PACKET.

       PACKET_ADD_MEMBERSHIP
       PACKET_DROP_MEMBERSHIP
              Les  options  des sockets packet permettent de configurer le multicasting de couche
              physique et le  mode  promiscuous.  PACKET_ADD_MEMBERSHIP  ajoute  une  liaison  et
              PACKET_DROP_MEMBERSHIP  la  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]; /* Adresse couche physique */
                  };

              mr_ifindex contient le numéro de l'interface dont  l'état  doit  être  modifié.  Le
              champ  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 le socket au groupe multicast de
              couche physique indiqué dans mr_address et mr_alen, et  PACKET_MR_ALLMULTI  demande
              au socket de recevoir tous les paquets multicast arrivant sur l'interface.

              De  plus,  les ioctls classiques SIOCSIFFLAGS, SIOCADDMULTI et SIOCDELMULTI peuvent
              parvenir au même résultat.

       PACKET_AUXDATA (depuis Linux 2.6.21)
              Si cette option est activée, le  socket  packet  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_vlan_tpid; /* Depuis Linux 3.14 ; précédemment
                                             c’était des octets de remplissage
                                             non utilisés */
                  };

       PACKET_FANOUT (depuis Linux 3.1)
              Pour s’adapter au nombre de traitements des threads,  les  sockets  packet  peuvent
              former un groupe de déploiement. Dans ce mode, tous les paquets correspondants sont
              mis en attente dans un seul socket du  groupe.  Un  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.  Un  socket  sélectionne un groupe en encodant l’identifiant dans les
              16 premiers bits de la valeur d’entier de cette option. Le premier socket packet  à
              rejoindre  un  groupe  le  crée  implicitement.  Pour réussir à rejoindre un groupe
              existant, les sockets packet suivants doivent avoir  le  même  protocole,  la  même
              configuration  de  périphérique, le même mode de déploiement et les mêmes attributs
              (voir ci-dessous). Les sockets packet ne peuvent quitter un groupe  de  déploiement
              qu’en fermant le socket. Le groupe est supprimé quand le dernier socket est fermé.

              Le déploiement gère plusieurs algorithmes pour répartir le trafic entre les sockets
              comme suit :

              •  Le mode par défaut, PACKET_FANOUT_HASH, envoie les paquets du même flux au  même
                 socket pour maintenir l’ordre par flux. Pour chaque paquet, il choisit un socket
                 en prenant le hachage du flux de paquets modulo le nombre  de  sockets  dans  le
                 groupe,  où  le  hachage  du  flux  est un hachage sur les adresses de la couche
                 réseau et les champs facultatifs de port de la couche transport.

              •  Le mode répartition de charge PACKET_FANOUT_LB met en  œuvre  un  algorithme  de
                 tourniquet (round-robin).

              •  PACKET_FANOUT_CPU  sélectionne  le  socket en se basant sur le CPU sur lequel le
                 paquet arrive.

              •  PACKET_FANOUT_ROLLOVER traite toutes les données sur un seul socket, allant  sur
                 le suivant quand le socket devient débordé.

              •  PACKET_FANOUT_RND  sélectionne  le  socket en utilisant un générateur de nombres
                 pseudo-aléatoires.

              •  PACKET_FANOUT_QM  (disponible  depuis  Linux 3.14)  sélectionne  le  socket   en
                 utilisant le queue_mapping enregistré du tampon de socket (SKB) reçu.

              Les  modes  de  déploiement acceptent des options supplémentaires. 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 l’application du déploiement, pour conserver  l’ordre  même  dans  ce
              cas.  Le  mode  de  déploiement  et  les options sont communiqués sur les deuxièmes
              16 bits    de    la    valeur    d’entier    de    cette     option.     L’attribut
              PACKET_FANOUT_FLAG_ROLLOVER  active le mécanisme de déplacement comme une stratégie
              de sauvegarde : si l’algorithme  de  déploiement  originel  sélectionne  un  socket
              débordé, le paquet se déplace vers le suivant disponible.

       PACKET_LOSS (avec PACKET_TX_RING)
              Lorsqu'un  paquet malformé est trouvé dans le tampon circulaire de transmission, le
              comportement par défaut est de réinitialiser son tp_status à TP_STATUS_WRONG_FORMAT
              et  d'abandonner  immédiatement  la  transmission. Le paquet malformé ainsi que les
              paquets suivants mis en file d'attente voient leur transmission  bloquée.  L'erreur
              de  format doit être corrigée, la valeur tp_status associée doit être réinitialisée
              à  TP_STATUS_SEND_REQUEST  et  le   processus   de   transmission   redémarré   par
              l'intermédiaire  de l'interface send(2). Cependant, si PACKET_LOSS est défini, tout
              paquet malformé est ignoré, son tp_status est réinitialisé à TP_STATUS_AVAILABLE et
              le processus de transmission continue.

       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  remplissage  d'alignement.  La  valeur
              d’entier de cette option réserve une possibilité de transmission supplémentaire.

       PACKET_RX_RING
              Créer  un  tampon  circulaire  projeté  en  mémoire pour la réception asynchrone de
              paquets.  Le  socket  packet  réserve  une   zone   contiguë   d’espace   d’adresse
              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 la couche réseau. Si le socket packet est
              de type SOCK_DGRAM, alors tp_mac est la même. S’il est de type SOCK_RAW,  alors  ce
              champ  stocke  la  position  de  la  trame  de  couche liaison. Le socket packet et
              l’application communiquent le début et la fin du  tampon  circulaire  à  l’aide  du
              champ  tp_status.  Tous  les  emplacements  avec  tp_status valant TP_STATUS_KERNEL
              appartiennent au socket packet. Après  avoir  rempli  un  emplacement,  il  modifie
              l’état  de  l’emplacement  pour  qu’il  appartienne  à  l’application.  Lors  d’une
              opération  normale,  la  nouvelle  valeur  de  tp_status  a  au   moins   son   bit
              TP_STATUS_USER  activé,  pour  signaler  qu’un  paquet  reçu  a été stocké. Lorsque
              l’application a terminé de traiter  un  paquet,  elle  transfère  la  propriété  de
              l’emplacement au socket en redéfinissant tp_status à TP_STATUS_KERNEL.

              Les  sockets  packet  mettent  en œuvre plusieurs variantes du tampon circulaire de
              paquets.  Des  précisions  sur  cette  mise  en   place   sont   disponibles   dans
              Documentation/networking/packet_mmap.rst  dans  l'arborescence des sources du noyau
              Linux.

       PACKET_STATISTICS
              Récupérer les statistiques du socket packet 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.  Cette  option  d’entier  sélectionne  le  type
              d’horodatage.  En plus du fonctionnement par défaut, il gère deux formats matériels
              décrits  dans  Documentation/networking/timestamping.rst  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  tp_status égal à
              TP_STATUS_AVAILABLE et les programme pour transmission en modifiant tp_status à  la
              valeur  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 le socket par défaut. En cas de transmission réussie,  le  socket
              réinitialise  tp_status  à  TP_STATUS_AVAILABLE.  Il  interrompt  immédiatement  la
              transmission 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 l’option d’entier avant de créer le tampon circulaire.

       PACKET_QDISC_BYPASS (depuis Linux 3.14)
              By default, packets sent through packet sockets pass  through  the  kernel's  qdisc
              (traffic  control)  layer,  which  is  fine for the vast majority of use cases. For
              traffic generator appliances using packet sockets that intend to brute-force  flood
              the network—for example, to test devices under load in a similar fashion to pktgen—
              this layer can be bypassed by setting this integer option to 1. A  side  effect  is
              that  packet  buffering in the qdisc layer is avoided, which will lead to increased
              drops when network device transmit queues are busy;  therefore,  use  at  your  own
              risk.

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

   Traitement des erreurs
       Les  sockets  packet  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  le  numéro  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 dans son adresse.

       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.

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-ensemble  des
       possibilités de AF_PACKET.

       Les  sockets  packet  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é.  La
       liaison  ETH_P_802_3  n’est donc pas possible, la liaison ETH_P_802_2 doit être utilisée à
       la place, et vous devez réaliser le multiplexage de protocoles vous-même. Le  comportement
       par  défaut  en  émission  est  l’encapsulation  Ethernet  DIX standard, avec le protocole
       renseigné.

       Les sockets packet ne sont pas soumis aux chaînes de pare-feu en entrée ou sortie.

   Compatibilité
       Avec Linux 2.0, la seule façon d’obtenir un socket paquet était avec l’appel :

           socket(AF_INET, SOCK_PACKET, protocol)

       C’est encore pris  en  charge  mais  obsolète  et  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 octet NULL, par exemple eth0.

       Cette structure est obsolète et ne doit pas être employée dans des nouveaux programmes.

BOGUES

   LLC header handling
       La gestion des en-têtes LLC IEEE 802.2/802.3 devrait être considérée comme un bogue.

   MSG_TRUNC issues
       L'extension  MSG_TRUNC  de recvmsg(2) est une bidouille horrible et devrait être remplacée
       par un message de contrôle. Il n'y a  actuellement  aucun  moyen  d'obtenir  l'adresse  de
       destination originelle des paquets à l’aide de SOCK_DGRAM.

   spkt_device device name truncation
       The  spkt_device  field  of  sockaddr_pkt  has  a size of 14 bytes, which is less than the
       constant IFNAMSIZ defined in <net/if.h> which is 16 bytes and describes the  system  limit
       for a network interface name. This means the names of network devices longer than 14 bytes
       will be truncated to fit into spkt_device. All these lengths include the terminating  null
       byte ('\0')).

       Issues  from  this  with old code typically show up with very long interface names used by
       the Predictable Network Interface Names feature enabled by default in  many  modern  Linux
       distributions.

       The  preferred  solution  is to rewrite code to avoid SOCK_PACKET. Possible user solutions
       are to disable Predictable Network Interface Names or to rename the interface to a name of
       at most 13 bytes, for example using the ip(8)  tool.

   Documentation issues
       Les filtres des sockets ne sont pas documentés.

VOIR AUSSI

       socket(2), pcap(3), capabilities(7), ip(7), raw(7), socket(7), ip(8),

       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.

       L'arbre des sources du noyau Linux.  /Documentation/networking/filter.rst  décrit  comment
       appliquer     des     filtres     Berkeley     de     paquets    aux    sockets    packet.
       /tools/testing/selftests/net/psock_tpacket.c contient  un  exemple  de  code  source  pour
       toutes les versions de PACKET_RX_RING et PACKET_TX_RING.

TRADUCTION

       La  traduction  française  de  cette  page  de  manuel  a  été créée par Christophe Blaess
       <https://www.blaess.fr/christophe/>, Stéphan  Rafin  <stephan.rafin@laposte.net>,  Thierry
       Vignaud  <tvignaud@mandriva.com>,  François Micaux, Alain Portal <aportal@univ-montp2.fr>,
       Jean-Philippe   Guérard   <fevrier@tigreraye.org>,   Jean-Luc   Coulon   (f5ibh)    <jean-
       luc.coulon@wanadoo.fr>,    Julien    Cristau    <jcristau@debian.org>,    Thomas   Huriaux
       <thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
       Duneau  <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
       Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>  et  Jean-Paul  Guillonneau
       <guillonneau.jeanpaul@free.fr>

       Cette  traduction  est  une  documentation libre ; veuillez vous reporter à la GNU General
       Public  License  version 3  ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩   concernant   les
       conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
       message à ⟨debian-l10n-french@lists.debian.org⟩.