Se connecter
Se connecter
Inscription
Mot de passe perdu
Connexion:
[Actualités]
Windows 11 : le menu Démarrer ne fonctionne parfois plus après la mise à jour
[Actualités]
Test Legacy of Kain Soul Reaver 1&2 Remastered (PS5) - Raziel de retour
[Actualités]
2025 nous apportera le nouvel iPad abordable : nouveaux détails de lancement
[Actualités]
Découvrons quand le Père Noël arrivera pour livrer nos cadeaux, avec Santa Tr...
[Actualités]
Nintendo Switch 2, la date d'annonce et le mois de sortie ont-ils été révélÃ...
[Actualités]
WhatsApp nous permet désormais de réagir à un message en « tirant des confet...
[Actualités]
Les pliables ne décollent pas ? Samsung réduit ses plans de production
[Actualités]
PS5, Sony bannit-il les utilisateurs qui utilisent le navigateur "caché" de la ...
[Actualités]
Test The Thing Remastered (PS5) - Une refonte du classique de 2002
[Actualités]
L'iPhone le plus fin de tous les temps sera aussi le moins cher : ce que l'on sa...
[Articles]
Legacy of Kain Soul Reaver 1&2 Remastered
[Articles]
The Thing Remastered
[Articles]
Mario & Luigi : L'épopée fraternelle
[Articles]
Deel acquiert la plateforme mondiale de gestion de la rémunération Assemble
[Articles]
Xuan Yuan Sword: The Gate of Firmament
[Articles]
Cyber-sécurité : bilan 2024 et regard vers 2025 par Andy Garth, directeur Aff...
[Articles]
Diesel Legacy: The Brazen Age
[Articles]
FANTASIAN Neo Dimension
[Articles]
Fairy Tail 2
[Articles]
Réseaux sociaux inondés d'arnaques deepfake ; Formbook, voleur d'informations ...
Actualités
Lettre d'information
Proposer une actualité
Archives
Actualités
Articles
Programmation
Press Release
Matériel
Logiciels
Livres
Interviews
Derniers commentaires
Jeux Vidéos
XBox One
XBox 360
Wii U
PSP
PS4
PS3
PC
DS
GameCube
3DS
Forum
Derniers messages
Informatique
Fun
Divers
Logithèque
Blogs
Divers
A Propos
Annonceurs
Contact
Recherche
RSS
Editer un article
Titre
Mots Clés
Texte
[size=18] [b]Nom[/b] [/size] ip - Implémentation Linux du protocole IPv4. [size=18] [b]Résumé[/b] [/size] [b]#include
[/b] [b][/b] [b]#include
[/b] [b][i]tcp_socket = socket(PF_INET, SOCK_STREAM, 0);[/i][/b] [b][/b] [b][i]raw_socket = socket(PF_INET, SOCK_RAW, protocol );[/i][/b] [b][/b] [b][i]udp_socket = socket(PF_INET, SOCK_DGRAM, protocol );[/i][/b] [size=18] [b]Description[/b] [/size] Linux implémente le Protocole Internet (IP) version 4, décrit dans les RFC 791 et RFC 1122. [b]ip [/b] contient une implémentation du multicasting niveau 2 conforme à la RFC 1112. Elle contient aussi un routeur IP comprenant un filtre de paquets. L'interface de programmation est compatible avec les sockets BSD. Pour plus de renseignements sur les sockets, voir [b]socket (7). [/b] Une socket IP est créée par la fonction [b]socket (2) [/b] invoquée sous la forme [b]socket(PF_INET, type_socket, protocole) .[/b] les types valides des sockets sont [b]SOCK_STREAM [/b] pour ouvrir une socket [b]tcp (7),[/b] [b]SOCK_DGRAM[/b] pour ouvrir une socket [b]udp (7),[/b] ou [b]SOCK_RAW[/b] pour ouvrir une socket [b]raw (7)[/b] permettant d'accéder directement au protocole IP. Le [i]protocole[/i] indiqué est celui inscrit dans les en-têtes IP émis ou reçus. Les seules valeurs valides pour le [i]protocole[/i] sont [b]0[/b] et [b]IPPROTO_TCP[/b] pour les sockets TCP, et [b]0[/b] et [b]IPPROTO_UDP [/b] pour les sockets UDP. Pour les sockets [b]SOCK_RAW[/b] 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 [b]bind (2).[/b] Une seule socket IP peut être attachée à une paire (adresse, port) locale donnée. Lorsqu'on indique [b]INADDR_ANY [/b] lors de l'attachement, la socket sera affectée à [i]toutes[/i] les interfaces locales. Si on invoque [b]listen (2)[/b] ou [b]connect (2)[/b] sur une socket non affectée, elle est automatiquement attachée à un port libre aléatoire, avec l'adresse locale fixée sur [b]INADDR_ANY .[/b] 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 [b]SO_REUSEADDR[/b] ait été activé. Il faut être prudent en utilisant ce drapeau, car il rend le protocole TCP moins fiable. [size=18] [b]Format dadresse[/b] [/size] Une adresse de socket IP est définie comme la combinaison d'une adresse IP d'interface et d'un numéro de port. Le protocole IP de base ne fournit pas de numéro de port, ils sont implémentés par les protocoles de plus haut-niveau comme [b]udp (7)[/b] et [b]tcp (7).[/b] Sur les sockets raw, le champ [b]sin_port[/b] contient le protocole IP. [table][row][col] [/col][col] .nf .ta 4n 19n 31n struct sockaddr_in { sa_family_t sin_family; /* famille d'adresses : AF_INET */ u_int16_t sin_port; /* port dans l'ordre d'octets réseau */ struct in_addr sin_addr; /* adresse Internet */ }; /* Adresse Internet */ struct in_addr { u_int32_t s_addr; /* Adresse dans l'ordre d'octets réseau */ }; .ta .fi[/col][/row][/table] [i]sin_family [/i] est toujours rempli avec [b]AF_INET . [/b] C'est indispensable. Sous Linux 2.2, la plupart des fonctions réseau renvoient [b]EINVAL[/b] lorsque cette configuration manque. [i]sin_port[/i] contient le numéro de port, dans l'ordre des octets du réseau. Les numéros de ports inférieures à 1024 sont dits [b]réservés .[/b] Seuls les processus avec un UID effectif nul ou la capacité [b]CAP_NET_BIND_SERVICE [/b] peuvent appeler [b]bind (2) [/b] 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 [b]tcp (7)[/b] et [b]udp (7).[/b] [i]sin_addr [/i] est l'adresse IP de l'hôte. le membre [i]addr[/i] de la structure [b]struct in_addr[/b] contient l'adresse de l'interface de l'hôte, dans l'ordre des octets du réseau. [b]in_addr [/b] ne doit être manipulé qu'au travers des fonctions de bibliothèque [b]inet_aton (3),[/b] [b]inet_addr (3),[/b] [b]inet_makeaddr (3)[/b] ou directement par le système de résolution des noms (voir [b]gethostbyname (3)).[/b] 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 [b]SO_BROADCAST[/b] 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 [b]htons (3) [/b] 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 : [b]INADDR_LOOPBACK[/b] (127.0.0.1) correspond toujours à l'hôte local via le périphérique loopback ; [b]INADDR_ANY [/b] (0.0.0.0) signifie un attachement à n'importe quelle adresse ; [b]INADDR_BROADCAST[/b] (255.255.255.255) signifie n'importe quel hôte et à le même effet que [b]INADDR_ANY[/b] pour des raisons historiques. [size=18] [b]Options[/b] [/size] IP supporte quelques options des sockets spécifiques aux protocoles, fixées avec [b]setsockopt (2)[/b] et consultées avec [b]getsockopt (2).[/b] Le niveau d'option de socket pour IP est [b]SOL_IP .[/b] Un attribut booléen en faux quand il est nul, et vrai sinon. [b]IP_OPTIONS[/b] [table][row][col] [/col][col]Fixe ou lit les options IP à envoyer avec chaque paquet sur cette socket. Les arguments sont un pointeur sur un buffer contenant les options et la longueur des options. L'appel [b]setsockopt (2)[/b] fixe les options IP associées à une socket. La taille maximale des options pour IPv4 est 40 octets. Voir la RFC 791 pour les options autorisées. Lorsque le paquet de connexion initiale d'une socket [b]SOCK_STREAM[/b] contient des options IP, celles-ci seront automatiquement attribué à la socket, avec les options de routage inversées. Les paquets entrants ne peuvent pas modifier les options après que la connexion est établie. Le traitement des options de routage des paquets entrant est désactivé par défaut, et peut être validé en utilisant la requête sysctl [b]accept_source_route .[/b] Les autres options, comme l'horodatage sont toujours traitées. Pour les socket datagrammes, les options IP ne peuvent être fixées que par l'utilisateur local. L'appel de [b]getsockopt (2)[/b] avec [i]IP_OPTIONS[/i] remplit le buffer fourni avec les options d'émission actuelles. [/col][/row][/table] [b]IP_PKTINFO[/b] [table][row][col] [/col][col]Fournit un message [i]IP_PKTINFO[/i] de service, qui contient une structure [b]pktinfo [/b] fournissant quelques informations à propos du paquet entrant. Ceci ne fonctionne que pour les sockets orientées datagrammes. L'argument est un drapeau indiquant à la socket sur le message IP_PKTINFO doit être passé ou non. Le message lui-même ne peut être écrit ou lu que comme message de contrôle avec un paquet, en utilisant [b]recvmsg (2)[/b] ou [b]sendmsg (2).[/b] [/col][/row][/table] [table][row][col] [/col][col] [table][row][col] [/col][col].ta 4n 19n 33n .nf 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 */ }; .fi[/col][/row][/table][/col][/row][/table] [b]ipi_ifindex[/b] [table][row][col] [/col][col]est le numéro unique de l'interface sur laquelle le paquet a été reçu. [b]ipi_spec_dst[/b] est l'adresse locale du paquet, et [b]ipi_addr[/b] est l'adresse de destination dans l'en-tête du paquet. Si [i]IP_PKTINFO [/i] est passé à [b]sendmsg (2)[/b] et si [b]ipi_spec_dest[/b] est non nul, alors il sera utilisé comme adresse source pour la recherche dans la table de routage, et pour fixer les options de routage IP. Si [b]ipi_ifindex[/b] est non nul, l'adresse local principale de l'interface indiquée par cet index écrase [b]ipi_spec_dst[/b] pour a table de routage.[/col][/row][/table] [b]IP_RECVTOS[/b] [table][row][col] [/col][col]Le message de service [i]IP_TOS [/i] est passé avec les paquets entrants. Il contient un octet qui décrit le champ Type-Of-Service/Précédence de l'en-tête du paquet. Il s'agit d'un drapeau entier booléen. [/col][/row][/table] [b]IP_RECVTTL[/b] [table][row][col] [/col][col]Passer un message de contrôle [i]IP_RECVTTL [/i] avec le champ Time-To-Live du paquet reçu comme argument sous forme d'octet. Non supporté pour les sockets [b]SOCK_STREAM .[/b] [/col][/row][/table] [b]IP_RECVOPTS[/b] [table][row][col] [/col][col]Passer à l'utilisateur toutes les options IP entrantes dans un message de contrôle [b]IP_OPTIONS .[/b] L'en-tête de routage et les autres options sont déjà remplies pour l'hôte local. Non supporté pour les sockets [b]SOCK_STREAM .[/b] [/col][/row][/table] [b]IP_RETOPTS[/b] [table][row][col] [/col][col]Comme [i]IP_RECVOPTS[/i] mais renvoie les options non traitées, avec les options d'horodatage et de routage non remplies pour ce saut (hop). [/col][/row][/table] [b]IP_TOS[/b] [table][row][col] [/col][col]Fixe ou consulte le champs Type-Of-Service (TOS) envoyé avec chaque paquet IP sortant de cette socket. Il sert à gérer sur le réseau les priorités entre paquets. TOS est un octet. Quelques attributs TOS standards sont définis : [b]IPTOS_LOWDELAY [/b] pour minimiser les délais en trafic interactif, [b]IPTOS_THROUGHPUT[/b] pour optimiser le débit, [b]IPTOS_RELIABILITY[/b] pour optimiser la fiabilité, [b]IPTOS_MINCOST[/b] doit être utilisé pour les données de remplissage, quand la lenteur de transmission importe peu. Une de ces valeurs TOS au maximum peut être indiquée. Les autres bits sont invalides et doivent être effacés. Linux envoie d'abord des datagrammes [b]IPTOS_LOWDELAY [/b] par défaut, mais le comportement exact dépend de la politique configurée pour la file d'attente. Quelques niveaux de haute priorité peuvent réclamer un UID effectif nul, ou la capacité [b]CAP_NET_ADMIN .[/b] La priorité peut aussi être indiquée d'une manière indépendante du protocole avec les options [b]( SOL_SOCKET, SO_PRIORITY )[/b] de [b]socket (7). [/b] [/col][/row][/table] [b]IP_TTL[/b] [table][row][col] [/col][col]Fixer ou consulter le contenu actuel du champ Time-To-Live envoyé avec chaque paquet sortant de cette socket. [/col][/row][/table] [b]IP_HDRINCL[/b] [table][row][col] [/col][col]L'utilisateur doit fournir un en-tête ip avant les données proprement dites. Uniquement valides pour les sockets [b]SOCK_RAW .[/b] Voir [b]raw (7)[/b] pour plus de détail. Lorsque cet attribut est activé, les valeurs fixées pour [b]IP_OPTIONS ,[/b] [i]IP_TTL[/i] et [i]IP_TOS[/i] sont ignorées. [/col][/row][/table] [b]IP_RECVERR (défini dans
)[/b] [table][row][col] [/col][col]Active le passage amélioré des messages d'erreur. Lorsque cet attribut est activé sur une socket datagramme, les erreurs seront mémorisées dans une file particulière pour la socket. Quand l'utilisateur détecte un échec d'une opération sur la socket, les erreurs peuvent être examinées en invoquant [b]recvmsg (2) [/b] avec l'attribut [b]MSG_ERRQUEUE . [/b] La structure [b]sock_extended_err [/b] décrivant l'erreur sera passé comme message de service ayant le type [i]IP_RECVERR [/i] et le niveau [b]SOL_IP .[/b] Ceci permet une gestion d'erreur fiable sur les sockets non connectées. La partie "données reçues" de la file d'erreurs contient le paquet ayant rencontré un problème. [/col][/row][/table] [table][row][col] [/col][col]Le message de contrôle [i]IP_RECVERR [/i] contient une structure [b]sock_extended_err :[/b][/col][/row][/table] [table][row][col] [/col][col] [table][row][col] [/col][col].ne 18 .nf .ta 4n 20n 32n #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 { u_int32_t ee_errno; /* numéro d'erreur */ u_int8_t ee_origin; /* origine de l'erreur */ u_int8_t ee_type; /* type */ u_int8_t ee_code; /* code */ u_int8_t ee_pad; u_int32_t ee_info; /* autres informations */ u_int32_t ee_data; /* autres données */ /* champs supplémentaires éventuels */ }; struct sockaddr *SOCK_EE_OFFENDER(struct sock_extended_err *); .ta .fi[/col][/row][/table][/col][/row][/table] [b]ee_errno [/b] [table][row][col] [/col][col]contient le numéro de l'erreur mise en file. [b]ee_origin[/b] est le code de l'origine de l'erreur. Les autres champs sont spécifiques au protocole. La macro [b]SOCK_EE_OFFENDER [/b] renvoie un pointeur sur l'adresse d'un objet réseau d'où l'erreur provient, en prenant en argument un pointeur sur le message de service. Si cette adresse n'est pas disponible, le membre [i]sa_family [/i] de la structure [b]sockaddr [/b] contient [b]AF_UNSPEC[/b] et les autres champs de [b]sockaddr [/b] sont indéfinis.[/col][/row][/table] [table][row][col] [/col][col]IP utilise la structure [b]sock_extended_err[/b] comme suit : [i]ee_origin [/i] contient [b]SO_EE_ORIGIN_ICMP [/b] pour les erreurs reçues sous forme de paquet ICMP, ou [b]SO_EE_ORIGIN_LOCAL [/b] pour les erreurs locales. Les valeurs inconnues doivent être ignorées. [i]ee_type [/i] et [i]ee_code [/i] sont remplis avec les champs type et code de l'en-tête ICMP. [i]ee_info[/i] contient le MTU déterminé pour les erreurs [b]EMSGSIZE .[/b] Le message contient aussi l'adresse [i]sockaddr_in[/i] du noeud ayant causé l'erreur, qui peut être obtenu avec la macro. [b]SOCK_EE_OFFENDER .[/b] Le champ [i]sin_family[/i] de l'adresse fournie par SOCK_EE_OFFENDER vaut [i]AF_UNSPEC[/i] si la source était inconnue. Lorsque les erreurs proviennent du réseau, toutes les options IP [i]( IP_OPTIONS , IP_TTL , [/i] etc.) valides pour la socket, et contenues dans le paquet en erreur sont transmises comme messages de contrôle. Le contenu original du paquet causant l'erreur est renvoyé comme charge normale. Notez que TCP n'a pas de file d'erreurs ; [b]MSG_ERRQUEUE[/b] est illégal sur les sockets [b]SOCK_STREAM .[/b] Ainsi, toutes les erreurs sont renvoyées par les fonctions sur les sockets ou par [b]SO_ERROR[/b] seulement. [/col][/row][/table] [table][row][col] [/col][col]Pour les sockets raw, [i]IP_RECVERR [/i] valide le passage de toutes les erreurs ICMP reçues à l'application, sinon les erreurs sont seulement renvoyées sur les sockets connectées. Il s'agit d'un attribut booléen entier. [i]IP_RECVERR[/i] est désactivé par défaut. [/col][/row][/table] [b]IP_PMTU_DISCOVER[/b] [table][row][col] [/col][col]Fixe ou consulte l'attribut de recherche du MTU du chemin (Path MTU - PMTU) pour une socket. Lorsqu'il est activé, Linux effectuer la recherche du MTU de chemin comme défini dans la RFC 1191. L'attribut interdisant la fragmentation est alors activé sur tous les datagrammes sortants. La valeur par défaut est commandée au niveau système par le sysctl [b]ip_no_pmtu_disc [/b] pour les sockets [b]SOCK_STREAM ,[/b] et désactivé pour toutes les autres. Pour les sockets autres que [b]SOCK_STREAM [/b] il est de la responsabilité de l'utilisateur d'empaqueter les données dans des blocs inférieurs au MTU et d'assurer la retransmission si besoin est. Le noyau rejettera les paquets qui sont plus gros que le MTU déterminé si cet attribut est activé (avec l'erreur [b]EMSGSIZE[/b] ). .TS tab(:); c l l l. 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. .TE 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 [b]connect (2),[/b] le MTU du chemin actuellement déterminé peut être consulté en utilisant l'option [b]IP_MTU [/b] de la socket (par exemple si une erreur [b]EMSGSIZE [/b] 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 [b]IP_RECVERR ).[/b] 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'en-tê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 [b]connect (2)[/b] et consultez le MTU en appelant [b]getsockopt (2)[/b] avec l'option [b]IP_MTU .[/b] [/col][/row][/table] [b]IP_MTU[/b] [table][row][col] [/col][col]Renvoie le MTU du chemin actuellement déterminé pour la socket. Seulement valide quand la socket a été connectée. Renvoie un entier. Uniquement valide pour un [b]getsockopt (2). [/b][/col][/row][/table] [b]IP_ROUTER_ALERT[/b] [table][row][col] [/col][col]Passer tous les futurs paquets redirigés (forwarded) avec l'option IP Router Alert activée sur cette socket. Uniquement valide pour les sockets raw. Ceci sert par exemple pour les démons RSVP de l'espace utilisateur. Les paquets enregistrés ne sont pas redirigés par le noyau, c'est la responsabilité de l'utilisateur de les renvoyer. L'attachement des sockets est ignoré, et de tels paquets ne sont filtrés que par le protocole. Il s'agit d'un attribut entier.[/col][/row][/table] [b]IP_MULTICAST_TTL[/b] [table][row][col] [/col][col]Fixe ou consulte la valeur du champs Time-To-Live des paquets multicast sortant sur cette socket. Il est très importants pour les paquets multicast de fixer le TTL le plus petit possible. La valeur par défaut est 1, ce qui signifie que les paquet multicast ne quittent pas le réseau local à moins que le programme de l'utilisateur ne le réclame explicitement. L'argument est un entier.[/col][/row][/table] [b]IP_MULTICAST_LOOP[/b] [table][row][col] [/col][col]Lit ou écrit un entier booléen indiquant si les paquets multicast doivent être renvoyés en boucle aux sockets locales concernées.[/col][/row][/table] [b]IP_ADD_MEMBERSHIP[/b] [table][row][col] [/col][col]Rejoindre un groupe multicast. L'argument est une structure [b]struct ip_mreqn .[/b][/col][/row][/table] [table][row][col] [/col][col] .nf .ta 4n 19n 34n 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 */ }; .fi[/col][/row][/table] [i]imr_multiaddr[/i] [table][row][col] [/col][col]contient l'adresse du groupe multicast que l'application veut rejoindre ou quitter. Il doit s'agir d'une adresse multicast valide. [i]imr_address[/i] est l'adresse de l'interface locale avec laquelle le système doit joindre le groupe multicast. Si elle est égale à [b]INADDR_ANY ,[/b] une interface appropriée est choisie par le système. [i]imr_ifindex[/i] est le numéro de l'interface pour rejoindre ou quitter le groupe [b]imr_multiaddr ,[/b] ou zéro pour indiquer n'importe quelle interface.[/col][/row][/table] [table][row][col] [/col][col]Pour la compatibilité, l'ancienne structure [b]ip_mreq[/b] est encore supportée. Elle diffère de [b]ip_mreqn [/b] seulement par l'absence du membre [b]imr_ifindex .[/b] Uniquement valide pour [b]setsockopt (2).[/b][/col][/row][/table] [b]IP_DROP_MEMBERSHIP[/b] [table][row][col] [/col][col]Quitter un groupe multicast. L'argument est une structure [b]ip_mreqn [/b] ou [b]ip_mreq [/b] comme pour [b]IP_ADD_MEMBERSHIP . [/b][/col][/row][/table] [b]IP_MULTICAST_IF[/b] [table][row][col] [/col][col]Fixer le périphérique local pour une socket multicast. L'argument est une structure [b]ip_mreqn [/b] ou [b]ip_mreq [/b] comme pour [b]IP_ADD_MEMBERSHIP .[/b][/col][/row][/table] [table][row][col] [/col][col]Lorsqu'une option de socket invalide est fournie, [b]ENOPROTOOPT[/b] est renvoyée.[/col][/row][/table] [size=18] [b]Sysctls[/b] [/size] Le protocole IP support l'interface sysctl pour configurer certaines options globales. Les sysctl peuvent être réalisés en lisant ou écrivant dans les fichiers [b]/proc/sys/net/ipv4/* [/b] ou en utilisant l'interface [b]sysctl (2).[/b] [b]ip_default_ttl [/b] [table][row][col] [/col][col]Fixe la valeur par défaut du champ Time-To-Live des paquets sortants. Ceci peut être modifié individuellement pour chaque socket avec l'option [b]IP_TTL .[/b][/col][/row][/table] [b]ip_forward[/b] [table][row][col] [/col][col]Active la redirection IP (forwarding) avec un attribut booléen. La redirection IP peut aussi être configurée interface par interface.[/col][/row][/table] [b]ip_dynaddr[/b] [table][row][col] [/col][col]Active la réécriture dynamique des adresses de socket et du masquerading lors des changements d'adresse d'interface. Cela sert pour les liaisons par modem, avec des adresses IP variables. 0 signifie aucune réécriture, 1 les autorise, et 2 demande un mode volubile.[/col][/row][/table] [b]ip_autoconfig[/b] [table][row][col] [/col][col]Non documenté.[/col][/row][/table] [b]ip_local_port_range[/b] [table][row][col] [/col][col]Contient deux entiers qui définissent l'intervalle par défaut des ports locaux alloués aux sockets. L'allocation démarre avec le premier numéro et se termine avec le second. Notez que cela ne doit pas entrer en conflit avec les ports utilisés pour le masquerading (bien que cela soit traité). De même des choix arbitraires peuvent poser des problèmes avec certains firewalls de filtrage par paquet qui font des suppositions sur les ports locaux utilisés. Le premier nombre doit être au moins supérieur à 1024 et de préférence à 4096 pour éviter les collisions avec les ports officiels et minimiser les problèmes de firewall.[/col][/row][/table] [b]ip_no_pmtu_disc[/b] [table][row][col] [/col][col]Désactiver la recherche par défaut des MTU par chemin pour les sockets TCP. La recherche du MTU par chemin peut échouer avec des firewalls mal configurés (qui rejettent tous les paquets ICMP) ou les interfaces mal configurées (par exemple lien point-à -point où les deux extrémités n'ont pas le même MTU). Il vaut mieux corriger le routeur défectueux que de supprimer globalement la recherche du MTU par chemin, car cette dernière option augmente les coûts du réseau.[/col][/row][/table] [b]ipfrag_high_thresh, ipfrag_low_thresh [/b] [table][row][col] [/col][col]Si le nombre de fragments IP en file atteint [b]ipfrag_high_thresh ,[/b] la file est restreinte à [b]ipfrag_low_thresh . [/b] Contient un entier avec le nombre d'octets.[/col][/row][/table] [b]ip_always_defrag[/b] [table][row][col] [/col][col][Nouveauté des noyaux 2.2.13, dans les noyaux précédents c'était une option de compilation nommée [b]CONFIG_IP_ALWAYS_DEFRAG ][/b] 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é.[/col][/row][/table] [b]neigh/*[/b] [table][row][col] [/col][col]voir [b]arp (7). [/b][/col][/row][/table] [size=18] [b]Ioctls[/b] [/size] Toutes les ioctls décrites dans [b]socket (7) [/b] s'appliquent à la couche IP. Les ioctls pour configurer les firewall sont documentés dans [b]ipfw (7)[/b] provenant du paquetage [b]ipchains .[/b] Les ioctls pour configurer les paramètres génériques des périphériques sont décrits dans [b]netdevice (7). [/b] [size=18] [b]Notes[/b] [/size] Soyez très prudents avec l'option [b]SO_BROADCAST ,[/b] elle n'est pas privilégiée sous Linux. Il est facile de surcharger un réseau avec des broadcast sans précaution. Pour les nouveaux protocoles applicatifs, il vaut mieux utiliser un groupe multicast plutôt que le broadcast. Ce dernier est déconseillé. Certaines autres implémentations des sockets BSD fournissent les options de socket [i]IP_RCVDSTADDR [/i] et [i]IP_RECVIF [/i] pour obtenir l'adresse de destination et l'interface des datagrammes reçus. Linux à l'option [i]IP_PKTINFO[/i] plus générale pour effectuer ce travail. [size=18] [b]Erreurs[/b] [/size] [b]ENOTCONN[/b] [table][row][col] [/col][col]L'opération n'est définie que pour une socket connectée, mais la socket ne l'était pas.[/col][/row][/table] [b]EINVAL[/b] [table][row][col] [/col][col]Un argument invalide a été transmis. Pour les émissions, cela peut être causé par un envoi vers une route [b]trou noir .[/b][/col][/row][/table] [b]EMSGSIZE [/b] [table][row][col] [/col][col]Datagramme plus grand que le MTU du chemin, et ne peut pas être fragmenté.[/col][/row][/table] [b]EACCES[/b] [table][row][col] [/col][col]L'utilisateur essaye de réaliser une opération sans avoir les permissions nécessaires. Cela inclut : L'envoi d'un paquet vers une adresse broadcast sans avoir activé l'attribut [b]SO_BROADCAST .[/b] L'envoi d'un paquet vers une route [b]interdite .[/b] Modification du paramétrage du firewall sans la capacité [b]CAP_NET_ADMIN[/b] ou un UID effectif nul. Attachement à un port réservé sans la capacité [b]CAP_NET_BIND_SERVICE[/b] ou un UID effectif nul. [/col][/row][/table] [b]EADDRINUSE[/b] [table][row][col] [/col][col]Tentative d'attachement à une adresse déjà utilisée.[/col][/row][/table] [b]ENOPROTOOPT et EOPNOTSUPP[/b] [table][row][col] [/col][col]Passage d'une option de socket invalide.[/col][/row][/table] [b]EPERM[/b] [table][row][col] [/col][col]L'utilisateur n'a pas la permission de fixer une priorité haute, de changer la configuration ou d'envoyer des signaux au groupe ou au processus demandé.[/col][/row][/table] [b]EADDRNOTAVAIL[/b] [table][row][col] [/col][col]Une interface inexistante ou une adresse source non locale ont été réclamées.[/col][/row][/table] [b]EAGAIN[/b] [table][row][col] [/col][col]L'opération sur une socket non-bloquante devrait bloquer.[/col][/row][/table] [b]ESOCKTNOSUPPORT[/b] [table][row][col] [/col][col]La socket n'est pas configurée ou on a demandé un type de socket inconnu.[/col][/row][/table] [b]EISCONN[/b] [b]connect (2)[/b] [table][row][col] [/col][col]a été appelé sur une socket déjà connectée.[/col][/row][/table] [b]EALREADY[/b] [table][row][col] [/col][col]Une opération de connexion est déjà en cours sur une socket non-bloquante.[/col][/row][/table] [b]ECONNABORTED[/b] [table][row][col] [/col][col]Une connexion a été fermée durant un [b]accept (2). [/b][/col][/row][/table] [b]EPIPE[/b] [table][row][col] [/col][col]La connexion a été fermée prématurément ou terminée par le correspondant.[/col][/row][/table] [b]ENOENT[/b] [b]SIOCGSTAMP [/b] [table][row][col] [/col][col]a été appelé sur une socket sans qu'aucun paquet n'y soit disponible.[/col][/row][/table] [b]EHOSTUNREACH[/b] [table][row][col] [/col][col]Aucune route valide dans la table ne correspond à l'adresse de destination. Cette erreur peut être due à un message ICMP d'un routeur distant ou à la table de routage interne.[/col][/row][/table] [b]ENODEV [/b] [table][row][col] [/col][col]Le périphérique réseau n'est pas disponible ou est incapable d'envoyer de l'IP.[/col][/row][/table] [b]ENOPKG [/b] [table][row][col] [/col][col]Un sous-système du noyau n'est pas configuré.[/col][/row][/table] [b]ENOBUFS, ENOMEM[/b] [table][row][col] [/col][col]Pas assez de mémoire. Cela signifie souvent que l'allocation mémoire est contrainte par les limites du buffer de socket, pas par la mémoire système, mais ce n'est pas toujours sûr.[/col][/row][/table] D'autres erreurs peuvent être déclenchées par les protocoles supérieurs. Voir [b]tcp (7),[/b] [b]raw (7),[/b] [b]udp (7)[/b] et [b]socket (7).[/b] [size=18] [b]Versions[/b] [/size] [b]IP_PKTINFO , [/b] [b]IP_MTU , [/b] [b]IP_PMTU_DISCOVER , [/b] [b]IP_PKTINFO , [/b] [b]IP_RECVERR[/b] et [b]IP_ROUTER_ALERT[/b] sont de nouvelles options de Linux 2.2. Elles sont aussi spécifiques à Linux et ne doivent pas servir dans des programmes destinés à être portables. [b]struct ip_mreqn [/b] est nouvelle dans Linux 2.2. Sous Linux 2.0, seule existait [b]ip_mreq .[/b] Les sysctls ont été introduits avec Linux 2.2. [size=18] [b]Compatibilité[/b] [/size] Pour la compatibilité avec Linux 2.0, la syntaxe obsolète [b][i]socket(PF_INET, SOCK_RAW, protocole )[/i][/b] est encore supportée pour ouvrir une socket [b]packet (7).[/b] Cela est déconseillé, et doit être remplacé par un [b][i]socket(PF_PACKET, SOCK_RAW, protocole )[/i][/b] La principale différence est la nouvelle structure d'adresse [b]sockaddr_ll [/b] pour les informations génériques du niveau liaison à la place de l'ancienne [b]sockaddr_pkt .[/b] [size=18] [b]Bugs[/b] [/size] Il y a trop de valeurs d'erreurs hétérogènes. Les ioctls pour configurer les options d'interface spécifiques IP et les tables ARP ne sont pas décrites. Certaines version de la GlibC oublient la déclaration [i]in_pktinfo.[/i] 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 [b]MSG_ERRQUEUE[/b] dans [i]msg_name[/i] par [b]recvmsg (2)[/b] ne fonctionne pas dans certains noyaux 2.2. [size=18] [b]Auteurs[/b] [/size] Cette page de manuel a été écrite par Andi Kleen. [size=18] [b]Voir aussi[/b] [/size] [b]sendmsg (2),[/b] [b]recvmsg (2),[/b] [b]socket (7),[/b] [b]netlink (7),[/b] [b]tcp (7),[/b] [b]udp (7),[/b] [b]raw (7),[/b] [b]ipfw (7).[/b] RFC 791 pour les spécifications IP d'origine. [b][/b] RFC 1122 pour les nécessités IPv4 des hôtes. [b][/b] RFC 1812 pour les nécessités IPv4 des routeurs. [size=18] [b]Traduction[/b] [/size] Christophe Blaess, 2001-2003.
Fichier
Forum
-
Derniers messages
Bavardages
Aujourd'hui, je rénove ou je construis ^^
Software
problème sur windows 10
Réseaux et Télécom
Administrateur Réseau - Cisco
Réseaux et Télécom
Problème wifi (POE)
Software
Postfix - Need help
Bavardages
Oh râge oh désespoir !
Programmation
Enregistrement client et envoi mail
Software
SÉCURITÉ MACBOOK
Hardware
conseil matos réseau?
Hardware
nVidia Shield Android TV
Actualités
-
Archives
Windows
Windows 11 : le menu Démarrer ne fonctionne parfois plus après la mise à jour
Jeux Vidéos
Test Legacy of Kain Soul Reaver 1&2 Remastered (PS5) - Raziel de retour
Tablettes
2025 nous apportera le nouvel iPad abordable : nouveaux détails de lancement
Google
Découvrons quand le Père Noël arrivera pour livrer nos cadeaux, avec Santa Tracker de Google
Consoles
Nintendo Switch 2, la date d'annonce et le mois de sortie ont-ils été révélés par un leaker ?
Ada
CSS
Cobol
CPP
HTML
Fortran
Java
JavaScript
Pascal
Perl
PHP
Python
SQL
VB
XML
Anon URL
DailyMotion
eBay
Flickr
FLV
Google Video
Google Maps
Metacafe
MP3
SeeqPod
Veoh
Yahoo Video
YouTube
6px
8px
10px
12px
14px
16px
18px
Informaticien.be
- © 2002-2024
Akretio
SPRL - Generated via
Kelare
The Akretio Network:
Akretio
-
Freedelity
-
KelCommerce
-
Votre publicité sur informaticien.be ?