<!-- 0,1 -->
<!-- PPP,0 -->
<!-- Al,Longyear,longyear@netcom.com -->
<!-- 1.0,1996-03-09 -->
<!-- PPP -->
<!-- Rafael,Agundo,ragundo@bitmailer.net -->
<!-- 1.0,1997-02-04 -->
<!-- PPP -->
<!-- Software,Protocolos,PPP -->

<!doctype linuxdoc system>

<!-- Traduccion del PPP-HOWTO -->

<article>

<!-- Title information -->

<title>Linux PPP HOWTO

<author>Al Longyear, <tt><htmlurl url="mailto:longyear@netcom.com" 
name="longyear@netcom.com"></tt>. &nl;  Traducido por Rafael Agundo
(INSFLUG), <tt><htmlurl url="mailto:ragundo@bitmailer.net"
name="ragundo@bitmailer.net"></tt>

<date>v1.0, 9 Marzo 1996

<abstract>
Este documento contiene una lista con las preguntas más habituales (FAQ, o
PUF, Preguntas de Uso Frecuente, en castellano)  sobre PPP para Linux
(junto con sus respuestas). No es realmente un Como, pués se adapta más al
formato clásico de Pregunta/Respuesta de las PUF. 
</abstract>

<toc>

<sect>Prefacio.
<p>

Si tiene alguna corrección sobre este documento, por favor, notifíquesela
a Al Longyear (<htmlurl url="mailto:longyear@netcom.com"
name="longyear@netcom.com">). Si tiene alguna corrección relativa a la
traducción, contacte con Rafael Agundo (<htmlurl
url="mailto:ragundo@bitmailer.net" name="ragundo@bitmailer.net">).

Este documento forma parte de los HOWTO y FAQs de Linux. Estos documentos
pueden conseguirse vía ftp en <url
url="ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/" name="sunsite.unc.edu">
(este es el sitio <em>oficial</em>) o bien mediante WWW en <url
url="http://sunsite.unc.edu/mdw/linux.html" name="la Linux Documentation
home page">. No espere que este HOWTO aparezca publicado en
<tt>comp.os.linux.answers</tt>, debido a problemas de espacio. 

A lo largo de este documento, se usa la palabra <em>remoto</em> para
designar "el sistema que está al final del enlace a traves del módem". En
la documentación sobre PPP suele aparecer también como <em>peer</em>.
Cuando se habla de rutado suele aparecer como <em>gateaway</em>. La
dirección IP del sistema remoto aparecerá como el campo <em>dirección
'P-t-P'</em> cuando se use <tt>ifconfig</tt>.  Asimismo, se emplea
indistintamente el término inglés <em>frame</em> junto con sus
equivalentes en castellano: trama o paquete. 

Microsoft es una marca registrada de Microsoft Corporation. Morning Star
es una marca registrada de Morning Star Technologies. El resto de
productos mencionados en este documento son marcas registradas de sus
respectivas compañías. 


<sect>Información general
<p>

<sect1>¿ Qué es PPP ?.
<p>

PPP o Point-to-Point Protocol (<bf>P</bf>rotocolo de <bf>P</bf>unto a
<bf>P</bf>unto) está reconocido como uno de los protocolos
<em>oficiales</em> de internet. Este protocolo se usa para intercambiar
tramas IP (y de otro tipo) a través de una línea serial. El número de RFC
para describir PPP es el 1661. No es el único, hay otros muchos documentos
relacionados con PPP. 

Contrariamente a lo que algunas personas piensan, PPP no significa "Peer
to Peer Processing", aunque se pueda realizar una comunicación peer to
peer usando TCP/IP a traves de un enlace PPP. 

<sect1> Mi universidad ( o compañía ) no soporta PPP. ¿ Puedo usar PPP ?.
<p>

En general, no. Una implementación <em>clásica</em> de PPP requiere
cambios en las rutas y en los dispositivos conectados al sistema
operativo. En definitiva, sería necesario volver a recompilar el kernel en
el ordenador remoto. 

Obtener un nuevo kernel no es tarea para un usuario normal de un sistema.
Si puede convencer al administrador de su sistema de las ventajas de tener
instalado soporte PPP, entonces puede ser que se instale dicho soporte. Si
no es así, entonces no podrá usar probablemente PPP. 

