NOMBRE¶

SINOPSIS¶

DESCRIPCIÓN¶

FORMATO DE LAS DIRECCIONES¶

struct sockaddr_in {
	sa_family_t	sin_family;	/* familia de direcciones:
			   AF_INET */
	u_int16_t	sin_port;	/* puerto con los bytes en el
			   orden de red */
	struct in_addr  sin_addr;	/* dirección de Internet */
};

/* Dirección de Internet. */
struct in_addr {
	u_int32_t	s_addr;	/* dirección con los bytes en
			   el orden de red */
};

OPCIONES DE LOS CONECTORES¶

IP_OPTIONS

Establece u obtiene las opciones IP a enviar con cada paquete desde este conector. Los argumentos son punteros a un buffer de memoria que contiene las opciones y la longitud de las opciones. La llamada setsockopt(2) establece las opciones IP asociadas a un conector. El tamaño máximo de opción para IPv4 es de 40 bytes. Vea RFC791 para las opciones permitidas. Cuando el paquete inicial de petición de conexión para un conector SOCK_STREAM contiene opciones IP, las opciones IP se configurarán automáticamente al valor de las opciónes del paquete inicial con las cabeceras de enrutamiento invertidas. No se permite que los paquetes de entrada cambien las opciones después de que la conexión se haya establecido. El procesamiento de todas las opciones de enrutamiento de la fuente de entrada está desactivado por defecto y se puede activar usando la sysctl accept_source_route. Otras opciones, como las marcas de tiempo, todavía se siguen manejando. Para los conectores de datagramas, las opciones IP sólo pueden ser configuradas por el usuario local. Llamar a getsockopt(2) con IP_OPTIONS coloca en el buffer proporcionado las opciones IP actuales usadas para enviar.

IP_PKTINFO

Pasa un mensaje auxiliar IP_PKTINFO que contiene una estructura pktinfo que proporciona alguna información sobre los paquetes de entrada. Esto sólo funciona para conectores orientados a datagramas. El argumento es un indicador que le dice al conector si debería pasar el mensaje IP_PKTINFO. El mensaje en sí mismo sólo puede ser enviado/obtenido como un mensaje de control con un paquete usando recvmsg(2) o sendmsg(2).

struct in_pktinfo {
	unsigned int	ipi_ifindex; 	/* Índice de la interfaz */
	struct in_addr	ipi_spec_dst;	/* Dirección local */
	struct in_addr	ipi_addr;	/* Dirección de destino en la
			   cabecera */
};

ipi_ifindex es el índice de la interfaz en la que se recibió el paquete. ipi_spec_dst es la dirección local del paquete y ipi_addr es la dirección de destino en la cabecera del paquete. Si se pasa IP_PKTINFO a sendmsg(2), el paquete de salida se enviará a través de la interfaz especificada en ipi_ifindex con la dirección de destino indicada en ipi_spec_dst.

IP_RECVTOS

Cuando está activa, se pasa el mensaje auxiliar IP_TOS con los paquetes de entrada. Contiene un byte que especifica el campo Tipo de Servicio/Precedencia de la cabecera del paquete. Espera una opción entera booleana.

IP_RECVTTL

Cuando esta opción está activa, pasa un mensaje de control IP_RECVTTL con el campo "tiempo de vida" (time to live) del paquete recibido dado por un byte. No soportada por conectores SOCK_STREAM.

IP_RECVOPTS

Pasa todas las opciones IP de entrada al usuario en un mensaje de control IP_OPTIONS. La cabecera de enrutamiento y otras opciones ya las completa el anfitrión local. No soportada para conectores SOCK_STREAM.

IP_RETOPTS

Identica a IP_RECVOPTS pero devuelve opciones directas sin procesar cuyas marcas de tiempo y opciones del registro de ruta no son completadas por este anfitrión.

IP_TOS

