NOTE: la fonctionnalité de connexion à la demande a été
énormément discutée sur la liste linux-kernel aux mois de
mai et de juin 1996. Il semble qu'il y ait quelques conditions particulières
de fonctionnement, et certains des gourous réseau ont recommandé
de ne pas utiliser kerneld pour cela. Le paquetage
diald peut être utilisé à la place, et permet
une souplesse plus importante lorsqu'il est nécessaire d'activer la connexion.
kerneld reçoit également une requête lorsque le noyau
a besoin d'envoyer des données à travers une connexion réseau
dont il ne connaît pas la route. C'est typiquement le cas si votre
réseau utilise une connexion SLIP ou PPP qui n'est active que de temps en
temps.
La requête que kerneld reçoit est sous la forme
request-route a.b.c.d, où a.b.c.d correspond à
l'adresse IP de la machine de destination. kerneld
va gérer cette requête en exécutant un script shell,
/sbin/request-route, avec l'adresse IP en paramètre.
Bien souvent, l'adresse IP demandée est celle de votre serveur de nom
(voir le fichier /etc/resolv.conf). À moins que vous
n'ayez plus d'une connexion réseau (par exemple un réseau Ethernet et
une connexion modem), vous pouvez sans problème ignorer cette adresse IP :
tous les accès réseau doivent se comporter de la même manière, et
il n'y a pas lieu de faire une différence entre les requêtes pour
telle ou telle adresse.
Pour implémenter la connexion à la demande, vous devez tout simplement
modifier le script /sbin/request-route
pour qu'il utilise une connexion SLIP ou PPP. Pour SLIP, cela utilise
généralement le programme dip (ou autre), pour appeler le
serveur SLIP et activer la connexion. Pour PPP, vous utiliserez probablement
chat et pppd. Le script n'a pas à se soucier s'il
doit charger ou pas les modules PPP ou SLIP : c'est automatisé par
kerneld.
Appeler votre fournisseur d'accès et configurer votre connexion
SLIP ou PPP peut mettre un peu de temps, et peut éventuellement
échouer. Le script request-route possède donc un système de
temporisation, par défaut fixé à 60 secondes, qui détermine le temps
d'attente du noyau pour obtenir la connexion. Bien souvent, la configuration
prend beaucoup moins de temps, donc pour obtenir une réponse la plus
rapide possible, vous devriez vous arranger à annuler la temporisation
dès que la connexion est établie. Les utilisateur de SLIP peuvent, s'ils
utilisent une version récente de dip, se servir de la commande :
shell kill `cat /tmp/request-route`
juste avant la commande mode SLIP dans le script DIP.
Les utilisateur de PPP peuvent faire un
kill `cat /tmp/request-route`
dans leur script /etc/ppp/ip-up.
Si votre réseau met plus de 60 secondes pour se configurer, alors
vous devrez changer la durée du timer dans le script
/sbin/request-route. Dans ce cas, vous aurez besoin de modifier
le délais de déchargement des modules non utilisés de kerneld,
en ajoutant l'option delay=xxx dans le fichier qui lance
le démon (par exemple /etc/rc.d/rc.S). La valeur xxx
correspond au temps d'inactivité d'un module avant qu'il ne soit
déchargé, en secondes (par défaut, c'est 60).
C'est nécessaire si vous utilisez PPP : les modules ppp sont chargés
dès que le démon pppd est lancé. Mais si vous utilisez une
commande du genre
/usr/sbin/pppd connect `chat -f /etc/chat.script` ...
alors le démon pppd reste inactif pendant l'exécution du script.
Donc, les modules PPP peuvent être déchargés avant que le script ne se
termine (NdT : lorsque la connexion est longue par exemple, cela se produit
souvent).
kerneld ne sait pas comment rendre compte de l'activité réseau
pour couper la connexion. Toutefois, les utilisateur de PPP peuvent
utiliser l'option idle-disconnect de pppd introduite
dans la version ppp-2.2.0. Si vous utilisez cette option :
idle-disconnect 600, alors la connexion PPP
sera coupée après 600 secondes (10 minutes) d'inactivité réseau. Les
utilisateurs de SLIP devront couper la liaison manuellement.
Chapitre suivant, Chapitre Précédent
Table des matières de ce chapitre, Table des matières générale
Début du document, Début de ce chapitre