Sin embargo, si usted usa un sistema soportado por la compañía que está
vendiendo el paquete adaptador TIA (The Internet Adapter), entonces puede
ser que si pueda usar PPP. El autor de este HOWTO no tiene disponible
mucha información sobre este paquete, sin embargo parece ser que ofrecerá
soporte PPP en su próxima versión. (Esta información puede estar ya
anticuada, mejor contacte con ellos directamente. Para averiguar más sobre
TIA, puede visitar <url url="http://www.marketplace.com/tia/tiahome"
name="www.marketplace.com">

Actualmente ya existe una versión para Linux de este paquete.

Si su sistema no está soportado por el paquete TIA, ni puede convencer a
su administrador de sistema para que adopte PPP, entonces debería usar el
paquete <em>term</em>. Algunos proveedores de servicios de conexión pueden
ponerle trabas a utilizar <em>term</em> para conectar con sus sistemas.
Hay varias razones para ello, pero la más importante está referida a temas
de 'seguridad'. 

Además del paquete TIA, Danny Gasparovski ha escrito un programa llamado
<tt>slirp</tt>, el cual realizará funciones similares al de TIA. Este
programa, junto con su código fuente, puede obtenerse mediante <url
url="ftp://blitzen.canberra.edu.au/pub/slirp" name="ftp">

Debería conseguir el código fuente del programa si desea obtener una mejor
información de cómo funciona.  La primera impresión es que el programa es
una excelente alternativa al paquete comercial de TIA. 

<sect1>¿ Dónde se encuentra PPP?.
<p>

El paquete PPP está dividido en dos partes. La primera se encuentra en el
kernel. A partir del kernel 1.1.13, el driver ya forma parte de los
drivers de red del sistema. 

La segunda parte es el <em>demonio</em> (daemon) <tt>pppd</tt>. Este es un
proceso obligatorio a ejecutar cuando quiera realizar una conexión PPP. El
código fuente para <tt>pppd</tt> se encuentra en el fichero
<tt>ppp-2.2.0.tar.gz</tt> de <url
url="ftp://sunsite.unc.edu/pub/Linux/system/Network/serial"
name="sunsite.unc.edu">
 
La versión 2.2 de PPP y posteriores están diseñadas para ser utilizadas
sólo con versiones de kernel mayores o iguales que la 1.2. No utilize esta
versión con versiones del kernel 1.1 o inferior, dado que tanto el código
de red, como el driver tty están ya desfasados. 

<sect1>Acabo de conseguir el paquete PPP. ¿ Qué hago con él ?.
<p>

Read The Fine Material available.

<footnote> ( Pequeña broma del autor que sustituye el famoso término RTFM:
Read The Fucked Manual, lea el jodido manual por RTFM: Read The Fine
Material, lea los agradables manuales).  </footnote>

Comience por leer el fichero <tt>README</tt> y después el fichero
<tt>README.linux</tt>. Para más fuentes de documentación vea la siguiente
pregunta. 

<sect1>¿ (Dónde está la documentación ?. ¿ Hay un HOWTO ?, etc.). ¿ Dónde
puedo conseguir documentación adicional sobre PPP ?. 
<label id="consultelo">
<p>

Hay varias fuentes de información sobre la manera en que se ha
implementado el protocolo PPP para Linux. 

<itemize>
<item>El fichero <tt>README</tt> que viene junto con el paquete.

<item>El fichero <tt>README.linux</tt> que también viene junto con el paquete.

<item>El documento Net-2-HOWTO.

<item>La Network Administration Guide (NAG).

<item>La página <tt>man</tt> de <tt>pppd</tt>.

<item>La PPP FAQ. (Este HOWTO no lo es aunque lo parezca).

</itemize>

El fichero HOWTO se encuentra en el lugar habitual para los HOWTOs de
Linux.  Actualmente están en <url
url="sunsite.unc.edu/pub/Linux/docs/HOWTO" name="sunsite.unc.edu">. 

La Network Administration Guide (Guia de Administración de Red ) puede
obtenerse en <url
url="ftp://sunsite.unc.edu/pub/Linux/docs/LDP/network-guide"
name="sunsite.unc.edu">. También está publicada en forma de libro impreso
por la editorial <url url="http://www.ora.com" name="O'Reilly and
Associates">. Si prefiere un documento profesional, bien impreso y
encuadernado, consiga una copia del libro en su librería habitual. 

Las páginas <tt>man</tt> vienen incluídas junto con el código fuente del
paquete PPP.  Casi con seguridad, será necesario moverlas al directorio
habitual donde se sitúan las páginas <tt>man</tt>, <tt>/usr/man/man8</tt>
antes de que el comando <tt>man</tt> pueda encontrarlas. También puede
usar <tt>nroff</tt> y <tt>more</tt> para leerlas directamente. 

La PPP FAQ describe el protocolo PPP en general, junto con varias de sus
implementaciones. La PPP FAQ puede encontrarse en el area de news
<tt>comp.protocols.PPP</tt> y también archivada en <url
url="ftp://rtfm.mit.edu/pub/usenet" name="rtfm.mit.edu">.  Actualmente, la
PPP FAQ está dividida en 8 partes. 

<sect1>¿ Podría alguien enviarme scripts para PPP, de tal manera que pueda
comprender cómo se han escrito ?. 
<p>

Existen unos pocos scripts que vienen incluidos con el código fuente del
paquete.  Estos ejemplos cubren los tipos de accesos más normales que
usted va a encontrar, accesos donde se conecta a una máquina UNIX que le
va a pedir un <tt>login</tt> y un <tt>password</tt>. 

Con el código fuente de <tt>pppd</tt> no vienen scripts específicos para
conectar con un sistema en concreto. Si tiene problemas para conectar con
dicho sistema, entonces debería pedir ayuda a alguien de su sistema y si
no la encuentra, debería preguntar en el area local de news de su sistema.
Si, por último, sigue sin poder encontrar ayuda, pregunte en el grupo
adecuado de Linux en usenet (vea la siguiente pregunta).
Desafortunadamente, el autor no tiene tiempo para poder suministrar
scripts para cada sistema en concreto. 

<sect1>¿ Dónde debo preguntar para resolver mis posibles dudas sobre PPP?.
<p>

El grupo adecuado de usenet para preguntar es <tt>comp.protocols.PPP</tt>
o <tt>comp.os.linux.setup</tt>.  Use estos grupos para realizar preguntas
del tipo: "¿ Cómo debo usar pppd ?" o "¿ Porqué no funciona esto ? ". 

Preguntas del estilo: "¿ Porqué no consigo compilar pppd ?", son preguntas
que debe dirigir al grupo <tt>comp.os.linux.networking</tt>. 

Por favor, no utilice para estas cuestiones <tt>comp.os.linux.help</tt>,
incluso si su sistema sigue recibiendo este grupo de news (ya obsoleto). 

<sect1> Mi software PPP no funciona. ¿ Qué hago ?.
<p>

Esta es una de las preguntas más habituales que suelen hacerse. Si usted
envía esta pregunta a usenet sin dar una información más específica, lo
más probable es que la gente que lea el area la ignore. 

Vea primero la pregunta referida a errores que aparecen al desconectar el
módem (pregunta <ref id="modem_no_cuelga" name="PPP no cuelga el módem
cuando termina">).  Estos errores no son la causa del problema, sino sólo
síntomas.  Preguntar qué puede ir mal incluyendo sólo estos errores
tampoco sirve de mucho, asi que&hellip; 

Lo que realmente debe proporcionar junto con su petición de ayuda es una
copia del system log (syslog) que obtiene cuando ejecuta <tt>pppd</tt> con
la opción <tt>debug</tt>. Además, si usa <tt>chat</tt> para establecer la
comunicación, use la opción <tt>-v</tt> en la línea de comandos de
<tt>chat</tt> para ver qué es lo que está ocurriendo realmente. 

Incluya además los mensajes que proporcione el kernel al arrancar el
sistema. Estos mensajes aportan información sobre el hardware que tiene
instalado en su máquina, tipo de UART, versión de PPP, etc. 

Incluya también toda la información que pueda relacionada con su problema. 
El tipo de disco duro que tenga, la marca de su tarjeta de sonido, o
cuanta memoria tiene su tarjeta de vídeo son irrelevantes. Lo importante
son cosas como el tipo de sistema al que desea conectar, la versión de PPP
(o de terminal) que usa el sistema remoto, el tipo de módem o la velocidad
con la que quiere conectar. 

Tenga en cuenta cuando ponga su syslog, que debe eliminar cualquier
posible referencia a su número de teléfono, su login o su password. No son
importantes a la hora de solucionar el problema, pero si pueden causarle
más de un problema de seguridad el proporcionar a todo el mundo su clave
de acceso.  Elimine también cualquier línea que no provenga del kernel o
de <tt>pppd</tt>. 

<em>NUNCA</em> ejecute <tt>pppd</tt> con la opción <tt>kdebug 31</tt> para
acompañar su petición de ayuda. 

Si su problema requiere examinar el flujo de datos que se intercambia
entre los ordenadores implicados en la conexión, recibirá un email
solicitándole que lo envíe. Desafortunadamente, usenet cuesta demasiado
dinero a mucha gente como para engrosar innecesariamente la longitud de
los mensajes. 

La información relativa sobre PPP está estructurada en varios niveles. La
información de debug es enviada al nivel de debug. Los mensajes
aclaratorios son enviados al nivel de información. Los errores son
enviados al nivel de error. Incluya todos los mensajes que provengan del
grupo 'local2' del proceso <tt>pppd</tt>. 

Por último, no borre la información relativa a la impresión de tiempos. Es
importante. 

<sect1>¿ Cómo debo usar PPP con un sistema remoto que usa asignación
dinámica de direcciones IP ?. ¡¡¡ Cada vez que conecto obtengo una
dirección IP distinta !!!. 
<p>

La asignación de la dirección IP local está en función de las opciones que
se proporcionen a <tt>pppd</tt> y del protocolo IPCP. Debería utilizar la
dirección IP <em>mágica</em> 0.0.0.0 si necesita especificar su dirección
IP local. La mayoría de la gente simplemente no incluye la dirección IP
local en las opciones de <tt>pppd</tt>. 

La otra opción relacionada con este tema se llama <tt>noipdefault</tt>.
Esta opción indica a su proceso <tt>pppd</tt> que no debe obtener su
dirección IP local a partir de los datos que contenga su fichero
<tt>/etc/hosts</tt>, sino que dicha dirección IP debe proporcionarla el
sistema remoto. La mayoría de la gente usa esta opción cuando la dirección
IP es asignada dinámicamente. Sin embargo, esta opción no debe entenderse
como "usa direcciones IP dinámicas". El uso de direcciones IP dinámicas es
automático cuando no se proporciona la dirección IP local. 

<sect1>¿ Cómo puedo saber que dirección IP me ha sido asignada cuando se
usa asignación dinámica de direcciones ?. 

<p>

Utilize el fichero ejecutable <tt>/etc/PPP/ip-up</tt>. La dirección IP
local es el cuarto parámetro que se le pasa a este fichero en su línea de
comandos. Este fichero se ejecuta cuando <tt/pppd/ conoce su dirección IP
local. 

Además, por si le interesa, el quinto parámetro que se le pasa a este
fichero es la dirección IP remota del sistema con el que ha conectado. 

Si siente curiosidad sobre el valor que le ha sido asignado, entonces
debería ejecutar <tt>ifconfig</tt>. Este programa le mostrará los valores
actuales de la direcciones IP local y remota bajo el campo "P-t-P". 
 
<sect1>¿ Puedo usar la misma dirección IP local para todas las líneas de
un servidor PPP?. 
<p>

Si. La dirección local no es significativa para el sistema local. Lo que
si debe tener es una única dirección IP remota. El rutado de información
se realiza usando la dirección IP remota, no la local. 

<sect>Otras implementaciones.
<p>

<sect1>¿ Existen otras implementaciones de PPP distintas a la de Linux ?.
Me gustaría saber si existe alguna para HP-UX o AIX o &hellip; 
<p>

Revise la PPP FAQ mencionada anteriormente. Consulte la pregunta <ref
id="consultelo" name="¿ Dónde está la documentación ?.">. 

HP-UX está soportado por el paquete comercial de Morningstar. El soporte
para AIX se encuentra ya disponible en la versión 2.2 del paquete
<tt>pppd</tt>. 

Si no encuentra el sistema que busca, pregunte en
<tt>comp.protocols.ppp</tt> y <em>NO</em> en los grupos de Linux. 

Por favor, no mande email al autor de este HOWTO con cuestiones del
estilo:  "¿ Conoce algún paquete PPP para el sistema xxxx ?". Estas
preguntas serán archivadas "apropiadamente" <tt/:-)/. 

El paquete <tt>pppd</tt> que se encuentra en <tt>sunsite</tt> no contiene
código que implementa interfaces del tipo stream. Esto se debe a que estos
tipos de interfaces tienen copyright. El grupo de personas que han
diseñado el paquete <tt>pppd</tt> ha realizado gestiones para ver si se
podían cambiar los términos de este copyright. Por el momento, no ha
habido respuesta. 

Por esta razón, y dado que <tt>sunsite</tt> está dedicado específicamente
a Linux, se han eliminado los ports de PPP para AIX, SunOS, Next y otros
sistemas que contenían protocolos con streams.  Se siguen manteniendo los
ports para BSD y para Linux. Si quiere conseguir el código de
<tt>pppd</tt> para otros sistemas, consulte la PPP FAQ. Alternativamente,
puede utilizar <tt>archie</tt>. No intente buscarlo en los mirrors de
<tt>sunsite</tt> porque tampoco estará ahí. 

<sect1>¿ Existe un programa llamado <tt>dp</tt> ?.
<p>

Si, existe. El paquete <tt>dp</tt> fue considerado al inicio del
desarrollo de la traslación de PPP a Linux. Es un buen programa, permite
"demand dial", pero sólo funciona con sistemas que soportan streams. SunOS
(Solaris) es un ejemplo de estos sistemas. Linux, por el momento,
<em>NO</em> soporta streams. 

Existen otros paquetes para PPP circulando por Internet. <bf>Portable
PPP</bf> es un paquete muy similar al de TIA. También existe otro paquete
denominado simplemente <bf/ppp/. El paquete <bf/KA9Q/ también contiene
código que implementa PPP. 

De todos estos paquetes, <tt>pppd</tt> fue el que más se ajustaba a las
necesidades de la traslación a Linux, por eso fue elegido. 

(Si quiere más información sobre estos programas, así como sobre otros,
pregunte en el grupo <tt>comp.protocols.ppp</tt> ). 

<sect1>¿ Cuáles son los RFCs que describen el protocolo PPP ?.
<p>

La implementación actual de PPP es una mezcla de varios de ellos. La mayor
parte del código de PPP aparece descrito en los RFCs 1331 y 1332. Estos
RFCs han quedado obsoletos hoy en día. RFC 1331 fue substituido por el RFC
1548 y éste a su vez fue sustituido 6 meses más tarde por el RFC 1661. 

La mayoría de las implementaciones de PPP no tienen porqué tener ningún
problema con la versión PPP de Linux. Para una lista completa, consulte la
PPP FAQ. 

Extraído de la PPP FAQ:

<quote>
Los RFCs 1134, 1171, 1172 (y 1055 para este tema en concreto)  han quedado
obsoletos. Sólo son interesantes si va a conectar con una implementación
"muy antigua" de PPP y no consigue negociar con ella. Por ejemplo, el PPP
remoto le pregunta al suyo por la opción 2 de IPCP con sólo una longitud
de 4 y con un tipo de compresión 0x0037. &nl;
(Todavía existe un montón de todo esto circulando por ahí . Sea cuidadoso
ahí fuera). 
</quote>

Linux, por ejemplo, detectaría esta condición y la corregiría
automáticamente. 

<sect>Compatibilidad.
<p>

<sect1>¿ Puede PPP dialogar con un interface tipo SLIP ?.
<p>

No. SLIP funciona con SLIP y PPP funciona con PPP.

Algunos vendedores ofrecen productos que trabajan tanto con SLIP como con
PPP. Sin embargo, estos paquetes deben de ser configurados para trabajar
bien con SLIP, bien con PPP, pero no con ambos a la vez. Actualmente, no
hay ninguna forma de saber si se está solicitando utilizar PPP o SLIP en
el momento de establecer una comunicación. 

<sect1>¿ Qué es mejor: usar PPP o SLIP ?.
<p>

<em>Depende de muchos factores</em>. Generalmente, las personas que hacen
esta pregunta, no han leído el documento Net-2-HOWTO. Consulte la pregunta
<ref id="consultelo" name="¿ Dónde está la documentación ?.">. 

Una excelente discusión teórica sobre esta cuestión está disponible en
<url url="http://www.mornignstar.com/" name="el servidor WWW de Morning
Star">. 

<sect1>¿ Qué es mejor para la identificación y verificación: CHAP o PAP ?.
<p>

Si puede elegir, use CHAP. Si no le queda más remedio use PAP, es mejor
que nada.<footnote>A lo largo del documento se utilizará el término
"identificación y verificación" en vez del equivalente inglés
"authentification".</footnote>

<sect>Ficheros de identificación y verificación.
<p>

<sect1>¿ Cuál es el formato del fichero <tt>/etc/pap-secrets</tt> ?. ¿ Hay
algún ejemplo disponible ?. 
<p> 

El protocolo de identificación y verificación PAP se usa principalmente
para enviar al sistema remoto su login y su password en ese sistema. Más
concretamente, debe enviar el nombre del sistema remoto, el nombre de su
cuenta en ese sistema y su password. 

Si el usuario en la máquina abbot quiere llamar a costello, la entrada
correspondiente en <tt>/etc/pap-secrets</tt> debería ser: 

<tscreen><verb>
#account	remote		password	IP address list
abbot		*		firstbase
</verb></tscreen>

<sect1>¿ Cuál es el formato del fichero <tt>/etc/chap-secrets</tt> ?. ¿
Hay algún ejemplo disponible ?. 
<p> 

El problema más común es que se suele olvidar que para que CHAP funcione,
<em>AMBOS</em> ordenadores implicados en la comunicación deben de tener su
fichero <tt>/etc/chap-secrets</tt> convenientemente configurado. 

Siguiendo con el ejemplo anterior, si abbot quiere hablar con costello,
entonces el fichero <tt>/etc/chap-secrets</tt> de abbot debe contener

<tscreen><verb>
#remote		local		secret		IP address list
abbot		costello	firstbase	10.10.10.2
costello	abbot		who		10.10.10.1
</verb></tscreen>

Y en la máquina costello <tt>/etc/chap-secrets</tt> debe tener

<tscreen><verb>
#remote		local		secret		IP address list
abbot		costello	firstbase	10.10.10.2
costello	abbot		who		10.10.10.1
</verb></tscreen>

<sect> Problemas de compilación.
<p>

<sect1>Hay errores cuando intento compilar el kernel.
<p>

El paquete con la versión 2.2 de <tt>pppd</tt> contiene las instrucciones
necesarias para que pueda compilar el programa. Brevemente, necesita
ejecutar el comando <tt>configure</tt>. Así se generarán los enlaces
adecuados para el Makefile. Después, haga un <tt>make kernel</tt>. Esto
instalará las nuevas partes del programa que deban ser actualizadas. 

Una vez hecho esto, vuelva a recompilar el kernel. Debe hacerlo incluso si
ya había construído anteriormente otro kernel para soportar PPP. El driver
suministrado con las versiones del kernel 1.2 y las primeras del 1.3 no es
compatible con la versión 2.2 de <tt>pppd</tt>. 

Una vez recompilado el kernel, ya puede seguir compilando <tt/pppd/,
<tt/chat/ y <tt/pppstats/. 

<sect>Problemas al ejecutar <tt>pppd</tt>.
<p>

<sect1><tt>pppd</tt> dice que la versión 0.0.0 está fuera de fecha.
<p>

Está intentando ejecutar la versión 2.2 de <tt>pppd</tt> sin haber vuelto
a recompilar los drivers en el kernel. 

<sect1><tt>pppd</tt> dice que el kernel no está configurado para PPP. Pero
yo estoy seguro de haber habilitado la opción al recompilarlo. 

<p>

Asegúrese de que compiló el kernel y de que lo está ejecutando
actualmente.  Puede ser que lo haya recompilado, pero no lo haya movido al
directorio adecuado donde pueda verlo el gestor de arranque (LILO, por
ejemplo). 

Asegúrese también de que no tiene una copia vieja de <tt>pppd</tt> en su
disco y esté ejecutando esa versión. La versión anterior de <tt>pppd</tt>
se guardaba en <tt>/usr/lib/ppp</tt>. A muchas personas no les gustaba ese
directorio, asi que en la nueva versión 2.2 se ha movido <tt>pppd</tt>,
<tt>chat</tt> y <tt>pppstats</tt> al directorio <tt>/usr/sbin</tt>. Si sus
scripts todavía apuntan hacia <tt>/usr/lib/ppp</tt>, entonces
probablemente esté ejecutando el código antiguo. 

<sect1><tt>pppd</tt> no funciona a menos que sea root.
<p>

El proceso <tt>pppd</tt> requiere hacer algunos cambios en el sistema de
red, y tales cambios sólo debería hacerlos el usuario root. Si quiere que
otro usuario ejecute <tt>pppd</tt>, asegúrese de configurar correctamente
<tt>sudo</tt> para permitir usar <tt>pppd</tt> a dicho usuario. 

<verb>
chmod root pppd
chmod 4755 pppd
</verb>

Si quiere que el acceso a <tt>pppd</tt> esté limitado a un determinado
grupo de usuarios, haga que el proceso <tt>pppd</tt> pertenezca a ese
grupo en concreto y no permita que nadie más pueda ejecutarlo. 

<sect1>Obtengo el mensaje: <tt/unable to create pid file: no such file or
directory/. 
<p>

Necesita crear un directorio denominado <tt>/var/run</tt>. En versiones
anteriores de la distribución Slackware, existía un acceso directo
(symlink) al directorio <tt>/etc</tt>.  En realidad, este mensaje no es un
error, sino un aviso (warning). PPP funcionará correctamente aunque
aparezca este mensaje. Sin embargo, el fichero script <tt>PPP-off</tt>
depende de este fichero para funcionar.  Es una buena idea crear el
directorio antes mencionado o bien crear un acceso directo al sitio
adecuado. 

El fichero de cabezera POSIX <tt>paths.h</tt> define, con el nombre
<tt>_VAR_RUN</tt>, el lugar donde debe de encontrarse este fichero. Si
quiere usar un directorio distinto para PPP y/u otros paquetes, cambie el
valor de este campo y vuelva a compilar el paquete. 

<sect1>Obtengo el mensaje: <tt>/etc/ppp/options: no such file or
directory</tt>. 
<p>

Necesita crear este directorio y dentro de él un fichero llamado
<tt>options</tt>. Necesita, además tener los permisos adecuados para que
pueda ser visible por el proceso <tt>pppd</tt> (root, generalmente). 

Este fichero debería estar vacío. Para crearlo, use el comando
<tt>touch</tt>. 

Para más información sobre la función de este fichero, consulte la página
<tt>man</tt> de <tt>pppd</tt>, <tt>pppd(8)</tt>. 

<sect1>No puedo averiguar cuál es mi dirección IP local.
<p>

Este problema suele aparecer con muchas configuraciones de la Telebit
Netblazer.  El problema no es del servidor de terminal, sino que el
sistema donde se ha instalado no le ha proporcionado un conjunto de
direcciones IP válidas. 

Esto pueden ocurrir por una serie de situaciones:
<itemize>

<item>La tarjeta Netblazer no tiene su dirección IP (la de usted) y usted
no tiene su dirección IP. 

<item>La Netblazer no sabe la dirección IP de su site y usted no sabe la
dirección IP de la Netblazer. 

</itemize>

El enlace no funcionará hasta que ambas direcciones IP esten definidas.

Debe indicarle a la Netblazer la dirección IP a usar. Use la dirección IP
local y la direccion IP remota como parámetros a pasar al proceso
<tt>pppd</tt>.  Esta opción tiene el formato: 

<tt>
pppd local_ip:remote_ip [resto de opciones]
</tt>

(o sea la dirección IP local, dos puntos y la dirección IP remota).

<sect1>No puedo averiguar la dirección IP remota.
<p>

Vea la pregunta anterior.

<sect1>Obtengo mensajes diciéndome que el número mágico no es aceptado.
<p>

Este mensaje aparecerá en su log como "magic number not ACK" o "magic
number NAK". Este es un error grave y PPP no funcionará. 

Hay una probabilidad de una entre 4 billones de que los dos sistemas que
se van a conectar tengan el mismo número mágico. Si obtiene continuamente
fallos de conexión debidos al número mágico, las probabilidades de que
esto sea una coincidencia se reducirán geométricamente. 

Las razones más comunes de este fallo son:

<itemize>

<item>El sistema remoto no está ejecutando PPP y usted piensa que sí lo
está haciendo. ¿ Está seguro de que el sistema remoto ha sido configurado
para ejecutar PPP ?. ¿ Está el proceso PPP en su lugar adecuado ?. ¿ Tiene
los permisos adecuados ?. 

Si ocurre esto, el shell está haciendo un eco de los datos que se le
mandan.  Esta es la causa más comun. 

<item>El módem ha desconectado nada más iniciar la conexión y le ha dejado
conectado con una cuenta en el sistema remoto. La mayoría de los módem
están configurados para hacer un eco de los datos que se les mandan, asi
que lo que usted esta viendo no es más que el eco de los datos que usted
está mandando. 

</itemize>

En cualquiera de los dos casos anteriores, el sistema Linux está enviando
datos al sistema remoto, el cual, a medida que llegan, se los vuelve a
enviar a usted. Esta situación se denomina un lazo (loop en ingles). 

<sect1>Obtengo un mensaje: <tt>protocol reject for protocol fffb</tt>.
<p>

Este mensaje suele aparecer cuando intenta conectar con un servidor de
terminal de la casa Xiplex. Según los fabricantes, la versión 5.1 de su
software tiene numerosos problemas con PPP. A partir de la versión 5.3
estos problemas ya se han solucionado. 

Si usa la versión 5.1 use la opcion <tt>vj-max-slots 3</tt> en la línea de
comandos de <tt>pppd</tt> para limitar el numero de slots a 3. El problema
radica en que el servidor Xiplex acepta peticiones de hasta 16 slots, pero
a partir del tercero no funciona. Si funcionase bien, deberia retornar un
frame del tipo NAK dentro del márgen que hay especificado para ello, pero
el servidor no hace tal cosa. 

Alternativamente, también puede eliminar la compresión de cabeceras Van
Jacobson con la opción <tt>-vj</tt> a pasar a <tt>pppd</tt>. 

<sect1>El software PPP conecta con el sistema remoto, envía unas cuantos
tramas, pero parece como si la conexión no fuese completa. ¿ Qué significa
esto ?. 
<p>

Linux no soporta módems RPI. Si su módem es RPI necesitará otro tipo de
módem para poder usarlo con Linux. Esta situación no tiene visos de
cambiar según la política que mantiene Rockwell. 

Examine el system log que obtiene cuando usa la opción <tt/debug/ en la
línea de comandos de <tt>pppd</tt>. (Necesita el log de todas maneras si
quiere pedir ayuda a alguien). Si el log muestra que se está enviando el
frame LCP-request continuamente y además el número id no se incrementa,
sino que permanece fijo, entonces esto significa que no se están enviando
frames entre su máquina y la máquina remota. 

Las tres causas más comunes de este fallo son las siguientes:

<itemize>

<item>El software PPP no está funcionando en la máquina con la que quiere
conectar. Está enviando tramas PPP a otro software que debe de estar
preguntándose: "¿ Qué es todo este XLSKFDJFpeojd23623 que estoy recibiendo
?". 

Asegúrese de que el sistema remoto está ejecutando PPP antes de que usted
intente conectarse a él. Pruebe a usar un programa de comunicaciones
"normal" y llame hasta que llegue a la secuencia normal de login del
sistema remoto al que se conecte. ¿ Recibe ahora frames PPP ?. 

Los frames de PPP son muy fáciles de identificar. Suelen tener 40
caracteres de longitud y contienen varios caracteres. No tienen un retorno
de carro que separe líneas y se mandan en una secuencia cíclica, con una
pausa entre secuencias. 

<item>La línea serial no está configurada con 8 bits de datos. PPP
requiere que la línea serial esté configurada para 8 bits de datos, sin
paridad y 1 bit de stop. 

Por defecto, el software PPP coloca la linea serial con 8 bits por dato,
sin paridad y un bit de stop. El sistema remoto debe también adoptar esta
configuración. Si no es así, aparecerán errores de paridad (parity) y de
trama (frame). 

PPP ignora caracteres enteros. PPP no es capaz de ignorar bits tal y como
lo hace kermit. PPP no funcionará con un enlace de comunicación de 7 bits
por dato. 

<item> El sistema remoto está configurado para usar algún metodo de
identificación y verificación (CHAP o PAP). Si usted no ha configurado su
sistema con alguno de estos métodos, el sistema remoto ignora cualquier
paquete IPCP de información que se le mande, ya que estará esperando el
paquete de identificación y verificación. 

En cualquier caso la solución consiste bien en deshabilitar la
identificación y verificación en el sistema remoto, bien habilitarla en su
sistema. 

Examine la recepción de las tramas del tipo <tt/LCP configure/ en el log
de la conexión. Si aparece un <tt/auth/ significa que el sistema remoto
requiere identificación y verificación. 

</itemize>

<sect1>El script <tt>/etc/ppp/ip-up</tt> no funciona.
<p>

El proceso <tt>pppd</tt> ejecuta el script <tt>/etc/ppp/ip-up</tt> cuando
la "capa"  del protocolo IP se ha establecido correctamente. <tt>pppd</tt>
y el protocolo IP le proporcionan al script los parámetros que definen el
status de la línea (nombre del dispositivo de conexión, velocidad de
comunicación y dirección IP). 

Sin embargo, lo que puede parecer confuso es que se trata a
<tt>/etc/ppp/ip-up</tt> como a un programa ejecutable y no como a un
script. El programa se "lanza" mediante la función <tt/exec/ de Linux. 

Esto quiere decir que si desea utilizar este script debe de hacer dos cosas:

<itemize>

<item>Necesita tener el fichero marcado como ejecutable. Haga esto con
<tt/chmod/.  Los permisos correctos de funcionamiento deberían ser de 100.
Usando <tt/chmod/ con un valor de 500 es aceptable si va a leer del
fichero, o bién usar el valor de 700 su va a escribir en él. Este fichero
debería ser usado por el usuario root. 

<item>El fichero debe tener como primera línea:

<tscreen><verb>
  #!/bin/sh
</verb></tscreen>

El caracter &num; debe ser el primer caracter de la primera línea del
fichero.  El intérprete de este script (<tt>/bin/sh</tt> en este caso)
puede ser cualquier programa que pueda ser utilizado para ejecutar
scripts. La mayoría de la gente utiliza el shell Bourne <tt/sh/, pero
pueden usarse otros como el C shell <tt/csh/ o incluso <tt/perl/. Lo
realmente importante es que los dos primeros caracteres sean &num; y !
respectivamente. 

</itemize>

<sect1>No puedo conectar con la red merit.
<p>

Algunos usuarios de esta red han señalado que es necesario utilizar PAP
para conectar con esta red. ¿ Ha probado a activar esta opción ?. 

<sect>DIP
<p>

<sect1>DIP no tiene soporte para ejecutar PPP.
<p>

La versión más actual de dip-uri si soporta el uso de PPP, ya que
utilizando la opción <tt/mode PPP/, <tt/dip/ lanzará el proceso <tt/pppd/
automáticamente. Sin embargo, <tt/pppd/ necesita ser invocado con varias
opciones para poder funcionar correctamente. Como <tt/dip/ no pasa estas
opciones a <tt/pppd/, dichas opciones deben de estar almacenadas en el
fichero <tt>/etc/ppp/options</tt>. 

<tt/dip/ es un programa que controla el establecimiento de una conexión
SLIP entre máquinas con la ayuda de otros programas: <tt/slattach/,
<tt/ifconfig/ y <tt/route/.  Todos estos programas deben ser utilizados
para lograr una conexión SLIP válida, sin embargo, no son necesarios para
realizar una conexión PPP. 

<tt/dip/ puede ser usado para efectuar la llamada telefónica y arrancar el
software PPP en el sistema remoto. Para utilizarlo en este modo, es mejor
usarlo como un parámetro a pasar con la opción <tt/connect/. Sin embargo,
usted tiene la opción de permitir que <tt/dip/ controle el enlace. Es
indiferente como <tt/pppd/ sea ejecutado, lo que si es realmente
importante es que debe ser ejecutato <em/obligatoriamente/, ya que es un
programa imprescindible para el protocolo PPP. 

<sect>Terminación del proceso.
<p>

<sect1>¿ Existe un comando similar a <tt>dip -k</tt> para PPP ?.<label
id="dip-k">
<p>

No. En el directorio de <tt>chat</tt> hay un <tt>PPP-off</tt> script.
Ejecutando este script se consigue el mismo efecto que con <tt>dip
-k</tt>.  Este script aparece a continuación. Para usarlo, corte el texto,
sálvelo en el fichero nombrado arriba y hagalo ejecutable con
<tt>chmod</tt>. 

<tscreen><verb>
  #!/bin/sh
  DEVICE=ppp0
  #
  # Si el fichero ppp0 pid existe es que el programa esta funcinando. Paralo.
  if [ -r /var/run/$DEVICE.pid ]; then
          kill -INT 'cat /var/run/$DEVICE.pid'
  #
  # Si kill no ha funcionado entoces no hay ningun proceso asociado a este
  # pid. Tambien puede significar que el fichero lock sigue abierto. Seria deseable
  # borrar tambien el fichero lock.
          if [ ! "$?" = "0" ]; then
                  rm -f /var/run/$DEVICE.pid
                  echo "ERROR: Removed stale pid file"
                  exit 1
          fi
  #
  # OK. Ahora dejamos a pppd terminar a su manera.
          echo "PPP link to $DEVICE terminated."
          exit 0
  fi
  #
  # el proceso PPP no esta ejecutandose para ppp0
  echo "ERROR: PPP link is not active on $DEVICE"
  exit 1
</verb></tscreen>

<sect1>PPP no cuelga el módem cuando termina.<label id="modem_no_cuelga">
<p>

Hay varias razones para que ocurra esto:

<itemize>

<item>¿ Especificó la opción <tt/módem/ en la línea de comandos de
<tt/pppd/ ?. Este parámetro controla si es <tt/pppd/ el que debe controlar
las señales de status del módem. Este parámetro aparece explicado más
detalladamente en la página <tt/man/ de <tt/pppd/.

<item>¿ Tiene el módem configurado para usar las señales DCD y DTR ?. La
secuencia Hayes para el módem es normalmente <tt>&amp;C1</tt>. Si resetea
el módem durante la sesión con <tt>ATZ</tt>, asegúrese de que configura su
módem correctamente. 

La señal DTR la genera el ordenador e indica al módem cuando desconectar.
La secuencia Hayes para esto es <tt>&amp;D1</tt> o <tt>&amp;D2</tt>,
siendo <tt>&amp;D2</tt> la opción preferida por PPP. Muchos fabricantes de
módems deshabilitan este uso de la señal DTR en la configuración de
fábrica que viene almacenada en el módem . 

<item>¿ Está utilizando un cable barato que no conecta la senal DCD entre
el ordenador y el módem ?. Los cables de los ordenadores Machintosh
"Classic"  son un ejemplo. Estos ordendadores no usan esta señal. 

<item> Para conexiones a una cuenta en un sistema remoto, ¿ lanza la
ejecución de <tt/pppd/ de forma correcta ?.  El proceso <tt/pppd/ debería
ser lanzado (con <tt/exec/) desde un script y no desde la línea de
comandos del shell que esté usando. Si hace esto último y ejecuta
<tt/pppd/, será el shell el que reciba la señal HUP (hang-up, colgar) y no
<tt/pppd/. 

Un script típico para lanzar <tt/pppd/ es el siguiente:

<code >
#!/bin/sh
exec pppd -detach modem ...
</code>

<item>El uso conjunto de de <tt/dip/ y <tt/diald/ puede interferir en
algunas ocasiones con la capacidad de <tt/pppd/ para detectar la falta de
portadora de la línea serial. En esta situación, debería usar las opciones
<tt/lcp-echo-request/ y <tt/lcp-echo-failure/ para que <tt/pppd/ pueda
detectar esta condición. 

</itemize>

<sect>Transferencia de datos.
<p>

<sect1>¿ En las transferencias con ftp, parece que la conexion <em/muere/
cuando hago un <tt/put/. Sin embargo, si hago <tt/get/ funciona
perfectamente. ¿ Qué ocurre ?. 
<p>

¿ Está activado el control de flujo (flow control) ?. Esto se hace pasando
a <tt/pppd/ la opción <tt/crtscts/ para usar control de flujo RTS/CTS
(hardware) o <tt/xonxoff/ para control de flujo XON/XOFF (software). Si no
tiene habilitado el control de flujo, probablemente está sobrescribiendo
en los buffers del módem. Esto tiene consecuencias catastróficas si
utiliza compresión de cabezeras vj (Van Jacobson). 

<sect1>¿ Cómo debo usar el control de flujo XON/XOFF ?.
<p>

Es mejor utilizar control de flujo hardware (CTS/RTS). Sin embargo, si se
ve obligado a usar control de flujo software, siga los siguientes pasos: 

<itemize>

<item>Necesita especificar la opción <tt/xonxoff/ en la línea de comandos
de <tt/pppd/. Esta opción le dice al dispositivo serial a utilizar que
utilice este tipo de control de flujo. Además, carga los dos caracteres
(XON y XOFF) dentro del driver tty. 

<item>Necesita especificar los caracteres que representan XON y XOFF en el
parámetro <tt/asyncmap/ que se pasa a <tt/pppd/. Esto avisa al sistema
remoto que debe <em/separar/ estos caracteres cuando quiera enviárselos a
su máquina. Esto se indica normalmente con la opción <tt/asyncmap a0000/. 

<item>Naturalmente, no olvide decirle a su módem que utilice control de
flujo XON/XOFF. En los módem ZyXEL, se suele utilizar la secuencia
<tt>"R1&amp;H4"</tt>. 

</itemize>

<sect1>¿ El módem parece que conecta a velocidades extrañas. Cuando uso
<tt/minicom/, el módem siempre usa 14400 bits/segundo. Sin embargo, PPP
dice que está conectando a 9600, 7200 e incluso a 2400 bits/segundo. ¿
Cómo puedo corregir esto ?. 
<p>

Especifique la velocidad que desea en la línea de comandos de <tt/pppd/.
Si no especifica la velocidad, PPP utilizará cualquier velocidad que
exista.  Algunos programas no dejan los parámetros de la línea serial
iguales que cuando se ejecutaron. Esto puede causar que la línea tenga una
configuración <em/extraña/. 

Linux no soporta módems que utilizan RPI (Rockwell Protocol Interface)
porque es un protocolo propietario. Dado que Rockwell no quiere facilitar
el código necesario para poder hacer una adaptación a Linux, hay muy pocas
posibilidades de ques estos módem sean soportados por Linux. La solución
en este caso es clara: no usar módems RPI. 

Si no sabe si un módem es RPI cuando quiera adquirirlo, fíjese en las
frases publicitarias que aparecen en la caja. Frases del estilo "con
corrección de errores software", o "compatible con Windows" o "requiere un
driver especial para funcionamiento completo", usualmente suelen indicar
que el módem es RPI. 

<sect1>Cuando hago ftp, la operación <tt/get/ es muy lenta, pero la
operación <tt/put/, sin embargo, es muy rápida. ¿ Porqué ?. 
<p>

¿ Especificó la opción <tt/asyncmap 0/ cuando ejecutó <tt/pppd/ ?. Si
olvidó esto, el peer debe <em/doblar/ todos los caracteres de control en
el rango <tt>0x00..0x1F</tt> (hexadecimal).  Esto supone una reducción de
velocidad de un 12.5 % cuando está recibiendo datos. 

¿ Ha configurado bien el sistema remoto ?. ¿ Olvidó especificar el control
de flujo del módem remoto ?. 

<sect1>La opción <tt/proxyarp/ no encuentra la dirección hardware.
<p>

Use el paquete <tt/ppp-2.1.2d.tar.gz/. El proceso <tt/pppd/ fué compilado
erróneamente con el kernel 1.1.8 y usaba definiciones Net-3 en vez de la
Net-2 como le correspondía. 

Consulte ademas el mini HOWTO proxy-ARP sobre los requerimientos
necesarios para utilizar proxy ARP. 

El paquete 2.1 tiene establecido un límite de 64 dispositivos de red.
Cuando se escribió el código de <tt/proxyarp/ se pensó que era un número
razonable, dado que la mayoría de la gente suele tener uno o dos
controladores Ethernet como máximo en una máquina. Hoy en día hay máquinas
que tienen conectados hasta 128 dispositivos de red. 

La versión 2.2 ha elevado el límite a 256 dispositivos de red. Este límite
aparece en forma de un <tt/&num;define/ que se encuentra en el módulo
<tt/sys-linux.c/. 

<sect>Rutado y otros problemas.
<p>

<sect1>¡ Mi ruta al sistema remoto sigue desapareciendo !. Estuvo activa
unos 3 minutos y ha vuelto a desaparecer. ¡ Ayuda !. 
<p>

Esta no es una pregunta que esté relacionada con PPP.

Pista: ¡ <em>NO EJECUTE</em> <tt>routed</tt> !.

<sect1>¿ Me gustaría conectar los ordenadores de mi red a Internet usando
PPP. Sólo tengo una dirección IP que me es asignada por mi proveedor de
servicios de conexión (incluso esa dirección IP es asignada
dinámicamente). ¿ Cómo puedo hacer esto ?. 
<p>

No se puede. Al menos no de la manera que a usted le gustaría hacerlo
normalmente. El problema reside en que su proveedor no sabría las
direcciones IP de las máquinas conectadas a su red y, por tanto, no
rutaría ninguna trama a su sistema local. 

Sin embargo, existen otras soluciones:

<itemize>

<item>Puede hacer un <tt/telnet/ a la máquina que está conectada a
Internet usando <tt/pppd/. Una vez conectado a esa máquina, ya puede hacer
<tt/telnet/ o <tt/ftp/ al resto de Internet. Realmente, esto no es mucho
mejor que usar el ordenador directamente, pero es útil para realizar cosas
sencillas. 

<item>Use un kernel reciente de la serie 1.3 y utilice la opcion <tt/IP
Masquerade/. Para saber más sobre cómo usar esta característica, debería
unirse a la lista de correo electrónico <tt/linux-net developer/ o bien
consultar el documento <tt/Net-2-HOWTO/. 

<item>Ejecute el programa <tt/socks/ en su sistema PPP. Este programa
realizará la misma función que si usa <tt/IP Masquerade/ pero, por contra,
necesitará clientes modificados. La ventaja de usar <tt/socks/ es que este
programa lleva mucho tiempo circulando por ahí y muchos clientes
entenderán el concepto de servidor <em/proxy/ (<tt/proxy server/) que es
necesario para trabajar correctamente con el programa. 

</itemize>

<sect1>Conecto con la máquina del sistema remoto, pero no puedo hacerlo
con ninguna otra máquina de dicho sistema. 
<p>

¿ Ha olvidado añadir el parámetro <tt>defaultroute</tt> a la línea de
comandos de <tt>pppd</tt> ?. Este parámetro añade una ruta por defecto
(default route) a su sistema de rutado, permitiendo que los frames
dirigidos a otras direcciones IP se canalicen a través del dispositivo
PPP. 

El software PPP no reemplazará la ruta por defecto si ya existía una
anterior a la ejecución de <tt>pppd</tt>. El motivo de esto es evitar que
alguien pueda destruir accidentalmente la ruta por defecto a sus routers
ethernet. Un aviso aparecerá en el system log si <tt>defaulrotute</tt> no
se ejecuta por esta razón. 

<sect1>Tengo una ruta por defecto pero sigo sin poder acceder al resto de
máquinas. ¿ Y ahora que hago ?. 
<p>

El problema no es entonces de su sistema Linux local. Lo más probable es
que haya un problema de rutado en la máquina remota. 

El sistema remoto no está configurado para <tt/IP forwarding/. En el RFC
de PPP se especifica que esta opción <em>NO</em> debe estar activada por
defecto.  Esta opción debe habilitarse. Para sistemas Linux, necesita
volver a compilar el kernel y especificar que desea <tt>IP
forwarding/gatewaying</tt>. 

El ordenador remoto necesita una ruta hacia su máquina de la misma manera
que usted necesita una ruta hacia él. Esto puede hacerse por uno de los
cuatro métodos siguientes. Cada uno tiene sus ventajas y sus
inconvenientes y recuerde que sólo puede usar un metodo y sólo uno. 

<itemize>

<item>Use una ruta de host (host route). En cada host del sistema remoto,
añada una ruta a la dirección IP de su máquina Linux, siendo el gateway la
máquina que usted usa para conectar con ese sistema. Esto es adecuado si
el sistema remoto tiene pocas máquinas conectadas y usa una red simple,
sin bridges, routers, gateways, etc. 

<item>Use una ruta de red (network route). Divida la dirección IP remota
de tal manera que la dirección IP local de su máquina Linux, la de la
máquina remota con la conecta usando PPP y la de la tarjeta Ethernet que
conecta esta máquina con el resto de su red pertenezcan al mismo dominio. 

Esto funciona si tiene suficientes direcciones IP para poder repartirlas.
Si tiene un dominio de direcciones IP de red de clase B, esta solución
funciona muy bien, puesto que puede poner todas las direcciones de las
máquinas remotas en el mismo dominio de direcciones IP. 

Una vez hecho esto, añada una ruta de red en cada uno de los gateways y
routers, de tal forma que cualquier dirección de la red remota sea enviada
al servidor de terminal. La mayoría de las configraciones de redes locales
tienen muchos hosts pero pocos routers. (Por ejemplo, en sii.com, hay unos
300 hosts activos con solo 3 routers). 

<item>Use <tt/gated/ en todos los gateways y en el servidor de terminal.
Con esto se consigue que el servidor de terminal <em/propague/ (broadcast)
los frames para su dirección IP a los gateways adecuados. Como los hosts
tendrán una ruta por defecto a uno de los gateways, este gateway generará
una trama de redirección ICMP y el host específico añadirá automáticamente
su propia ruta de host. 

<item>Utilice proxy ARP en el servidor de terminal. Esto sólo funcionará
si su dirección IP remota está en el mismo dominio de direcciones IP que
uno de los dominios de las tarjetas de red del sistema remoto.  </itemize>
No hay solucion "exacta". Debe elegir la que mejor se adapte a sus
circunstancias. 

Si su router remoto necesita recibir tramas RIP para poder actualizar la
ruta hacia su sistema, entonces debería usar el programa <tt/bcastd/ de
<tt/sunsite.unc.edu/. Este programa genera las tramas RIP sin necesidad de
que tenga que instalar y ejecutar <tt/gated/. 

<sect1>No puedo hacer <tt/ping/ a mi dirección IP local.
<p>

No puede hacer esto porque normalmente no tiene definida una ruta hacia
esa dirección. Este es el modo normal de funcionamiento, asi que no hay
nada anormal.  Si quiere hacer un <tt/ping/ a su sistema, utilice la
dirección del dispositivo loopback (127.0.0.1). 

Puede hacer un ping a la direccion IP remota, si así lo desea. Sin
embargo, algunos servidores de terminal no permitirán esto, ya que esa
dirección esta ocupada <em/telefónicamente/ para ellos. Esto depende de la
configuración específica de cada servidor .  En general, no haga <tt/ping/
a ninguna de las 2 direcciones ( local o remota ). Elija una dirección IP
de otra máquina que sepa que está en la red remota (una de su nameserver,
por ejemplo). 

Mientras el software PPP no haga esta tarea, debe de añadir manualmente a
la tabla de rutado la ruta al host con el que acaba de conectar. Esto se
hace con el comando

<verb>
route add -host 192.187.163.32 lo
</verb>

Donde la dirección IP local es 192.187.163.32 en este ejemplo. Esto le
dice al software de red que debe dirigir todas las tramas destinadas a su
dirección IP al dispositivo loopback. Una vez que ha añadido la ruta
apropiada a la dirección IP local, entonces ya puede usar esta dirección
como el destino para las tramas IP. 

Usted es el responsable de eliminar esta ruta cuando el enlace termine.

<sect>Interacción con otras implementaciones de PPP.
<p>

<sect1>Estoy usando Trumpet (para MSDOS) y la conexión simplemente
termina. ¿ Porqué ocurre esto ?. 
<p>

Trumpet no acepta ningún tipo de compresión de cabeceras VJ. Utilize
<tt/pppd/ con la opción <tt/-vj/ para desactivar esta compresión. 

<sect1>Estoy usando <tt/dp-3.1.2/ (con SunOS) y el sistema no me permite
hacer nada más que <tt/ping/ o <tt/nslookup/. ¿ Porqué ocurre esto ?. 
<p>

Existe un fallo en la versión 3.1.2 de <tt/dp/. Actualícese a la versión
3.1.2a o posterior. Puede conseguirla en el <url
url="http://www.ecn.purdue.edu" name="home site de dp">. 

Hasta que consiga esta actualización, no utilice compresión de cabeceras
VJ. 

<sect1>No puedo conectar con/desde mi máquina con Windows NT.
<p>

Microsoft ha elegido para Windows NT un sistema no estandar de
identificación y verificación. Están en su derecho, ya que han registrado
su propio protocolo en la IANA. Si en la casilla "accept only Microsoft
encrypted authentication" está activada en la entrada "phone book",
entonces la conexión no podrá realizarse. Esta opción le indica a Windows
NT, que sólo puede comunicarse con otro sistema que tenga implementado el
protocolo PPP propio de Microsoft (otro sistema Windows NT). 

Linux no soporta este tipo de identificación y verificación.  Si puede
cambiar las opciones del sistema de su Windows NT, vaya a las opciones de
Windows NT Phone Book, eliga advanced, luego security settings y asegúrese
de que la casilla "Accept any authentication including clear text" está
activada y que la casilla "accept only Microsoft encrypted authentication"
no está activada. El resto de casillas del cuadro de dialogo no influyen
en este tema. 

Una vez hecho esto, utilice PAP en su máquina Linux y ponga el login y el
password de la máquina Windows NT en el fichero habitual
<tt//etc/ppp/pap-secrets/. 

La secuencia de identificación y verificación de Microsoft es una variante
del sistema PAP con el password protegido por un sistema de criptografiado
del tipo DES. El sistema PAP normal envía las password sin encriptar, lo
cual supone una violacion de seguridad dentro del sistema de seguridad que
Microsoft ha elegido (tipo C2). 

Versiones anteriores del código de PPP a la 2.1.2c tienen un fallo en el
sistema de decodificación de las peticiones de identificación y
verificación. Una comunciación entre un sistema Windows NT y esta versión
no podrán nunca negociar. La versión actual, 2.2 o la 2.1.2d (si necesita
el soporte para la serie de kernels 1.1) deberían ser usadas en esta
situación

Segun Scott Hutton (<tt/shutton@habanero.ucs.indiana.edu/): 

Básicamente, NT RAS (Remote Access Services) terminará la conexión si su
máquina rechaza (REJ) algún componente del protocolo que sea crítico (i.e.
el protocolo de identificación y verificación). El truco consiste en crear
un fichero chap-secrets de lo mas simple. El mio es: 

<tscreen><verb>
*	""	""
</verb></tscreen>

Esto le dice a pppd que debe enviar un NAK (no aceptado) en vez de un REJ
(rechazado). Con la clave de registro (registry key) SPAP eliminada, el
siguiente protocolo a probar es PAP (que es el que yo uso). 

Otras personas afirman que SOLO los servicios de red TCP/IP deben estar
habilitados en el RAS (ni NetBEUI ni IPX (Ed: IPX está comprobándose
ahora.  Hasta que esté instalado convenientemente, es una buena idea
deshabilitarlo.)). También he tenido que batallar con un montón de claves
de registro (registry keys) para eliminar timeouts (que son problemáticos
cuando sólo se quiere usar TCP/IP): 

<tscreen><verb>
  HKEY_LOCAL_MACHINE\eSYSTEM\eCurrentControlSet\eServices\eRemoteAccess\eP
           Autodisconnect: REG_DWORD: 0
</verb></tscreen>

  y para conseguir que el rutado funcione correctamente:

<tscreen><verb>
  HKEY_LOCAL_MACHINE\eSYSTEM\eCurrentControlSet\eServices\eRasArp\eParamet
           DisableOtherSrcPackets: REG_DWORD: 0
</verb></tscreen>

  Para finalizar, la clave a eliminar para eliminar SPAP es:

<tscreen><verb>
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\SPAP
</verb></tscreen>

<sect>Otros mensajes enviados al system log.
<p>

<sect1>Alarm.
<p>

Esto no es un problema, aunque su nombre lo parezca. Sólo significa que un
temporizador (timer) ha concluido su cuenta. Los temporizadores son una
parte necesaria durante la fase de establecimiento del protocolo. 

<sect1>SIGHUP.
<p>

El proceso <tt/pppd/ ha recibido una señal HUP. La señal HUP se genera por
el software que controla el dispositivo tty cuando el dispositivo remoto
al que se estaba conectado ha terminado el enlace a través del módem. Esto
significa que el módem ha colgado ("hang up" en inglés) la conexión.  El
programa <tt/kill/ también puede ser usado para enviar esta señal al
proceso <tt/pppd/.  Cuando <tt/pppd/ recibe esta señal, empieza la
secuencia de finalización del enlace de una manera ordenada. 

<sect1>SIGINT.
<p>

El proceso <tt/pppd/ ha recibido una señal INT. Esta señal la genera el
software que controla la consola cuando se pulsa un CTRL+C y <tt/pppd/ se
está ejecutando como un proceso de segundo plano (background).  Igualmente
<tt/kill/ también puede generar esta señal para el proceso <tt/pppd/.  De
hecho, esta es la forma <em/educada/ de finalizar la ejecución de
<tt/pppd/ y terminar con el enlace. Vea la pregunta referida a <tt/dip -k/
(pregunta <ref id="dip-k" name="¿ Existe algún comando similar a <tt>dip
-k</tt> para PPP ?.">) para ver un script que realiza esta función.  De la
misma manera que con SIGHUP, <tt/pppd/ termina con el enlace de una manera
ordenada. 

<sect1><tt/Unknow protocol (c025) received/.
<p>

El sistema remoto desea utilizar el protocolo Lynk Quality Reporting con
su sistema Linux. Este protocolo no está soportado por la versión actual
de PPP para Linux. Esto no es un error, sólo indica que el sistema remoto
está enviando una invitación a usar este protocolo y Linux le responde con
un delicado: "No puedo hacer lo que me pides ahora, asi que no me marees
más con esto". 

El paquete PPP de Morning Star Software siempre intentará utilizar este
protocolo LQP. Esto es normal y no significa que el enlace no pueda
realizarse o sea erróneo. 

<sect1><tt/Unknow protocol (80fd) received/.
<p>

El sistema remoto quiere utilizar el protocolo de control de compresión
(Compresion Control Protocol) con su sistema Linux. Este protocolo se
situa "por encima" del protocolo básico y, si se negocia correctamente, se
obtiene una reducción del número de bytes transmitidos en cada trama.  O
sea, que la transmisión es más rápida. 

Sin embargo, existen un buen número de compresores que pueden agruparse
bajo el tármino de Compression Control Protocol. La versión 2.2 del
paquete PPP sólo entiende uno: el compresor BSD. Este compresor funciona
de forma muy parecida a como lo hace el programa <tt/compress/ de UNIX y
utiliza una compresión del tipo LZW.  Dependiendo del tamaño del código,
puede ser necesario una gran cantidad de espacio del kernel para
incorporar los diccionarios de compresión y descompresión necesarios. Esto
no debería ser utilizado si su máquina tiene un espacio limitado de
memoria (ni siquiera lo intente si tiene 8 megabytes o menos de RAM
física). Para estos casos, debería adquirir un módem decente que soporte
este tipo de compresión. 

A menos que los dos extremos del enlace acepten este tipo de compresión,
ésta no se utilizará en la conexión. 

Otro tipo común de compresor es Predictor-1. Necesita menos memoria y se
ejecuta más rápido. Sin embargo, su compresión no es tan buena como el de
BSD, ya que envía unos pocos más de bytes por cada trama. 

Muchos servidores de terminal comerciales utilizan un compresor denominado
Stacker(TM) LZW o Protocolo LZS. Este tipo de compresor es comercial y
requiere una licencia de uso. Aparentemente, Stacker le puede dar a usted
esa licencia gratis, pero existe otra licencia más específica que le
impide utilizar este tipo de compresión junto con <tt/pppd/. 

<sect1>La conexión falla con errores como <tt>ioctl(TIOCGETD): I/O
error</tt> o <tt>ioctl(PPPIOCSINPSIG): I/O error</tt>. 
<p>

Examine los mensajes que aparecen cuando arranca el sistema. Si aparece el
mensaje <tt/PPP version 0.1.2/ es que tiene una versión antigua del driver
<tt/PPP.c/. 

Si aparece <tt/PPP version 0.2.7/, entonces tiene una versión actualizada
de <tt/PPP.c/ para el paquete 2.1.2. Sin embargo, este fichero no fué
compilado con el mismo conjunto de números de ioctl. Asegurése que sólo
tiene un fichero llamado <tt/if_ppp.h/. Debería estar situado en el
directorio donde están los ficheros include del kernel de linux. Una vez
hecho esto, vuelva a compilar el kernel y el proceso <tt/pppd/. 

Si aparece <tt/PPP version 2.2.0/ entonces está usando el driver
correspondiente a la versión 2.2 del paquete. Esta versión del driver solo
funciona con las versiones 2.2 del paquete <tt/pppd/. El programa
<tt/pppd/ versión 2.2 sólo funcionará con esta versión del driver. 

<sect1>Ocurren errores del tipo <tt>ioctl(PPPIOCGDEBUG): I/O error</tt>,
<tt>ioctl(TIOCSETD): I/O error</tt> o <tt>ioctl(TIOCNXCL): I/O error</tt>.
¿ Porqué ocurre esto ?. 
<p>

El sistema remoto ha desconectado el teléfono. Los drivers tty intentan
reestablecer la disciplina de conexión que tenían antes de perder la
línea. A la vez, <tt/pppd/ intenta hacer lo mismo que estos drivers tty
para poder recuperar la conexión.  Cuando se produce esta situación es
normal que estos errores aparezcan. 

<sect1><tt/ifconfig/ me proporciona una información extraña con PPP.
<p>

Normalmente, <tt/ifconfig/ proporciona una información parecida a esta:

<tscreen><verb>
   ppp0      Link encap UNSPEC  HWaddr 00-00-00-00-00-00-00 ...
             inet addr 192.76.32.2  P-t-P 129.67.1.65  Mask 255.255.255.0
             UP POINTOPOINT RUNNING  MTU 1500  Metric 1

</verb></tscreen>

Este mensaje aparece sólo con propósitos informativos. Si usa una versión
reciente del kernel, actualice el paquete <tt/nettools/ por el de
<tt><htmlurl url="http://sunacm.swan.ac.uk/pub/Linux/networking/nettools" 
name="http://sunacm.swan.ac.uk/pub/Linux/networking/nettools"></tt>. 

<sect1>El fichero <tt>proc/net/dev</tt> parece que esta vacío.
<p>

¿ Tecleó el comando <tt>ls -l /proc/net</tt> y se está preguntando cómo
puede ser que tenga un tamaño de 0 bytes ?. Si es así, no se preocupe
porque es normal. En vez de eso teclee: 

<tt>cat /proc/net/dev</tt>

Ahora no debería de estar vacío. El hecho de que la longitud del fichero
sea cero se debe a que se encuentra en un sistema de ficheros del tipo
"proc". De la misma manera, usar <tt/more/, <tt/less/ o <tt/most/ tampoco
deben usarse para visualizar este fichero. Si quiere un resultado similar
haga

<tt>cat /proc/net/dev | less</tt>

<sect1>El kernel informa que los dispositivos PPP están siendo
"desactivados" cuando el sistema empieza a arrancar. 
<p>

Esto no es un problema. Este mensaje es el resultado de la llamada que
hace el driver de PPP al procedimiento <tt/unregister_netdev/. Esta
llamada permite al driver de PPP solicitar dinámicamente el número de
dispositivos que sean necesarios. No hay un límite real sobre el número de
ellos a crear. Por poner un límite, se ha elegido el valor de 256
dispositivos. Si encuentra que este número es pequeño, entonces debe
cambiar el <tt>#define</tt> que se encuentra en el fichero <tt/ppp.c/ y
poner el valor que desee. Este será el número de dispositivos que serán
cargados dinámicamente. 

<sect1>Acabo de comprobar que <tt>/proc/net/dev</tt> no tiene ningún
dispositivo PPP. ¿ Donde están ?. 
<p>

No están en ningún sitio. Fueron desconectados durante el arranque del
sistema. Vea la pregunta anterior para más información. 

<sect>Rutado con redes locales (usando PPP como un "bridge" económico).
<p>

<sect1><tt>Slattach</tt> e <tt>ifconfig</tt> no funcionan como con SLIP.
<p>

No utilice <tt/slattach/ ni <tt/ifconfig/ con PPP. Estos programas se usan
con SLIP. El proceso <tt/pppd/ realiza las funciones de estos programas en
el momento adecuado. Estas funciones deben realizarse después de que se
hayan intercambiado los protocolos LCP e IPCP entre las máquinas que
realizan la conexión. 

Usted no puede reemplazar <tt/ifconfig/ y <tt/slattach/ por <tt/pppd/. La
mayoria de los protocolos que se usan con PPP residen dentro del código de
<tt/pppd/. Sólo el protocolo IP ( y el IPX cuando esté terminado ) residen
dentro del kernel. 

La ruta de host (host route) al sistema remoto la añade automáticamente
<tt/pppd/. No hay ninguna posibilidad de no añadir esta ruta. El proceso
<tt/pppd/ terminará si no puede definirla y añadirla a la tabla de rutas
del sistema. 

La ruta por defecto (default route) puede ser o no añadida. Esto se
controla con la opcion <tt/defaultroute/. Si ya existía una ruta por
defecto anterior, <tt/pppd/ no definirá una nueva, sino que conservará la
ya existente. 

Si quiere gobernar el rutado para una red entera, ponga el comando
<tt/route/ dentro del script <tt>/etc/ppp/ip-up</tt>. Los parámetros de
este script son: 

<itemize>
<item>&dollar;0 : nombre del script que se esta ejecutando
(<tt>/etc/ppp/ip-up</tt> o <tt>/etc/ppp/ip-down</tt> ).
<item>&dollar;1 : nombre del dispositivo de red (<tt/ppp0/ por ejemplo).
<item>&dollar;2 : nombre del dispositivo tty (<tt>/dev/cua0</tt> por ejemplo).
<item>&dollar;3 : velocidad del dispositivo tty en bits por segundo (14400 por
ejemplo).
<item>&dollar;4 : la dirección IP local (en formato xxx.yyy.zzz.vvv).
<item>&dollar;5 : la direccion IP remota (en formato xxx.yyy.zzz.vvv).
<item>&dollar;6 : el valor del parámetro <tt/ipparam/.
</itemize>

<sect1>Quiero definir una ruta a la red entera y no sólo a un host de esa red.
<p>

Existe en <tt/sunsite/ un paquete llamado <tt/devinfo.tar.gz/ que contiene
una serie de pequeñas utilidades que extraen datos sobre el dispositivo de
red que se esté usando y, junto con las direcciones IP del enlace,
proporcionan informaciones muy útiles.  La documentación se encuentra en
las páginas <tt/man/ del paquete. 

Por ejemplo, si quiere rutar el dominio entero de direcciones IP en la red
remota, haga lo siguiente en el script <tt>/etc/ppp/ip-up</tt>.
Naturalmete, si los valores no son variables sino fijos, entonces
simplemente use esos valores en las entradas apropiadas del comando
<tt/route/. 

<tscreen><verb>
  # Obtener la mascara de red (netmask) para el dispositivo ppp0 (o cualquier otro).
  NETMASK = "devinfo -d $1 -t mask"
  # Obtener el dominio IP (sin la direccion del host eliminando los bits extra)
  DOMAIN = "netmath -a $5 $NETMASK"
  # Creamos la network route ahora que ya se sabe el dominio IP
  route -net add $DOMAIN gw $5
</verb></tscreen>

<sect>Otras características y protocolos.
<p>

<sect1>¿ Existe soporte para <tt>demand dial</tt> ?.
<p>

Utilice el paquete <tt><htmlurl
name="ftp://sunsite.unc.edu/pub/Linux/system/Network/serial" 
url="ftp://sunsite.unc.edu/pub/Linux/system/Network/serial"></tt>. Está en
<tt>sunsite</tt>, en el mismo directorio que el código fuente de PPP.

<sect1>¿ Existe soporte para filtrado (<tt>filtering</tt>) ?.
<p>

No hay intención de implementar filtrado dentro del código de PPP.  La
versión 1.3 del kernel soporta una opción <tt/firewall/ que debría usar en
vez de buscar un método de embutir la lógica de funcionamiento de un
cortafuegos (firewall) dentro de un dispositivo de red. Puede usar bien
<tt/ipfw/, bien <tt/ipfwadm/ para definir las reglas que gobiernan el
funcionamiento del cortafuegos que está dentro del kernel. 

<sect1>¿ Existe soporte para IPX ?.
<p>

El soporte IPX sería muy fácil de implementar. Esto se está haciendo en la
actualidad, gracias, sobre todo, al apoyo de <url
url="http://www.caldera.com" name="Caldera">. 

<sect1>¿ Existe soporte para NetBIOS ?.
<p>

Hay definido un protocolo PPP para NetBIOS. Sin embargo, la solución
óptima consiste en usar TCP/IP y la aplicación <tt>samba</tt>. 

Microsoft y otras compañías han usado el protocolo PPP de NetBIOS.

El protocolo nbfcp y su documentación son de libre acceso y puede
obtenerse de numerosas fuentes. El protocolo NetBIOS no es una familia de
protocolos válidos actualmente para Linux. Hasta que Linux lo soporte, no
hace mucha falta el soporte de NetBIOS en el PPP de Linux. 

<sect1>¿ Existe soporte para ISDN ?.
<p>

Para que se soporte ISDN se necesita un driver ISDN que funcione. El
diseño actual del driver PPP no se adapta bien al concepto ISDN de
recepción de bloques de datos. Esto está cambiando. Un driver para el
interfaz Sonix se está desarrollando actualmente. 

<sect1>¿ Existe soporte para multipuntos (multi-point) ?.
<p>

Multi-point sería una característica muy útil para el PPP de Linux. Sin
embargo, el autor no tiene conocimiento de nadie que esté intentando
construir este tipo de soporte actualmente. 

<sect1>¿ Existe soporte para PPP síncrono ?.
<p>

Son necesarios pequeños cambios para soportar un interfaz serial con
comunicación síncrona. El rediseño que se está haciendo del driver PPP
está también orientado hacia este fin.  Kate Marika Alhola ha mostrado su
interés en escribir este soporte.  Debería contactar con ella (<htmlurl
url="mailto:kate@digiw.fi" name="kate@digiw.fi">) para más información. 

Actualmente, Kate ha informado al autor que este driver está ya en fase de
pruebas, funcionando con máquinas Cisco(TM) y con velocidades de 64K y
256K. El código fuente del programa se encuentra bajo la licencia GPL de
la GNU y puede encontrarse en <url
url="ftp://nic.funet.fi/pub/Linux/kernel/xnet-sync-driver-1.0.tar.gz"
name="nic.funet.fi" >

<sect>Miscelánea
<p>

<sect1>¿ Existe un lector de correo compatible con PPP ?.
<p>

¿ Uh ?. PPP no tiene nada que ver con el mail user agent (el programa que
le presenta el correo en pantalla). Todos estos programas son compatibles
con PPP. 

<sect1>¿ Y un lector de news ?.
<p>

Vuelva a leer la pregunta anterior.

<sect>Preguntas sobre <tt/chat/.
<p>

<sect1>Mi módem no marca cuando ejecuto <tt/chat/.
<p>

El módem debe encontrarse en modo comando para poder marcar. Si su módem
ya está en linea, los comandos de marcado se envían al sistema remoto como
si fuesen datos normales. 

Si es posible, configure su módem para que monitorice la señal DTR y
retorne al modo de comandos cuando se desactive esta señal. Esto permitirá
al ordenador forzar al módem para que vuelva al modo de comandos cuando el
proceso <tt/pppd/ termine como resultado del fin de la conexión. De este
modo, se asegura que el módem se queda en el estado adecuado para que
<tt/chat/ pueda marcar. 

Si no puede cambiar la configuración del módem, entonces debería cambiar
la secuencia de marcado para que se parezca a la siguiente. Esta secuencia
se asegura que el módem está en modo comando antes de intentar enviar la
secuencia de marcado al módem.  <p> <tscreen><verb> TIMEOUT 3 "" \rAT
OK-+++\c-OK AT&ero;D2&ero;C1 TIMEOUT 60 OK ATDT555-1212 CONNECT
</verb></tscreen> <p> Esta secuencia cambia el temporizador de alarma a 3
segundos. Este valor se acomoda al tiempo requerido por la mayoría de los
módem para responder. Tras esto, envía un AT al módem para esperar su
respuesta OK. Si esto no sucede en el tiempo especificado en el TIMEOUT (3
segundos), manda la secuencia +++ al módem y espera de nuevo una respuesta
OK del módem. Una vez recibida la confirmación del módem, configura el
módem adecuadamente, restablece el TIMEOUT y marca (por tonos) el número
de teléfono (555-1212). 

<sect1>El módem solo marca en el segundo intento.
<p>

Vea la pregunta anterior. Generalmente esto suele ser causado por el mismo
problema que el descrito en la pregunta anterior. 

<sect1>El script de <tt/chat/ se para tras enviar el login al sistema remoto
y nunca envía el password.
<p>

Algunos sistemas, especialmente SCO, vacían los buffers de recepción justo
tras escribir el prompt de entrada del login y del password. <tt/Chat/
normalmente transmite la respuesta al prompt nada más ver este prompt. El
resultado de todo esto es que la respuesta que ha enviado <tt/chat/ se
pierde al vaciarse el buffer. Como el sistema remoto no ha recibido el
login, no pregunta por el password y como <tt/chat/ está esperando
precisamente eso, se ha llegado a un estado de bloqueo. 

La solución es sencilla. Enleztezca las respuestas de <tt/chat/, de tal
forma que haya tiempo en el sistema remoto para vaciar su buffer antes de
que <tt/chat/ envíe la respuesta. Para hacer esto, cambie las cadenas de
respuesta del script a algo como esto: 

<tscreen><verb>
ogin:--ogin: \d\daccount assword: \d\dhello2u2
</verb></tscreen>

Donde cada &bsol;d representa un retraso (delay) de un segundo a esperar
por <tt/chat/ antes de enviar la respuesta.

<sect>Anexo: El INSFLUG <label id="Grupos">
<p>

El <em/INSFLUG/ forma parte del grupo internacional <it/Linux
Documentation Project/, encargándose de las traducciones al castellano de
los Howtos (Comos), así como la producción de documentos originales en
aquellos casos en los que no existe análogo en inglés. 

En el <bf/INSFLUG/ se orienta preferentemente a la traducción de
documentos breves, como los <em/COMOs/ y <em/PUFs/ (<bf/P/reguntas de
<bf/U/so <bf/F/recuente, las <it/FAQs/. <tt/:)/ ), etc. 

Diríjase a la sede del INSFLUG para más información al respecto.

En la sede del INSFLUG encontrará siempre las <bf/últimas/ versiones de
las traducciones:  <tt><htmlurl url="www.insflug.org" 
name="www.insflug.org"></tt>. Asegúrese de comprobar cuál es la última
versión disponible en el Insflug antes de bajar un documento de un
servidor réplica. 

Se proporciona también una lista de los servidores réplica (<it/mirror/)
del Insflug más cercanos a Vd., e información relativa a otros recursos en
castellano. 

Francisco José Montilla, <tt><htmlurl url="mailto:pacopepe@insflug.org" 
name="pacopepe@insflug.org"></tt>. 

</article>