Establece o devuelve el campo Tipo de Servicio (Type-Of-Service, TOS) a enviar con cada paquete IP creado desde este conector. Se usa para priorizar los paquetes en la red. TOS es un byte. Existen algunas opciones TOS estándares definidas: IPTOS_LOWDELAY para minizar los retrasos en el caso de tráfico interactivo, IPTOS_THROUGHPUT para optimizar el rendimiento, IPTOS_RELIABILITY para optimizar la fiabilidad e IPTOS_MINCOST, que se debería usar para "datos de relleno" donde no tenga sentido una transmisión lenta. Como mucho, se puede especificar uno de estos valores TOS. Los otros bits son inválidos y se limpiarán. Por defecto, Linux envía primero datagramas IPTOS_LOWDELAY pero el comportamiento exacto depende de la disciplina de encolamiento configurada. Algunos niveles de prioridad alta pueden necesitar un identificador de usuario efectivo 0 o la capacidad CAP_NET_ADMIN. La prioridad también se puede configurar de una manera independiente del protocolo mediante la opción de conector ( SOL_SOCKET, SO_PRIORITY) (vea socket(7)).

IP_TTL

Establece u obtiene el campo "tiempo de vida" actual que se envía en cada paquete enviado desde este conector.

IP_HDRINCL

Cuando está activa, el usuario proporciona una cabecera IP delante de los datos de usuario. Sólo válida para conectores SOCK_RAW. Vea raw(7) para más información. Cuando esta opción está activa los valores configurados mediante IP_OPTIONS, IP_TTL y IP_TOS se ignoran.

IP_RECVERR (definido en <linux/errqueue.h>)

Habilita el paso adicional fiable de mensajes de error. Cuando se activa en un conector de datagramas todos los errores generados se encolarán en una cola de errores por conector. Cuando el usuario recibe un errore procedente de una operación con un conector, se pueden recibir el errore llamando a recvmsg(2) con la opción MSG_ERRQUEUE activa. La estructura sock_extended_err que describe el error se pasará en un mensaje auxiliar con el tipo IP_RECVERR y el nivel SOL_IP. Esto es útil para el manejo fiable de errores en conectores no conectados. La parte de datos recibida de la cola de errores contiene el paquete de error.

El mensaje de control IP_RECVERR contiene una estructura sock_extended_err:

#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;	/* número de error */
	u_int8_t	ee_origin;	/* dónde se originó el error */ 
	u_int8_t	ee_type;	/* tipo */
	u_int8_t	ee_code;	/* código */
	u_int8_t	ee_pad;
	u_int32_t	ee_info;	/* información adicional */
	u_int32_t	ee_data;	/* otros datos */  
	/* More data may follow */ 
};

struct sockaddr *SO_EE_OFFENDER(struct sock_extended_err *);

ee_errno contiene el número de error del error puesto en cola. ee_origin es el código de origen que identifica al origen del error. Los otros campos son específicos del protocolo. La macro SO_EE_OFFENDER devuelve un puntero a la dirección del objeto de red dónde se originó el error dado un puntero al mensaje auxiliar. Si la dirección no es conocida, el miembro sa_family de sockaddr valdrá AF_UNSPEC y los otros campos de sockaddr serán indefinidos.

IP usa la estructura sock_extended_err como sigue: a ee_origin se le asigna el valor SO_EE_ORIGIN_ICMP para errores recibidos en un paquete ICMP o SO_EE_ORIGIN_LOCAL para errores generados localmente. Los valores desconocidos deben ser ignorados. A ee_type y ee_code se les asignan los campos tipo y código de la cabecera ICMP. ee_info contiene la MTU descubierta para errores EMSGSIZE. El mensaje contiene también la estructura sockaddr_in del nodo que provocó el error, a la cual se puede acceder con la macro SO_EE_OFFENDER. El campo sin_family de la dirección devuelta por SO_EE_OFFENDER valdrá AF_UNSPEC cuando la fuente sea desconocida. Cuando el error se originó en la red, todas las opciones IP (IP_OPTIONS, IP_TTL, etc.) activas en el conector y contenidas en el paquete de error, se pasan como mensajes de control. El contenido útil del paquete que ha provocado el error se devuelve como datos normales.

