Provided by: manpages-pt_20040726-4_all bug

NOME

       ip - Implementação do protocolo IPv4 em Linux

SINOPSE

       #include <sys/socket.h>
       #include <net/netinet.h>

       tcp_socket = socket(PF_INET, SOCK_STREAM, 0);
       raw_socket = socket(PF_INET, SOCK_RAW, protocol);
       udp_socket = socket(PF_INET, SOCK_DGRAM, protocol);

DESCRIÇÃO

       Linux  implementa  o  Protocolo  Internet  (IP), versão 4, descrito nas
       RFC791 e RFC1122.  ip contém uma implementação de multicasting de nível
       2,  conforme a RFC1112.  Ele também contém um roteador IP que inclui um
       filtro de pacotes.

       A interface do programador é compatível com sockets BSD.  Para  maiores
       informações sobre sockets, veja socket(7).

       Um  socket  IP  é  criado  ao  se  chamar a função socket(2) no formato
       socket(PF_INET, socket_type, protocol).  Tipos válidos de  sockets  são
       SOCK_STREAM  para  abrir  um  socket  tcp(7) , SOCK_DGRAM para abrir um
       socket udp(7) , ou SOCK_RAW para abrir um socket raw(7) para acessar  o
       protocolo IP protocol diretamente.  protocol é o protocolo IP no header
       IP a ser recebido ou enviado. Os únicos valores válidos  para  protocol
       são  0  e  IPPROTO_TCP para sockets TCP, e 0 e IPPROTO_UDP para sockets
       UDP. Para SOCK_RAW Você deve especificar um protocolo IP  IANA  válido,
       definido nos números atribuídos na RFC1700.

       Quando  um  processo quer receber novos pacotes ou conexões de entrada,
       ele deveria ligar um socket a um endereço local  de  interface,  usando
       bind(2).   Somente  um  socket  IP  pode  ser  ligado  a  qualquer  par
       (endereço, porta) local dado.   Quando  INADDR_ANY  é  especificado  na
       chamada  ’bind’  ,  o  socket será ligado a todas as interfaces locais.
       Quando listen(2) ou connect(2) são chamados sobre um socket não ligado,
       o  socket  é automaticalmente ligado a uma porta livre aleatória, com o
       endereço local setado em INADDR_ANY.

       Um endereço de socket TCP local que tenha sido  ligado  é  indisponível
       por  algum  tempo depois do fechamento, a menos que o flag SO_REUSEADDR
       tenha sido setado. Deve-se tomar cuidado quando se usa este flag,  pois
       ele torna o TCP menos reliable.

FORMATO DE ENDEREÇO

       Um  endereço de socket IP é definido como uma combinação de um endereço
       de interface IP e um número de porta. O protocolo IP básico não suporta
       número  de  portas, elas são implementadas por protocolos de nível mais
       alto, como udp(7) e tcp(7).  Em sockets diretos, sin_port é setado para
       o protocolo IP.

              struct sockaddr_in {
                 sa_family_t   sin_family; /* família de endereço: AF_INET */
                 u_int16_t     sin_port;   /* porta na ordem de byte da rede */
                 struct in_addr  sin_addr; /* endereço internet */
              };

              /* Endereço internet. */
              struct in_addr {
                 u_int32_t     s_addr;     /* endereço na ordem de byte da rede */
              };

       sin_family  é  sempre  selecionado  para AF_INET.  Este é requerido; em
       Linux  2.2,  muitas  funções  de  rede  retornam  EINVAL  quando   esta
       configuração  está  faltando.  sin_port contém a porta em ordem de byte
       da rede. Os números de porta abaixo de  1024  são  chamados  de  portas
       reservadas.   Somente  processos  com  id  efetivo  de  usuário  0 ou a
       capabilidade CAP_NET_BIND_SERVICE podem fazer o bind(2) nesses sockets.
       Note  que o protocolo IPv4 direto, como tal, não possui nenhum conceito
       de porta, elas somente são  implementadas  por  protocolos  superiores,
       como o tcp(7) e o udp(7).

       sin_addr  é  o  endereço  IP  do host.  O membro addr de struct in_addr
       contém o endereço de interface do host na ordem de  rede.   in_addr  só
       deveria  ser  acessada usando-se as funções de biblioteca inet_aton(3),
       inet_addr(3), inet_makeaddr(3) , ou diretamente  com  o  resolvedor  de
       nomes  (veja  gethostbyname(3)).   Os  endereços  IPv4 são divididos em
       unicast, broadcast e multicast. Endereços de  unicast  especificam  uma
       interface única de um host, endereços de broadcast especificam todos os
       hosts de uma rede, e endereços de multicast endereçam todos os hosts em
       um grupo de multicast. Datagramas dirigidos a endereços de broadcast só
       podem ser  enviados  ou  recebidos  quando  um  sinalizador  de  socket
       SO_BROADCAST  está  selecionado.   Na  implementação  corrente, sockets
       orientados a conexão somente  têm  permissão  para  usar  endereços  de
       unicast.

       Note  que o endereço e a porta são sempre armazenados na ordem da rede.
       Em particular, isto significa que você precisa chamar htons(3) sobre  o
       número  que é atribuído a uma porta. Todas as funções de manipulação de
       endereço/porta na biblioteca padrão funcionam na ordem da rede.

       Há vários endereços especiais: INADDR_LOOPBACK  (127.0.0.1)  sempre  se
       refere  ao host local via dispositivo de loopback; INADDR_ANY (0.0.0.0)
       significa   qualquer   endereço    para    conexão;    INADDR_BROADCAST
       (255.255.255.255)  significa qualquer host e tem o mesmo efeito, em uma
       conexão, que o INADDR_ANY por razões históricas.

