Résumé

  • Dans la RFC 1207, deux Sun 3/60 reliées par SLIP sur leurs ports ttya réussissaient ping et rlogin, mais le montage NFS affichait server not responding: RPC Timed Out. La réponse incriminait la somme de contrôle UDP désactivée par SunOS 3.5 sur une liaison SLIP dépourvue de contrôle équivalent.
  • La même section précisait que le SLIP de SCO TCP/IP pour Xenix exigeait les pilotes série de SCO. Une carte intelligente à plusieurs ports munie de ses propres pilotes ne satisfaisait pas cette condition. La disponibilité d’une liaison et la compatibilité d’un service se prouvaient séparément.

La réussite la moins chère masquait la panne coûteuse

Un administrateur avait de quoi cocher la case « réseau ». Les deux stations Sun 3/60 échangeaient par leurs ports ttya avec SLIP. ping trouvait l’autre machine. rlogin fonctionnait. Puis le partage de fichiers refusait de se monter, et le système répondait par une expiration RPC. La contradiction est seulement apparente : ces trois essais ne sollicitent pas les mêmes garanties.

Cette question figurait dans une FAQ pour utilisateurs expérimentés de l’Internet, publiée en février 1991 par G. Malkin, A. Marine et J. Reynolds. Les rédacteurs avaient suivi de grandes listes de diffusion afin de recueillir les difficultés récurrentes. Ils voulaient fournir aux équipes d’exploitation, notamment sur les réseaux nouvellement raccordés, un répertoire de réponses utilisables. Ils voulaient aussi épargner aux abonnés la répétition des mêmes échanges. La panne NFS avait précisément le genre de forme qui revient dans une liste : tout paraît branché, et le travail demandé reste impossible.

La réponse localisait un réglage. Selon la FAQ, SunOS 3.5 désactivait la somme de contrôle UDP. Sur Ethernet, le contrôle au niveau de la liaison pouvait rendre ce choix acceptable dans l’usage décrit. SLIP ne possédait pas ce contrôle. Pour faire tourner NFS sur la liaison série, la réponse demandait donc d’activer la somme UDP. Elle indiquait une commande adb pour modifier udpcksum dans le noyau et recommandait de conserver l’ancien noyau.

Le détail est important parce qu’il déplace la décision. Changer le nom du serveur NFS ou remplacer le câble aurait traité le symptôme au mauvais endroit. ping attestait qu’un échange particulier passait. rlogin attestait qu’une session interactive passait. Aucun des deux ne vérifiait que le trafic UDP nécessaire au montage disposait du contrôle attendu sur cette liaison. Un voyant vert ne peut certifier un travail qu’il n’a jamais exécuté.

Une carte plus savante, un pilote moins utile

La même section de la RFC proposait un autre piège, cette fois avant même le premier montage. Un utilisateur de Xenix voulait plusieurs ports série pour SLIP. SCO TCP/IP pour Xenix prenait bien en charge SLIP, répondait le texte, mais seulement avec les pilotes série de SCO. Les cartes intelligentes à plusieurs ports livrées avec leur propre pilote ne convenaient pas. Pour multiplier les ports, la réponse proposait des ports simples, éventuellement réunis sur une carte multipostes sans intelligence embarquée.

Le matériel le plus élaboré pouvait ainsi devenir le mauvais achat. La fiche d’une carte donnait son nombre de ports ; la fiche du logiciel disait « SLIP ». Entre les deux se trouvait le pilote effectivement chargé. C’était lui qui décidait si le logiciel savait utiliser la carte. Le budget consacré à une capacité supérieure ne franchissait pas automatiquement cette interface.

Plus tôt dans le chapitre, une autre question inversait même la nature de SLIP : le demandeur croyait le protocole réservé aux lignes synchrones. La réponse rappelait qu’il avait été conçu pour les lignes asynchrones, tandis que PPP pouvait convenir aux deux types. Type de circuit, pilote, contrôle des datagrammes, application : la mise en réseau de machines existantes exigeait des réponses distinctes à chacun de ces niveaux. L’acronyme « SLIP » posé sur la commande d’achat ne réglait pas l’ensemble.

La commande imprimée n’était pas le résultat observé

La FAQ donnait la ligne historique de modification du noyau, avec la précaution de garder l’ancien. Cette précision rend visible le levier que les rédacteurs jugeaient pertinent. Elle ne fournit pas la trace des paquets avant et après, le réglage effectivement lu sur les deux machines, ni le résultat d’un nouveau montage. Ces éléments établiraient si le diagnostic a résolu cette installation particulière. Le texte consigne le succès de ping et rlogin, puis l’échec de NFS ; il propose ensuite une réparation.

Les rédacteurs expliquaient d’ailleurs leur méthode. Certaines réponses trouvées sur les listes étaient raccourcies ; ils pouvaient en ajouter quand la liste n’en avait pas donné, sans toujours les distinguer ; les compléments portaient un intitulé propre. Les noms des correspondants avaient été retirés. Le document transforme du savoir d’exploitation dispersé en référence publique, sans fabriquer un compte rendu d’incident complet.

Sa leçon opérationnelle tient dans cette séparation des preuves. La ligne marchait pour deux tests. Le service de fichiers échouait. Pour expliquer l’écart, il fallait descendre jusqu’à la garantie qu’offrait Ethernet et que SLIP n’offrait pas. C’est à ce niveau que l’équipe devait regarder avant de déclarer la machine « connectée » au sens qui comptait pour son utilisateur.

Source