Dese cuenta que TCP no posee una cola de errores. MSG_ERRQUEUE es ilegal en conectores SOCK_STREAM. Por tanto, todos los errores son devueltos sólo por funciones de conector o mediante SO_ERROR.

Para conectores directos (raw), IP_RECVERR activa el paso de todos los errores ICMP recibidos a la aplicación. En otro caso, sólo se informa de los errores que se producen en conectores conectados.

Esta opción establece u obtiene un valor booleano entero. Por defecto, IP_RECVERR está desactivada.

IP_PMTU_DISCOVER

Establece o recibe la configuración del "descubrimiento de la MTU de la ruta" para el conector. Cuando se activa, Linux realizará el descubrimiento de la MTU de la ruta en este conector tal y como se define en RFC1191. La opción de "no fragmentar" se activa en todos los datagramas de salida. El valor global por defecto del sistema se controla mediante la sysctl ip_no_pmtu_disc para los conectores SOCK_STREAM y para todos los demás está desactivado. Para conectores que no son SOCK_STREAM es responsabilidad del usuario enpaquetar los datos en trozos de tamaño MTU y realizar la retransmisión si es necesario. El núcleo rechazará aquellos paquetes que sean más grandes que la MTU de ruta conocida si esta opción está activa (con EMSGSIZE ).

Opciones del descubrimiento de la MTU de la ruta	Significado
IP_PMTUDISC_WANT	Usar configuraciones por ruta.
IP_PMTUDISC_DONT	Nunca realizar el descubrimiento de la MTU de la ruta.
IP_PMTUDISC_DO	Realizar siempre el descubrimiento de la MTU de la ruta.

Cuando se activa el descubrimiento de la MTU de la ruta, el núcleo automáticamente memoriza la MTU de la ruta por anfitrión de destino. Cuando se está conectado a un extremo específico mediante connect(2), se puede obtener convenientemente la MTU de la ruta conocida actualmente usando la opción de conector IP_MTU (por ejemplo, después de que haya ocurrido un error EMSGSIZE). La MTU puede cambiar con el tiempo. Para conectores no orientados a conexión con muchos destinos, también se puede acceder a la nueva MTU usando la cola de errores (vea IP_RECVERR). Se encolará un nuevo error para cada actualización que llegue de la MTU.

Mientras se está realizando el descubrimiento de la MTU, se pueden perder paquetes iniciales de los conectores de datagramas. Las aplicaciones que usan UDP deben se conscientes de esto y no tenerlo en cuenta para sus estrategias de retransmisión de paquetes.

Para iniciar el proceso de descubrimiento de la MTU de la ruta en conectores no orientados a conexión, es posible comenzar con un tamaño grande de datagramas (con logitudes de bytes de hasta 64KB en las cabeceras) y dejar que se reduzca mediante actualizaciones de la MTU de la ruta.

Para obtener una estimación inicial de la MTU de la ruta, conecte un conector de datagramas a una dirección de destino usando connect(2) y obtenga la MTU llamando a getsockopt(2) con la opción IP_MTU.

IP_MTU

Obtiene la MTU de la ruta conocida actualmente para el conector actual. Sólo válida cuando el conector ha sido conectado. Devuelve un entero. Sólo válida para getsockopt(2).

IP_ROUTER_ALERT

Pasar a este conector todos los paquetes "a reenviar" que tengan activa la opción "alarma del enrutador IP" (IP Router Alert). Sólo válida para conectores directos. Esto es útil, por ejemplo, para demonios RSVP en el espacio de usuario. Los paquetes interceptados no son reenviados por el núcleo, es responsabilidad de los usuarios envilarlos de nuevo. Se ignora el enlace del conector, tales paquetes sólo son filtrados por el protocolo. Espera una opción entera.

IP_MULTICAST_TTL