OPÇÕES DE SOCKETS

       O IP suporta algumas opções de socket  específicos  de  protocolo,  que
       podem  ser  selecionado com setsockopt(2) e lidas com getsockopt(2).  O
       nível de opção de socket para IP é SOL_IP.  Um sinalizador inteiro para
       booleano é zero quando é falso, e em caso contrário é verdadeiro.

       IP_OPTIONS
              Seta  ou  obtém as opções de IP a serem enviadas com cada pacote
              deste socket.  Os argumentos são um ponteiro para um  buffer  de
              memória  que  contém  as  opções,  e  o comprimento da opção.  A
              chamada setsockopt(2) seta as opções  de  IP  associadas  com  o
              socket.   O  máximo  tamanho  de  opção  para  IPv4  é 40 bytes.
              Consulte RFC791 para ver as opções permitidas. Quando  o  pacote
              inicial  de  requisição  de  conexão  para um socket SOCK_STREAM
              contém  opções  de  IP,  as   opções   de   IP   serão   setadas
              automaticamente para as opções do pacote inicial, com os headers
              de roteamento revertido.  Pacotes entrantes não têm permissão de
              mudar   opções   depois   que   a  conexão  é  estabelecida.   O
              processamento de todas as  opções  entrantes  de  roteamento  da
              fonte é desabilitada por default, e pode ser habilitada pelo uso
              do sysctl accept_source_route Para  sockets  de  datagramas,  as
              opções de IP só podem ser setadas pelo usuário local.  Chamando-
              se  getsockopt(2)  com  IP_OPTIONS  põe-se  as  opções   de   IP
              correntes, usadas para envio, no buffer fornecido.

       IP_PKTINFO
              Passa  uma  mensagem ancilar IP_PKTINFO que contém uma estrutura
              pktinfo  ,  que  fornece  algumas  informações  sobre  o  pacote
              entrante. Isto só funciona para sockets orientados a datagramas.

              struct in_pktinfo
              {
                  unsigned int   ipi_ifindex;  /* índice da interface  */
                  struct in_addr ipi_spec_dst; /* endereço de destino do roteamento */
                  struct in_addr ipi_addr;     /* endereço do Destino do Header */
              };

              ipi_ifindex é o único índice da  interface  onde  o  pacote  foi
              recebido.   ipi_spec_dst  é  o endereço de destino da entrada da
              tabela de roteamento e ipi_addr  é  o  endereço  de  destino  no
              cabeçalho  do  pacote.   Se IP_PKTINFO é passado para sendmsg(2)
              então  o  pacote  de  saída  será  enviado  sobre  a   interface
              especificada  em  ipi_ifindex , com o endereço de destino setado
              em ipi_spec_dst.

       IP_RECVTOS
              Se habilitado, a mensagem ancilar IP_TOS é passada  com  pacotes
              entrantes.  Ele  contém  um byte que especifica o campo "Tipo de
              Serviço/Precedência" do cabeçalho  do  pacote.  Espera  um  flag
              booleano inteiro.

       IP_RECVTTL
              Quando  este  flag  é  setado,  passa  uma  mensagem de controle
              IP_RECVTTL com o campo "time to live" do pacote recebido como um
              byte.  Não é suportado para sockets SOCK_STREAM

       IP_RECVOPTS
              Passa  todas  as  opções  de  IP entrantes para o usuário em uma
              mensagem de controle  IP_OPTIONS.   O  header  de  roteamento  e
              outras  opções  já  são  preenchidas  para  o host local.  Não é
              suportado para sockets SOCK_STREAM

       IP_RETOPTS
              Idêntico  a  IP_RECVOPTS  ,  mas  retorna  opções  diretas   não
              processadas,  com  opções  de  timestamp  e registro de rota não
              preenchidos para este hop.

       IP_TOS Seleciona ou recebe o campo Tipo-de-Serviço  (Tipo-Of-Service  -
              TOS),  que  é  enviado  com todos os pacotes IP originados deste
              socket. Ele é usado para priorizar pacotes na rede.   TOS  é  um
              byte.  Há  alguns padrões de flags TOS definidos: IPTOS_LOWDELAY
              para minimizar delays para tráfego interativo,  IPTOS_THROUGHPUT
              para   otimizar  o  fluxo,  IPTOS_RELIABILITY  para  otimizar  a
              reliability,  IPTOS_MINCOST  deveria  ser   usado   como   "dado
              preenchedor"  onde transmissões lentas não causam problemas.  No
              máximo um desses valores de TOS podem ser especificados.  Outros
              bits  são  inválidos  e  serão  zerados.  Linux envia datagramas
              IPTOS_LOWDELAY primeiro por default, mas o  comportamento  exato
              depende  da  disciplina  de  fila configurada.  Alguns níveis de
              alta prioridade podem requerer um id efetivo de usuário 0  ou  a
              capabilidade CAP_NET_ADMIN.  A prioridade também pode ser setada
              de maneira independente de protocolo, pela  opção  de  socket  (
              SOL_SOCKET, SO_PRIORITY ) (veja socket(7) ).

       IP_TTL Seta  ou recupera o campo "time to live" corrente, que é enviado
              em todos os pacotes originados neste socket.

       IP_HDRINCL
              Se habilitado, o usuário fornece um  header  ip  na  frente  dos
              dados.  Somente  válido para sockets SOCK_RAW.  Veja raw(7) para
              mais informação. Quando  este  flag  é  habilitado,  os  valores
              setados por IP_OPTIONS, IP_TTL e IP_TOS são ignorados.

       IP_RECVERR
              Habilita  a passagem estendida e confiável de mensagens de erro.
              Quando habilitado sobre um socket de datagrama, todos  os  erros
              gerados  serão  enfileirados  em  uma  fila de erros por-socket.
              Quando o usuário recebe um erro de uma operação  de  socket,  os
              erros   podem   ser   recebidos  chamando-se  recvmsg(2)  com  o
              sinalizador    MSG_ERRQUEUE     selecionado.     A     estrutura
              sock_extended_err  descrevendo  o  erro  será  analisada  em uma
              mensagem ancilar, com o tipo IP_RECVERR e o nível SOL_IP.   Isto
              é   útil   para   manipulação  confiável  de  erros  ou  sockets
              desconectados.  A parte dos dados recebidos a partir da fila  de
              erros contém o pacote de erro.

              IP  usa  a  estrutura  sock_extended_err como segue: ee_origin é
              setado em SO_EE_ORIGIN_ICMP para erros recebidos como um  pacote
              ICMP,  ou  SO_EE_ORIGIN_LOCAL  para  erros  gerados  localmente.
              ee_type e ee_code são setados para os campos "tipo"  e  "código"
              do  header  ICMP.  ee_info contém o MTU descoberto para EMSGSIZE
              erros.  ee_data não é usado atualmente. Quando o erro  originou-
              se  na  rede,  todas  as opções de IP (IP_OPTIONS, IP_TTL, etc.)
              habilitadas no socket e contidas no pacote de erro são  passadas
              como  mensagens  de controle. O "payload" do pacote que causou o
              erro é retornado como dado normal.

              Em sockets SOCK_STREAM , IP_RECVERR tem semânticas  ligeiramente
              diferentes.  Em  vez  de gravar os erros para o próximo timeout,
              ele passa todos os erros entrantes imediatamente para o usuário.
              Isto  pode ser útil para conexões TCP muito curtas, que precisam
              de uma manipulação de erros rápida. Use esta opção com  cuidado:
              ela  torna  o  TCP  não  confiável,  ao  não permitir que ele se
              recupere propriamente de deslocamento de  roteamento,  e  outras
              condições e quebras normais da especificação do protocolo.  Note
              que TCP não tem fila de erro; MSG_ERRQUEUE é ilegal  em  sockets
              SOCK_STREAM  Portanto todos os erros são retornados pelo retorno
              de função do socket ou SO_ERROR apenas.

              Para sockets diretos, IP_RECVERR  habilita  a  passagem  para  o
              aplicativo  de  todos os erros ICMP recebidos, caso contrário os
              erros serão relatados apenas nos sockets conectados.

              Ele seta ou recupera um flag  booleano  inteiro.   IP_RECVERR  é
              desligado, por padrão.

       IP_PMTU_DISCOVER
              Seta  ou  recupera  a configuração do Path MTU Discovery para um
              socket. Quando habilitado, o Linux realiza o Path MTU  Discovery
              neste  socket  como é definido na RFC1191.  O sinalizador de não
              fragmentação é selecionado em todos os datagramas de  saída.   O
              padrão geral do sistema é controlado pelo sysctl ip_no_pmtu_disc
              para sockets SOCK_STREAM , e desabilitado para todos os  outros.
              Para  sockets  que  não  são SOCK_STREAM , é responsabilidade do
              usuário empacotar os dados em blocos grandes, de  tamanho  igual
              ao  MTU  e  fazer  a  retransmissão,  se  necessário.   O kernel
              rejeitará pacotes que sejam maiores que o MTU da rota conhecida,
              se este flag é setada (com EMSGSIZE ).

              Flags do Path MTU Discovery   Significado
              IP_PMTUDISC_WANT              Usa configurações por-rota.
              IP_PMTUDISC_DONT              Nunca executa Path MTU Discovery.
              IP_PMTUDISC_DO                Sempre executa Path MTU Discovery.

              Quando    o   PMTU   discovery   está   habilitado,   o   kernel
              automaticamente guarda as informações do Path MTU  por  host  de
              destino.   Quando  ele  é  conectado  a  um  peer específico com
              connect(2) , o PMTU conhecido  atualmente  pode  ser  recuperado
              convenientemente   usando-se  a  opção  de  socket  IP_MTU  (por
              exemplo, depois da ocorrência de um erro EMSGSIZE ).  Isso  pode
              mudar  com  o  tempo.   Para  sockets  sem  conexão  com  muitos
              destinos, o novo also MTU para um dado destino também  pode  ser
              acessado  usando-se  a fila de erros (veja IP_RECVERR).  Um novo
              erro será enfileirado em toda atualização de MTU de entrada.

              Enquanto o MTU Discovery está em progresso, os pacotes  iniciais
              de  sockets de datagramas podem ser perdidos. Aplicativos usando
              UDP devem ser alertados sobre isso, e não levar  isso  em  conta
              pera a estratégia de retransmissão de pacotes.

              Para  bootstrap  o processo de path MTU discovery em sockets não
              conectados, é possível  iniciar  com  um  tamanho  de  datagrama
              grande  (de  até  64K-headers  bytes  de comprimento) e deixá-lo
              encolher pelas atualizações do MTU da rota.

              Para conseguir uma estimativa inicial do PMTU, conecte um socket
              de  datagrama  a  um  endereço  de  destino  usando connect(2) e
              recupere o MTU chamando getsockopt(2) com a opção IP_MTU

       IP_MTU Recupera o PMTU atual do socket corrente.  Somente válido quando
              o socket está conectado. Retorna um inteiro. Somente válido como
              um getsockopt(2).

       IP_ROUTER_ALERT
              Passa todos os  pacotes  "a  serem  encaminhados"  com  a  opção
              "Alerta  de  Roteador  IP" selecionada para este socket. Somente
              válido para sockets diretos. Isto é  útil,  por  enquanto,  para
              daemons  RSVP  do espaço do usuário. Os pacotes mandados não são
              encaminhados  pelo  kernel,  é   responsabilidade   do   usuário
              enviá-los  novamente.  A  ligação  do  socket  é  ignorada, tais
              pacotes  são  apenas  filtrados  pelo  protocolo.    Espera   um
              sinalizador inteiro.

       IP_MULTICAST_TTL
              Seta  ou lê o valor de "time-to-live" de pacotes de multicast de
              saída  para  este  socket.  É  muito  importante  para   pacotes
              multicast que seja setado o menor TTL possível.  O padrão é 1, o
              que significa que pacotes multicast não saem  da  rede  local  a
              menos  que  o  programa  do usuário o requeira explicitamente. O
              argumento é um inteiro.

       IP_MULTICAST_LOOP
              Seta ou lê um argumento booleano inteiro se pacotes de multicast
              enviados deveriam ser retornados por meio de "loop back" para os
              sockets locais.

       IP_ADD_MEMBERSHIP
              Integra a um grupo de multicast. O  argumento  é  uma  estrutura
              struct ip_mreqn

              struct ip_mreqn
              {
                  struct in_addr imr_multiaddr; /* endereço IP de grupo de multicast */
                  struct in_addr imr_address;   /* endereço IP da interface local */
                  int            imr_ifindex;   /* índice da interface */
              };

              imr_multiaddr  contém o endereço do grupo de multicast com que a
              aplicação quer se ligar ou deixar.   Deve  ser  um  endereço  de
              multicast  válido.   imr_address é o endereço da interface local
              com o qual o sistema deveria se unir ao grupo de  multicast;  se
              for  igual  a  INADDR_ANY , uma interface apropriada é escolhida
              pelo sistema.  imr_ifindex é um  índice  da  interface  que  vai
              agregar/abandonar  o  grupo  imr_multiaddr  ,  ou 0 para indicar
              qualquer interface.

              Por questão de contabilidade, a antiga estrutura ip_mreq ainda é
              suportada.  Ela  difere de ip_mreqn somente pela não inclusão do
              campo imr_ifindex.  Somente válido como um setsockopt(2).

       IP_DROP_MEMBERSHIP
              Abandona um grupo de multicast.  O  argumento  é  uma  estrutura
              ip_mreqn ou ip_mreq , similar a IP_ADD_MEMBERSHIP.

       IP_MULTICAST_IF
              Seta o dispositivo local para um socket multicast. O argumento é
              uma estrutura ip_mreqn ou ip_mreq , similar a IP_ADD_MEMBERSHIP.

              Quando  é  passada  uma  opção inválida de socket, ENOPROTOOPT é
              retornado.

