ip | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
SYNOPSIS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
tcp_socket = socket(PF_INET, SOCK_STREAM, 0);
udp_socket = socket(PF_INET, SOCK_DGRAM, 0);
raw_socket = socket(PF_INET, SOCK_RAW, protocol);
DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
L'interface de programmation est compatible avec les sockets BSD. Pour plus de renseignements sur les sockets, voir socket(7).
Une socket IP est créée par la fonction socket(2) invoquée sous la forme socket(PF_INET, type_socket, protocole). les types valides des sockets sont SOCK_STREAM pour ouvrir une socket tcp(7), SOCK_DGRAM pour ouvrir une socket udp(7), ou SOCK_RAW pour ouvrir une socket raw(7) permettant d'accéder directement au protocole IP. Le protocole indiqué est celui inscrit dans les entêtes IP émis ou reçus. Les seules valeurs valides pour le protocole sont 0 et IPPROTO_TCP pour les sockets TCP, et 0 et IPPROTO_UDP pour les sockets UDP. Pour les sockets SOCK_RAW on peut indiquer un protocole IP IANA valide dont la RFC 1700 précise les numéros assignés.
Lorsqu'un processus veut recevoir de nouveaux paquets entrants ou connexions, il doit attacher une socket à une adresse d'interface locale en utilisant bind(2). Une seule socket IP peut être attachée à une paire (adresse, port) locale donnée. Lorsqu'on indique INADDR_ANY lors de l'attachement, la socket sera affectée à toutes les interfaces locales. Si on invoque listen(2) ou connect(2) sur une socket non affectée, elle est automatiquement attachée à un port libre aléatoire, avec l'adresse locale fixée sur INADDR_ANY.
L'adresse locale d'une socket TCP qui a été attachée est indisponible pendant quelques instants après sa fermeture, à moins que l'attribut SO_REUSEADDR ait été activé. Il faut être prudent en utilisant ce drapeau, car il rend le protocole TCP moins fiable.
Format d'adresse | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
struct sockaddr_in { sa_family_t sin_family; /* famille d'adresses : AF_INET */ uint16_t sin_port; /* port dans l'ordre d'octets réseau */ struct in_addr sin_addr; /* adresse Internet */ }; /* Adresse Internet */ struct in_addr { uint32_t s_addr; /* Adresse dans l'ordre d'octets réseau */ };
sin_family est toujours rempli avec AF_INET. C'est indispensable. Sous Linux 2.2, la plupart des fonctions réseau renvoient EINVAL lorsque cette configuration manque. sin_port contient le numéro de port, dans l'ordre des octets du réseau. Les numéros de ports inférieures à 1024 sont dits réservés. Seuls les processus privilégiés (c'est à dire ceux qui ont la capacité CAP_NET_BIND_SERVICE) peuvent appeler bind(2) pour ces ports. Notez que le protocole IPv4 en tant que tel n'a pas de concept de ports, ils sont seulement implémentés par des protocoles de plus haut-niveau comme tcp(7) et udp(7).
sin_addr est l'adresse IP de l'hôte. le membre s_addr de la structure struct in_addr contient l'adresse de l'interface de l'hôte, dans l'ordre des octets du réseau. in_addr devrait être affecté par l'une des valeurs INADDR_* (par exemple, INADDR_ANY) ou configuré avec les fonctions de bibliothèque inet_aton(3), inet_addr(3), inet_makeaddr(3) ou directement par le système de résolution des noms (voir gethostbyname(3)). Les adresses IPv4 sont divisées en adresses unicast, broadcast et multicast. Les adresses unicast décrivent une interface unique d'un hôte, les adresses broadcast correspondent à tous les hôtes d'un réseau, et les adresses multicast représentent tous les hôtes d'un groupe multicast. Les datagrammes vers des adresses broadcast ne peuvent être émis et reçus que si l'attribut de socket SO_BROADCAST est activé. Dans l'implémentation actuelle, les sockets orientées connexion ne sont autorisées que sur des adresses unicast.
Remarquez que l'adresse et le port sont toujours stockés dans l'ordre des octets du réseau. Cela signifie qu'il faut invoquer htons(3) sur le numéro attribué à un port. Toutes les fonctions de manipulation d'adresse et port de la bibliothèque standard fonctionne dans l'ordre du réseau.
Il existe plusieurs adresses particulières : INADDR_LOOPBACK (127.0.0.1) correspond toujours à l'hôte local via le périphérique loopback ; INADDR_ANY (0.0.0.0) signifie un attachement à n'importe quelle adresse ; INADDR_BROADCAST (255.255.255.255) signifie n'importe quel hôte et à le même effet que INADDR_ANY pour des raisons historiques.
Options des sockets | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
struct in_pktinfo { unsigned int ipi_ifindex; /* Numéro d'interface */ struct in_addr ipi_spec_dst; /* Adresse locale */ struct in_addr ipi_addr; /* Adresse destination */ };
#define SO_EE_ORIGIN_NONE 0 #define SO_EE_ORIGIN_LOCAL 1 #define SO_EE_ORIGIN_ICMP 2 #define SO_EE_ORIGIN_ICMP6 3 struct sock_extended_err { uint32_t ee_errno; /* numéro d'erreur */ uint8_t ee_origin; /* origine de l'erreur */ uint8_t ee_type; /* type */ uint8_t ee_code; /* code */ uint8_t ee_pad; uint32_t ee_info; /* autres informations */ uint32_t ee_data; /* autres données */ /* champs supplémentaires éventuels */ }; struct sockaddr *SOCK_EE_OFFENDER(struct sock_extended_err *);
Attribut MTU chemin | Signification |
IP_PMTUDISC_WANT | Utiliser une configuration par route. |
IP_PMTUDISC_DONT | Ne pas rechercher le MTU par chemin. |
IP_PMTUDISC_DO | Toujours rechercher le MTU par chemin. |
IP_PMTUDISC_PROBE | Activer DF mais ignorer la MTU par chemin. |
Lorsque la recherche du PMTU est active, le noyau garde automatiquement une trace des MTU des chemins par hôte destinataire. Lorsqu'il est connecté à un correspondant spécifique avec connect(2), le MTU du chemin actuellement déterminé peut être consulté en utilisant l'option IP_MTU de la socket (par exemple si une erreur EMSGSIZE se produit). Cette valeur peut changer dans le temps. Pour les sockets sans connexions, avec plusieurs destinations, le nouveau MTU pour une destination donnée peut également être obtenu en utilisant la file d'erreur (voir IP_RECVERR). Une nouvelle erreur sera mise en file pour chaque mise à jour du MTU.
Durant la recherche du MTU, les paquets initiaux des sockets datagrammes peuvent être perdus. Les applications utilisant UDP devraient le savoir, et les éviter dans leur stratégie de retransmission.
Pour démarrer le processus de recherche du MTU par chemin sur les sockets non-connectées, il est possible de démarrer avec une grande taille de datagramme (jusqu'à 64 ko d'entête) et la diminuer au fur et à mesure des mises à jours du MTU du chemin.
Pour obtenir une estimation initiale du MTU d'un chemin connectez une socket datagramme à l'adresse de destination en utilisant connect(2) et consultez le MTU en appelant getsockopt(2) avec l'option Il est possible d'implémenter la RFC 4821 pour les recherches de MTU avec des sockets SOCK_DGRAM ou SOCK_RAW en utilisant la valeur IP_PMTUDISC_PROBE. C'est aussi particulièrement utile pour les outils de diagnostic comme tracepath(8) qui souhaitent délibérément envoyer des paquets sonde plus grands que le MTU observé du chemin. IP_MTU.
struct ip_mreqn { struct in_addr imr_multiaddr; /* Adresse IP du groupe multicast */ struct in_addr imr_address; /* Adresse IP de l'interface locale */ int imr_ifindex; /* Numéro d'interface */ };
imr_multiaddr contient l'adresse du groupe multicast que l'application veut rejoindre ou quitter. Il doit s'agir d'une adresse multicast valide. imr_address est l'adresse de l'interface locale avec laquelle le système doit joindre le groupe multicast. Si elle est égale à INADDR_ANY, une interface appropriée est choisie par le système. imr_ifindex est le numéro de l'interface pour rejoindre ou quitter le groupe imr_multiaddr, ou zéro pour indiquer n'importe quelle interface.
Sysctls | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Lorsque ce drapeau booléen et actif (différent de zéro), les fragments entrants (morceaux de paquets IP obtenus car un hôte entre l'origine et la destination a décidé que les paquets étaient trop grands et les a coupé en morceaux) seront réassemblés (défragmentés) avant d'être traités, même s'ils doivent être redirigés (forwarded).
À utiliser uniquement pour un firewall qui est le seul lien d'entrée de votre réseau, ou un proxy transparent. Ne jamais activer pour un routeur normal ou un hôte. Sinon, les communications fragmentées peuvent être interrompues lorsque les fragments circulent par différents liens. La défragmentation a également un coût mémoire et CPU non négligeable.
Ceci est automatiquement activé lorsque le masquerading ou le proxy transparent est configuré.
Ioctls | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Les ioctls pour configurer les paramètres génériques des périphériques sont décrits dans netdevice(7).
ERREURS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
D'autres erreurs peuvent être déclenchées par les protocoles supérieurs. Voir tcp(7), raw(7), udp(7) et socket(7).
VERSIONS | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
IP_PMTUDISC_PROBE est nouvelle dans Linux 2.6.22.
struct ip_mreqn est nouvelle dans Linux 2.2. Sous Linux 2.0, seule existait ip_mreq.
NOTES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Certaines autres implémentations des sockets BSD fournissent les options de socket IP_RCVDSTADDR et IP_RECVIF pour obtenir l'adresse de destination et l'interface des datagrammes reçus. Linux à l'option IP_PKTINFO plus générale pour effectuer ce travail.
Certaines implémentations de sockets BSD fournissent également une option IP_RECVTTL, mais un message auxilliaire de type IP_RECVTTL est passé avec le paquet entrant. Cela est différent de l'option IP_TTL sous Linux.
L'utilisation du niveau d'option socket SOL_IP n'est pas portable, les piles basées sur BSD utilisent le niveau IPPROTO_IP.
Compatibilité | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
BOGUES | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Les ioctls pour configurer les options d'interface spécifiques IP et les tables ARP ne sont pas décrites.
Certaines versions de la glibc oublient la déclaration in_pktinfo. Le remède est de recopier dans votre programme la description de cette page de manuel.
La réception de l'adresse de destination originale avec MSG_ERRQUEUE dans msg_name par recvmsg(2) ne fonctionne pas dans certains noyaux 2.2.
VOIR AUSSI | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
RFC 791 pour les spécifications IP d'origine.
RFC 1122 pour les nécessités IPv4 des hôtes.
RFC 1812 pour les nécessités IPv4 des routeurs.
TRADUCTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Ce document est une traduction réalisée par Christophe Blaess <http://www.blaess.fr/christophe/> le 9 juin 2001 et révisée le 6 juin 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 7 ip ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.
Sommaire | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
Table des mots clés | Début | Suivant | Sommaire | Préc.page.lue | Accueil |