Establece o lee el valor "tiempo de vida" (time-to-live, TTL) de los paquetes multidestino de salida para este conector. Es muy importante para los paquetes multidestino utilizar el TTL más pequeño posible. El valor por defecto es 1 lo que significa que los paquetes multidestino no abandonarán la red local a menos que el programa de usuario lo solicite explícitamente. El argumento es un entero.

IP_MULTICAST_LOOP

Establece o lee un argumento entero booleano que indica si los paquetes multidestino enviados deben o no ser devueltos a los conectores locales.

IP_ADD_MEMBERSHIP

Unirse a un grupo multidestino. El argumento es una estructura struct ip_mreqn.

struct ip_mreqn {
	struct in_addr	imr_multiaddr;	/* Dirección IP del grupo
			   multidestino */
	struct in_addr	imr_address;	/* Dirección IP de la
			   interfaz local */
	int	imr_ifindex;	/* Índice de la interfaz */
};

imr_multiaddr contiene la dirección del grupo multidestino al que la aplicación se quiere unir o quiere dejar. Debe ser una dirección multidestino válida. imr_address es la dirección de la interfaz local con la que el sistema debe unirse al grupo multidestino. Si es igual a INADDR_ANY el sistema elige una interfaz adecuada. imr_ifindex es el índice de la interfaz que debe unirse a o dejar el grupo imr_multiaddr, o 0 para indicar cualquier interfaz.

Por compatibilidad, todavía se soporta la antigua estructura ip_mreq. Difiere de ip_mreqn sólo en que no incluye el campo imr_ifindex. Ésta opción sólo es válida para setsockopt(2).

IP_DROP_MEMBERSHIP

Dejar un grupo multidestino. El argumento es una estructura ip_mreqn o ip_mreq similar a la de IP_ADD_MEMBERSHIP.

IP_MULTICAST_IF

Establece el dispositivo local para un conector multidestino. El argumento es una estructura ip_mreqn o ip_mreq similar a la de IP_ADD_MEMBERSHIP.

Cuando se pasa una opción de conector inválida, se devuelve el error ENOPROTOOPT.

SYSCTLS¶

ip_default_ttl

Establece el valor "tiempo de vida" (TTL) por defecto de los paquetes de salida. Éste se puede cambiar para cada conector con la opción IP_TTL.

ip_forward

Activa el reenvío IP con una opción booleana. También se puede configurar el reenvío IP interfaz a interfaz.

ip_dynaddr

Activa la reescritura dinámica de la dirección del conector y de las entradas de enmascaramiento (masquerading) para cuando cambie la dirección de la interfaz. Esto es útil para interfaces dialup (como las telefónicas) con direcciones IP cambiantes. 0 significa no reescritura, 1 la activa y 2 activa el modo verboso.

ip_autoconfig

No documentado.

ip_local_port_range

Contiene dos enteros que definen el intervalo de puertos locales por defecto reservados para los conectores. La reserva comienza con el primer número y termina con el segundo. Dése cuenta que estos no deben entrar en conflicto con los puertos usados por el enmascaramiento (aunque se trate el caso). También, las elecciones arbitrarias pueden producir problemas con algunos filtros de paquetes del cortafuegos que realizan suposiciones sobre los puertos locales en uso. El primer número debe ser al menos >1024, mejor >4096 para evitar conflictos con puertos bien conocidos y para minimizar los problemas con el cortafuegos.

ip_no_pmtu_disc

Si está activa, por defecto no realiza el descubrimiento de la MTU de la ruta para los conectores TCP. El descubrimiento de la MTU de la ruta puede fallar si se encuentran en la ruta cortafuegos mal configurados (como los que pierden todos los paquetes ICMP) o interfaces mal configuradas (por ejemplo, un enlace punto a punto en donde ambos extremos no se ponen de acuerdo en la MTU). Es mejor arreglar los enrutadores defectuosos de la ruta que desactivar globalmente el descubrimiento de la MTU de la ruta ya que el no realizarlo incurre en un alto coste para la red.

ipfrag_high_thresh, ipfrag_low_thresh

