Resumo

  • A RFC 1207 registrou duas Sun 3/60 ligadas por SLIP nas portas ttya. ping e rlogin funcionavam; a montagem NFS retornava server not responding: RPC Timed Out. A resposta atribuiu o problema ao checksum UDP desligado no SunOS 3.5, combinado com o fato de o SLIP não oferecer checksum próprio.
  • Na mesma seção, a FAQ informou que o SLIP do SCO TCP/IP para Xenix só funcionava com drivers seriais da SCO. Uma placa inteligente de várias portas com driver próprio não servia para aquela implementação. Ter uma linha e ter portas disponíveis eram verificações menores do que entregar o serviço pretendido.

O teste que passou não montava arquivos

O cenário parecia resolvido antes de o trabalho começar. As duas Sun 3/60 estavam conectadas pelas portas ttya e trocavam pacotes usando SLIP. O ping tinha resposta. O rlogin permitia entrar na outra máquina. Então veio a montagem NFS, seguida da mensagem de tempo esgotado do RPC. O administrador tinha duas provas de funcionamento e uma falha que ambas deixavam de fora.

A pergunta chegou à RFC 1207, uma coletânea para usuários experientes organizada por G. Malkin, A. Marine e J. Reynolds em fevereiro de 1991. Os editores acompanharam grandes listas de discussão e retiraram delas perguntas repetidas. Queriam ajudar equipes de operação, especialmente em redes que estavam entrando na Internet, e reduzir o custo de ver as mesmas dúvidas circularem de novo. A falha de NFS era candidata perfeita: qualquer equipe que aceitasse “a rede está funcionando” como diagnóstico teria de reabrir o caso quando alguém tentasse usar o sistema de arquivos.

A resposta encontrou uma condição específica. Segundo a FAQ, o SunOS 3.5 deixava o checksum UDP desligado. Em Ethernet, a verificação da camada de enlace podia fazer esse arranjo funcionar. O SLIP não tinha verificação equivalente. Para rodar NFS sobre a linha serial, a resposta mandava ativar o checksum UDP. Publicou até o comando histórico de adb para mudar udpcksum no kernel, com o conselho de guardar o kernel anterior.

A diferença entre os três testes é o centro da história. ping atesta que a troca que ele próprio realizou chegou ao destino. rlogin atesta uma sessão interativa. Nenhum deles responde se as trocas UDP do NFS estavam protegidas na configuração descrita. A equipe que declarasse o link pronto depois de dois sinais verdes entregaria ao usuário a tarefa de descobrir a terceira condição.

Mais portas, menos compatibilidade

A seção 8.3 também apresentou um pedido de outro operador: usar SLIP no Xenix com uma placa serial de múltiplas portas. A resposta reconheceu que o SCO TCP/IP para Xenix oferecia SLIP, mas disse que ele funcionava somente com os drivers seriais da SCO. Placas inteligentes que vinham com seu próprio driver ficavam fora. Para multiplicar portas, a sugestão era usar várias portas simples ou uma placa multiposta sem aquela inteligência.

É o tipo de surpresa que aparece depois da compra. A placa promete capacidade; o sistema operacional promete SLIP. Quem decide se os dois se encontram é o driver que atende a placa. Um produto mais avançado podia, nesse caso, estreitar as opções de instalação. Contar conectores no gabinete não dizia se o software conseguiria usá-los.

A FAQ ainda corrigia uma lembrança errada no início do capítulo: SLIP foi pensado para linhas seriais assíncronas, enquanto PPP podia operar em linhas assíncronas ou síncronas. O operador precisava saber qual circuito tinha, qual driver carregava, que proteção existia para os dados e que aplicação seria usada. Essas perguntas pertenciam a camadas diferentes. O caso de Xenix parava na interface do driver; o caso de NFS, na integridade dos datagramas sobre a linha.

Um comando no papel não é um relatório de conserto

A precisão da resposta SunOS impressiona: ela nomeia a variável do kernel, fornece um comando e lembra o leitor de preservar a versão anterior. Também deixa uma lacuna concreta. A RFC não mostra a configuração lida nas máquinas após a mudança, uma captura dos pacotes nem uma montagem NFS concluída depois do ajuste. Esses registros permitiriam dizer se a recomendação resolveu aquele ambiente. O documento registra a falha e a intervenção proposta.

Os editores explicaram sua própria forma de trabalho. Às vezes encurtavam respostas das listas; às vezes forneciam uma resposta quando a lista não a tinha dado, sem sempre separar essa contribuição; material extra vinha marcado. Os nomes dos correspondentes foram retirados. O resultado é um arquivo público de experiência operacional, não um laudo completo de incidente. Ele preserva a pergunta que uma luz de conexão não responde: a aplicação que trouxe o usuário até ali conseguiu terminar sua tarefa?

Fonte