SYSCTLS

       O protocolo IP suporta que a interface sysctl configure algumas  opções
       globais.   Os  sysctls  podem ser acessados pela leitura ou escrita dos
       arquivos /proc/sys/net/ipv4/* , ou usando a interface sysctl(2)

       ip_default_ttl
              Seta o valor default do "time-to-live" para  pacotes  de  saída.
              Isso pode ser alterado para cada socket, com a opção IP_TTL

       ip_forward
              Habilita  "IP  forwarding" com um flag booleano. "IP forwarding"
              também pode ser configurado em uma base por interface.

       ip_dynaddr
              Habilita endereço dinâmico de socket e  reescrita  mascarada  de
              entrada  em  mudança  de endereço de interface. Isto é útil para
              interface de dialup com endereços IP variáveis.  0 significa sem
              reescrita, 1 ativa a reescrita, e 2 habilita o modo verbose.

       ip_autoconfig
              Não documentado.

       ip_local_port_range
              Contém dois inteiros que definem a faixa padrão de portas locais
              alocados para sockets. A alocação começa com o primeiro número e
              termina no segundo.  Note que eles não deveriam conflitar com as
              portas  usadas  pelo  mascaramento  (apesar  de  que  o  caso  é
              manipulado).  Escolhas arbitrárias também podem causar problemas
              com  alguns  filtros  de  pacotes  de   firewall   que   assumem
              informações  sobre  as  portas locais em uso.  O primeiro número
              deve ser pelo menos maior que 1024, o melhor é  que  seja  maior
              que  4096  para  evitar  conflitos com portas mais conhecidas, e
              minimizar problemas com o firewall.

       ip_no_pmtu_disc
              Se habilitado, não realiza Path MTU Discovery para sockets  TCP,
              por  padrão.  Path  MTU  discovery pode falhar se firewalls mal-
              configurados (que perdem todos os  pacotes  TCP)  ou  interfaces
              mal-configuradas  (por exemplo, um link ponto-a-ponto onde ambos
              os extremos não concordam com o MTU) estão  na  rota.  É  melhor
              corrigir  os  roteadores problemáticos na rota do que desligar o
              Path MTU Discovery globalmente,  porque  a  não  execução  deste
              último incorre em grandes custos para a rede.

       ipfrag_high_thresh, ipfrag_low_thresh
              Se   a   quantidade   de   fragmentos   IP  enfileirados  atinge
              ipfrag_high_thresh , a fila é "podada" para ipfrag_low_thresh  .
              Contém um inteiro com o número de bytes.

       ip_always_defrag
              [Novo  com  Kernel  2.2.13;  em  versões anteriores do kernel, a
              feature  era  controlada  em  tempo  de  compilação  pela  opção
              CONFIG_IP_ALWAYS_DEFRAG ]

              Quando   esse  flag  booleano  é  habilitado  (diferente  de  0)
              fragmentos de entrada (partes de pacotes IP que surgiram  quando
              algum host, entre a origem e o destino, decidiram que os pacotes
              eram grandes demais e os cortaram em pedaços)  serão  remontados
              (desfragmentados)  antes  de  serem  processados,  mesmo se eles
              serão encaminhados.

              Somente habilite se estiver rodando um firewall  que  é  o  link
              exclusivo  para sua rede, ou um proxy transparente; nunca acione
              isso para um roteador normal ou um  host.  Caso  contrário,  uma
              comunicação fragmentada pode ser perturbada quando os fragmentos
              viajam sobre links diferentes. A desfragmentação também  consome
              muita memória e tempo da CPU.

              Isto  é  "automagicamente"  acionado  quando o mascaramento ou o
              proxy transparente são configurados.

       neigh/*
              Veja arp(7).

IOCTLS

       Todos os ioctls descritos em socket(7) se aplicam a ip.

       Os ioctls que configuram firewalling são  documentados  em  ipfw(7)  do
       pacote ipchains

       Os  ioctls  que  configuram  parâmetros  genéricos  do  dispositivo são
       descritos em netdevice(7).

NOTAS

       Tome cuidado com a opção SO_BROADCAST  -  ela  não  é  privilegiada  em
       Linux.  É  fácil  sobrecarregar a rede com broadcasts descuidados. Para
       novos protocolos de aplicativos, é melhor usar um grupo de multicast em
       vez de broadcast. Broadcast é desencorajado.

       Algumas outras implementações de sockets BSD provêm as opções de socket
       IP_RCVDSTADDR e IP_RECVIF para conseguir o  endereço  de  destino  e  a
       interface  dos  datagramas  recebidos.  O Linux tem o IP_PKTINFO , mais
       geral para a mesma tarefa.

ERROS

       ENOTCONN
              A operação só é definida em sockets  conectados  socket,  mas  o
              socket não é conectado.

       EINVAL Um  argumento  inválido  foi  passado.  Para operações de envio,
              isso pode ser causado pelo envio a uma rota blackhole

       EMSGSIZE
              O datagrama  é  maior  que  um  MTU  na  rota  e  não  pode  ser
              fragmentado.

       EACCES O  usuário  tentou  executar  uma  operação  sem  as  permissões
              necessárias.  Isso inclui: Envio de  pacote  a  um  endereço  de
              broadcast  sem  ter o sinalizador SO_BROADCAST seleciona.  Envio
              de  um  pacote  através  da   rota   prohibit   Modificação   de
              configuração  de  firewall  sem  CAP_NET_ADMIN  ou id de usuário
              efetivo   0.    Ligação   em    uma    porta    reservada    sem
              CAP_NET_BIND_SERVICE ou id de usuário efetivo 0.

       EADDRINUSE
              Tentativa de ligar a um endereço já em uso.

       ENOMEM and ENOBUFS
              Não há memória disponível suficiente.

       ENOPROTOOPT and EOPNOTSUPP
              Uma opção de socket inválida foi passada.

       EPERM  Usuário não tem permissão para configurar alta prioridade, mudar
              configuração,  ou  enviar  sinais  para  o  processo  ou   grupo
              requerido.

       EADDRNOTAVAIL
              Uma  interface  não  existente  foi  requerida, ou o endereço de
              origem requerido não era local.

       EAGAIN A operação sobre um socket não-bloqueável teria sido  bloqueada.

       ESOCKTNOSUPPORT
              O socket não está configurado, ou um tipo desconhecido de socket
              foi requerido.

       EISCONN
              connect(2) foi chamado em um socket já conectado.

       EALREADY
              Uma operação de conexão sobre um socket não-bloqueável  já  está
              em progresso.

       ECONNABORTED
              Uma conexão foi fechada durante um accept(2).

       EPIPE  A  conexão  foi  inesperadamente fechada ou derrubada pelo outra
              extremidade.

       ENOENT SIOCGSTAMP foi chamado em um socket onde nenhum pacote chegou.

       EHOSTUNREACH
              Nenhuma entrada válida da tabela de  roteamento  combina  com  o
              endereço de destino. Este erro pode ser causado por uma mensagem
              ICMP de um roteador remoto para a tabela de roteamento local.

       ENODEV Dispositivo de rede não disponível ou não capaz de enviar IP.

       ENOPKG Um subsistema do kernel não foi configurado.

       ENOBUFS, ENOMEM
              Não há memória livre suficiente.  Isso frequentemente quer dizer
              que  a alocação de memória é limitada pelos limites do buffer de
              socket, e não pela memória do  sistema,  mas  isso  não  é  100%
              consistente.

       Outros  erros  podem  ser  gerados  pelos  protocolos  de overlay; veja
       tcp(7), raw(7), udp(7) e socket(7).

VERSÕES

       IP_PKTINFO,  IP_MTU,   IP_PMTU_DISCOVER,   IP_PKTINFO,   IP_RECVERR   e
       IP_ROUTER_ALERT são novas opções no Linux 2.2.

       struct  ip_mreqn  é  novo  no  Linux  2.2.   Linux  2.0 somente suporta
       ip_mreq.

       Os sysctls foram introduzidos com o Linux 2.2.

COMPATIBILIDADE

       Por questões de compatibilidade com o Linux  2.0,  a  sintaxe  obsoleta
       socket(PF_INET,  SOCK_RAW,  protocol)  ainda  é suportada para abrir um
       socket packet(7) socket(PF_PACKET, SOCK_RAW, protocol)  nova  estrutura
       de  endereço sockaddr_ll para informação genérica da camada de link, em
       vez do antigo sockaddr_pkt.

PROBLEMAS

       Há muitos valores de erro inconsistentes.

       Os ioctls que configuram  opções  de  interface  específicos  do  IP  e
       tabelas ARP não estão descritos.

AUTORES

       Esta man page foi escrita por Andi Kleen.

VEJA TAMBÉM

       sendmsg(2),  recvmsg(2), socket(7), netlink(7), tcp(7), udp(7), raw(7),
       ipfw(7).

       RFC791 para a especificação IP original.
       RFC1122 para os requisitos do host IPv4.
       RFC1812 para os requisitos do roteador IPv4.

TRADUZIDO POR LDP-BR em 21/08/2000.

       Rubens de  Jesus  Nogueira  <darkseid99@usa.net>  (tradução)  André  L.
       Fassone Canova <lonelywolf@blv.com.br> (revisão)