Si el número de fragmentos IP encolados alcanza el valor ipfrag_high_thresh, la cola se recorta al valor ipfrag_low_thresh. Contiene un entero con el número de bytes.

ip_always_defrag

[Nueva con la versión 2.2.13 del núcleo. En anteriores versiones del núcleo la característica era controlada en tiempo de compilación por la opción CONFIG_IP_ALWAYS_DEFRAG]

Cuanda esta opción booleana se habilita (es distinta de 0) los fragmentos de entrada (partes de paquetes IP que aparecen cuando algún anfitrión entre el origen y el destino decidió que los paquetes eran demasiado grandes y los dividió en pedazos) se reensamblarán (desfragmentarán) antes de ser procesados, incluso aunque vayan a ser reenviados.

Sólo habilítelo cuando tenga en funcionamiento un cortafuegos que sea el único enlace de su red o un proxy transparente. Nunca lo active para un enrutador u ordenador normal. En otro caso, se puede perturbar la comunicación fragmentada cuando los fragmentos viajen a través de diferentes enlaces. La desfragmentación también tiene un alto coste de tiempo de CPU y de memoria.

Esto se activa automágicamente cuando se configura un enmascaramiento o un proxy transparente.

neigh/*

Vea arp(7).

IOCTLS¶

OBSERVACIONES¶

ERRORES¶

ENOTCONN

La operación sólo está definida en conectores conectados, pero el conector no lo está.

EINVAL

Se ha pasado un argumento inválido. Para las operaciones de envío, éste se puede producir al enviar a una ruta blackhole.

EMSGSIZE

El datagrama es mayor que una MTU de la ruta y no puede ser fragmentado.

EACCES

El usuario ha intentado ejecutar una operación sin los permisos necesarios. Estos incluyen: enviar un paquete a una dirección de difusión sin haber activado la opción SO_BROADCAST, enviar un paquete a través de una ruta prohibida, modificar la configuración del cortafuegos sin tener la capacidad CAP_NET_ADMIN ni un identificador de usuario efectivo 0, y realizar un enlace a un puerto reservado sin la capacidad CAP_NET_BIND_SERVICE ni un identificador de usuario efectivo 0.

EADDRINUSE

Se ha intentado el enlace a una dirección ya en uso.

ENOPROTOOPT y EOPNOTSUPP

Se han pasado una opción de conector inválida.

EPERM

El usuario no tiene permiso para establecer una prioridad alta, cambiar la configuración o enviar señales al proceso o grupo solicitado.

EADDRNOTAVAIL

Se ha solicitado una interfaz inexistente o la dirección fuente solicitada no es local.

EAGAIN

La operación se bloquearía en un conector bloqueante.

ESOCKTNOSUPPORT

El conector no está configurado o se ha solicitado un tipo de conector desconocido.

EISCONN

Se ha llamado a connect(2) con un conector ya conectado.

EALREADY

Ya se está realizando una operación de conexión sobre un conector no bloqueante.

ECONNABORTED

Se ha cerrado la conexión durante un accept(2).

EPIPE

La conexión se ha cerrado inesperadamente o el otro extremo la ha cancelado.

ENOENT

Se ha llamado a SIOCGSTAMP con un conector en donde no ha llegado ningún paquete.

EHOSTUNREACH

Ninguna entrada válida de la tabla de enrutamiento coincide con la dirección de destino. Este error puede ser provocado por un mensaje ICMP procedente de un enrutador remoto o por la tabla local de enrutamiento.

ENODEV

Dispositivo de red no disponible o incapaz de enviar paquetes IP.

ENOPKG

No se ha configurado un subsistema del núcleo.

ENOBUFS, ENOMEM

No hay suficiente memoria libre. Esto a menudo significa que la reserva de memoria está limitada por los límites del búfer de conectores, no por la memoria del sistema, aunque esto no es coherente al 100%.

VERSIONES¶

COMPATIBILIDAD¶

FALLOS¶

AUTORES¶

VÉASE TAMBIÉN¶