  Linux PPP HOWTO
  Al Longyear, longyear@netcom.com.
  Traducido por Rafael Agundo (INSFLUG), ragundo@bitmailer.net.
  v1.0, 9 Marzo 1996

  Este documento contiene una lista con las preguntas más habituales
  (FAQ) sobre PPP para Linux ( junto con sus respuestas). No es real­
  mente un HOWTO, pués se adapta más al formato clásico de Pre­
  gunta/Respuesta de las FAQ.
  ______________________________________________________________________

  Índice General:

  1.      Prefacio.

  2.      Información general

  2.1.    ¿ Qué es PPP ?.

  2.2.    Mi universidad ( o compañía ) no soporta PPP. ¿ Puedo usar PPP
  ?.

  2.3.    ¿ Dónde se encuentra PPP?.

  2.4.    Acabo de conseguir el paquete PPP. ¿ Qué hago con él ?.

  2.5.    ¿ (Dónde está la documentación ?. ¿ Hay un HOWTO ?, etc.). ¿
  Dónde puedo conseguir documentación adicional sobre PPP ?.

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

  2.7.    ¿ Dónde debo preguntar para resolver mis posibles dudas sobre
  PPP?.

  2.8.    Mi software PPP no funciona. ¿ Qué hago ?.

  2.9.    ¿ 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 !!!.

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

  2.11.   ¿ Puedo usar la misma dirección IP local para todas las líneas
  de un servidor PPP?.

  3.      Otras implementaciones.

  3.1.    ¿ Existen otras implementaciones de PPP distintas a la de
  Linux ?. Me gustaría saber si existe alguna para HP-UX o AIX o ...

  3.2.    ¿ Existe un programa llamado dp  ?.

  3.3.    ¿ Cuáles son los RFCs que describen el protocolo PPP ?.

  4.      Compatibilidad.

  4.1.    ¿ Puede PPP dialogar con un interface tipo SLIP ?.

  4.2.    ¿ Qué es mejor: usar PPP o SLIP ?.

  4.3.    ¿ Qué es mejor para la identificación y verificación: CHAP o
  PAP ?.

  5.      Ficheros de identificación y verificación.

  5.1.    ¿ Cuál es el formato del fichero /etc/pap-secrets  ?. ¿ Hay
  algún ejemplo disponible ?.

  5.2.    ¿ Cuál es el formato del fichero /etc/chap-secrets  ?. ¿ Hay
  algún ejemplo disponible ?.

  6.      Problemas de compilación.

  6.1.    Hay errores cuando intento compilar el kernel.

  7.      Problemas al ejecutar pppd .

  7.1.    pppd  dice que la versión 0.0.0 está fuera de fecha.

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

  7.3.    pppd  no funciona a menos que sea root.

  7.4.    Obtengo el mensaje: unable to create pid file: no such file or
  directory .

  7.5.    Obtengo el mensaje: /etc/ppp/options: no such file or
  directory .

  7.6.    No puedo averiguar cuál es mi dirección IP local.

  7.7.    No puedo averiguar la dirección IP remota.

  7.8.    Obtengo mensajes diciéndome que el número mágico no es
  aceptado.

  7.9.    Obtengo un mensaje: protocol reject for protocol fffb .

  7.10.   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 ?.

  7.11.   El script /etc/ppp/ip-up  no funciona.

  7.12.   No puedo conectar con la red merit.

  8.      DIP

  8.1.    DIP no tiene soporte para ejecutar PPP.

  9.      Terminación del proceso.

  9.1.    ¿ Existe un comando similar a dip -k  para PPP ?.

  9.2.    PPP no cuelga el módem cuando termina.

  10.     Transferencia de datos.

  10.1.   ¿ En las transferencias con ftp, parece que la conexion muere
  cuando hago un put . Sin embargo, si hago get  funciona perfectamente.
  ¿ Qué ocurre ?.

  10.2.   ¿ Cómo debo usar el control de flujo XON/XOFF ?.

  10.3.   ¿ El módem parece que conecta a velocidades extrañas. Cuando
  uso 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 ?.
  10.4.   Cuando hago ftp, la operación get  es muy lenta, pero la
  operación put , sin embargo, es muy rápida. ¿ Porqué ?.

  10.5.   La opción proxyarp  no encuentra la dirección hardware.

  11.     Rutado y otros problemas.

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

  11.2.   ¿ 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 ?.

  11.3.   Conecto con la máquina del sistema remoto, pero no puedo
  hacerlo con ninguna otra máquina de dicho sistema.

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

  11.5.   No puedo hacer ping  a mi dirección IP local.

  12.     Interacción con otras implementaciones de PPP.

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

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

  12.3.   No puedo conectar con/desde mi máquina con Windows NT.

  13.     Otros mensajes enviados al system log.

  13.1.   Alarm.

  13.2.   SIGHUP.

  13.3.   SIGINT.

  13.4.   Unknow protocol (c025) received .

  13.5.   Unknow protocol (80fd) received .

  13.6.   La conexión falla con errores como ioctl(TIOCGETD): I/O error
  o ioctl(PPPIOCSINPSIG): I/O error .

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

  13.8.   ifconfig  me proporciona una información extraña con PPP.

  13.9.   El fichero proc/net/dev  parece que esta vacío.

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

  13.11.  Acabo de comprobar que /proc/net/dev  no tiene ningún
  dispositivo PPP. ¿ Donde están ?.

  14.     Rutado con redes locales (usando PPP como un "bridge"
  económico).

  14.1.   Slattach  e ifconfig  no funcionan como con SLIP.

  14.2.   Quiero definir una ruta a la red entera y no sólo a un host de
  esa red.

  15.     Otras características y protocolos.

  15.1.   ¿ Existe soporte para demand dial  ?.

  15.2.   ¿ Existe soporte para filtrado ( filtering ) ?.

  15.3.   ¿ Existe soporte para IPX ?.

  15.4.   ¿ Existe soporte para NetBIOS ?.

  15.5.   ¿ Existe soporte para ISDN ?.

  15.6.   ¿ Existe soporte para multipuntos (multi-point) ?.

  15.7.   ¿ Existe soporte para PPP síncrono ?.

  16.     Miscelánea

  16.1.   ¿ Existe un lector de correo compatible con PPP ?.

  16.2.   ¿ Y un lector de news ?.

  17.     Preguntas sobre chat .

  17.1.   Mi módem no marca cuando ejecuto chat .

  17.2.   El módem solo marca en el segundo intento.

  17.3.   El script de chat  se para tras enviar el login al sistema
  remoto y nunca envía el password.
  ______________________________________________________________________

  1.  Prefacio.

  Si tiene alguna corrección sobre este documento, por favor,
  notifíquesela a Al Longyear (longyear@netcom.com).  Si tiene alguna
  corrección relativa a la traducción, contacte con Rafael Agundo
  (ragundo@bitmailer.net).

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

  A lo largo de este documento, se usa la palabra remoto 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 peer. Cuando se
  habla de rutado suele aparecer como gateaway. La dirección IP del
  sistema remoto aparecerá como el campo dirección 'P-t-P' cuando se use
  ifconfig.  Asimismo, se emplea indistintamente el término inglés frame
  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.

  2.  Información general

  2.1.  ¿ Qué es PPP ?.

  PPP o Point-to-Point Protocol (Protocolo de Punto a Punto) está
  reconocido como uno de los  protocolos oficiales 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.

  2.2.  Mi universidad ( o compañía ) no soporta PPP. ¿ Puedo usar PPP
  ?.

  En general, no. Una implementación clásica 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
  www.marketplace.com <http://www.marketplace.com/tia/tiahome>

  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 term. Algunos proveedores de servicios de conexión
  pueden ponerle trabas a utilizar term 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 slirp, el cual realizará funciones similares al de TIA. Este
  programa, junto con su código fuente, puede obtenerse mediante ftp
  <ftp://blitzen.canberra.edu.au/pub/slirp>

  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.

  2.3.  ¿ Dónde se encuentra PPP?.

  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 demonio (daemon) pppd. Este es un proceso
  obligatorio a ejecutar cuando quiera realizar una conexión PPP. El
  código fuente para pppd se encuentra en el fichero ppp-2.2.0.tar.gz de
  sunsite.unc.edu
  <ftp://sunsite.unc.edu/pub/Linux/system/Network/serial>

  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.

  2.4.  Acabo de conseguir el paquete PPP. ¿ Qué hago con él ?.

  Read The Fine Material available. (-- ( 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).--)

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

  2.5.  ¿ (Dónde está la documentación ?. ¿ Hay un HOWTO ?, etc.). ¿
  Dónde puedo conseguir documentación adicional sobre PPP ?.

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

  ·  El fichero README que viene junto con el paquete.

  ·  El fichero README.linux que también viene junto con el paquete.

  ·  El documento Net-2-HOWTO.

  ·  La Network Administration Guide (NAG).

  ·  La página man de pppd.

  ·  La PPP FAQ. (Este HOWTO no lo es aunque lo parezca).

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

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

  Las páginas man 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 man, /usr/man/man8
  antes de que el comando man pueda encontrarlas. También puede usar
  nroff y more 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
  comp.protocols.PPP y también archivada en rtfm.mit.edu
  <ftp://rtfm.mit.edu/pub/usenet>.  Actualmente, la PPP FAQ está
  dividida en 8 partes.

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

  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 login y un password.

  Con el código fuente de pppd 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.

  2.7.  ¿ Dónde debo preguntar para resolver mis posibles dudas sobre
  PPP?.

  El grupo adecuado de usenet para preguntar es comp.protocols.PPP o
  comp.os.linux.setup.  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 comp.os.linux.networking.

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

  2.8.  Mi software PPP no funciona. ¿ Qué hago ?.

  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 ``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...

  Lo que realmente debe proporcionar junto con su petición de ayuda es
  una copia del system log (syslog) que obtiene cuando ejecuta pppd con
  la opción debug. Además, si usa chat para establecer la comunicación,
  use la opción -v en la línea de comandos de chat 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 pppd.

  NUNCA ejecute pppd con la opción kdebug 31 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 pppd.

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

  2.9.  ¿ 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 !!!.

  La asignación de la dirección IP local está en función de las opciones
  que se proporcionen a pppd y del protocolo IPCP. Debería utilizar la
  dirección IP mágica 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 pppd.

  La otra opción relacionada con este tema se llama noipdefault. Esta
  opción indica a su proceso pppd que no debe obtener su dirección IP
  local a partir de los datos que contenga su fichero /etc/hosts, 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.

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

  Utilize el fichero ejecutable /etc/PPP/ip-up. 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 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 ifconfig. Este programa le mostrará los valores
  actuales de la direcciones IP local y remota bajo el campo "P-t-P".

  2.11.  ¿ Puedo usar la misma dirección IP local para todas las líneas
  de un servidor PPP?.

  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.

  3.  Otras implementaciones.

  3.1.  ¿ Existen otras implementaciones de PPP distintas a la de Linux
  ?. Me gustaría saber si existe alguna para HP-UX o AIX o ...

  Revise la PPP FAQ mencionada anteriormente. Consulte la pregunta ``¿
  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 pppd.

  Si no encuentra el sistema que busca, pregunte en comp.protocols.ppp y
  NO 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" :-).

  El paquete pppd que se encuentra en sunsite 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 pppd 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 sunsite 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 pppd
  para otros sistemas, consulte la PPP FAQ. Alternativamente, puede
  utilizar archie. No intente buscarlo en los mirrors de sunsite porque
  tampoco estará ahí.

  3.2.  ¿ Existe un programa llamado dp  ?.

  Si, existe. El paquete dp 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, NO
  soporta streams.

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

  De todos estos paquetes, pppd 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 comp.protocols.ppp ).

  3.3.  ¿ Cuáles son los RFCs que describen el protocolo PPP ?.

  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:

       Los RFCs 1134, 1171, 1172 (y 1055 para este tema en con­
       creto) 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 longi­
       tud de 4 y con un tipo de compresión 0x0037.
       (Todavía existe un montón de todo esto circulando por ahí .
       Sea cuidadoso ahí fuera).

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

  4.  Compatibilidad.

  4.1.  ¿ Puede PPP dialogar con un interface tipo SLIP ?.

  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.

  4.2.  ¿ Qué es mejor: usar PPP o SLIP ?.

  Depende de muchos factores. Generalmente, las personas que hacen esta
  pregunta, no han leído el documento Net-2-HOWTO. Consulte la pregunta
  ``¿ Dónde está la documentación ?.''.

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

  4.3.  ¿ Qué es mejor para la identificación y verificación: CHAP o PAP
  ?.

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

  5.  Ficheros de identificación y verificación.

  5.1.  ¿ Cuál es el formato del fichero /etc/pap-secrets  ?. ¿ Hay
  algún ejemplo disponible ?.

  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 /etc/pap-secrets debería ser:
               #account        remote          password        IP address list
               abbot           *               firstbase

  5.2.  ¿ Cuál es el formato del fichero /etc/chap-secrets  ?. ¿ Hay
  algún ejemplo disponible ?.

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

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

               #remote         local           secret          IP address list
               abbot           costello        firstbase       10.10.10.2
               costello        abbot           who             10.10.10.1

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

               #remote         local           secret          IP address list
               abbot           costello        firstbase       10.10.10.2
               costello        abbot           who             10.10.10.1

  6.  Problemas de compilación.

  6.1.  Hay errores cuando intento compilar el kernel.

  El paquete con la versión 2.2 de pppd contiene las instrucciones
  necesarias para que pueda compilar el programa. Brevemente, necesita
  ejecutar el comando configure. Así se generarán los enlaces adecuados
  para el Makefile. Después, haga un make kernel. 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 pppd.

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

  7.  Problemas al ejecutar pppd .

  7.1.  pppd  dice que la versión 0.0.0 está fuera de fecha.

  Está intentando ejecutar la versión 2.2 de pppd sin haber vuelto a
  recompilar los drivers en el kernel.
  7.2.  pppd  dice que el kernel no está configurado para PPP. Pero yo
  estoy seguro de haber habilitado la opción al recompilarlo.

  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 pppd en su disco
  y esté ejecutando esa versión. La versión anterior de pppd se guardaba
  en /usr/lib/ppp. A muchas personas no les gustaba ese directorio, asi
  que en la nueva versión 2.2 se ha movido pppd, chat y pppstats al
  directorio /usr/sbin. Si sus scripts todavía apuntan hacia
  /usr/lib/ppp, entonces probablemente esté ejecutando el código
  antiguo.

  7.3.  pppd  no funciona a menos que sea root.

  El proceso pppd 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 pppd, asegúrese de configurar correctamente sudo
  para permitir usar pppd a dicho usuario.

    chmod root pppd
    chmod 4755 pppd

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

  7.4.  Obtengo el mensaje: unable to create pid file: no such file or
  directory .

  Necesita crear un directorio denominado /var/run. En versiones
  anteriores de la distribución Slackware, existía un acceso directo
  (symlink) al directorio /etc.  En realidad, este mensaje no es un
  error, sino un aviso (warning). PPP funcionará correctamente aunque
  aparezca este mensaje. Sin embargo, el fichero script PPP-off 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 paths.h define, con el nombre _VAR_RUN,
  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.

  7.5.  Obtengo el mensaje: /etc/ppp/options: no such file or directory
  .

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

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

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

  7.6.  No puedo averiguar cuál es mi dirección IP local.

  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:

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

  ·  La Netblazer no sabe la dirección IP de su site y usted no sabe la
     dirección IP de la Netblazer.

  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
  pppd.  Esta opción tiene el formato:

  pppd local_ip:remote_ip [resto de opciones]

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

  7.7.  No puedo averiguar la dirección IP remota.

  Vea la pregunta anterior.

  7.8.  Obtengo mensajes diciéndome que el número mágico no es aceptado.

  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:

  ·  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.

  ·  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.

  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).

  7.9.  Obtengo un mensaje: protocol reject for protocol fffb .

  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 vj-max-slots 3 en la línea de
  comandos de pppd 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 -vj a pasar a pppd.

  7.10.  El software PPP conecta con el sistema remoto, envía unas cuan­
  tos tramas, pero parece como si la conexión no fuese completa. ¿ Qué
  significa esto ?.

  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 debug en la
  línea de comandos de pppd. (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:

  ·  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.

  ·  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.

  ·  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 LCP configure en el log
     de la conexión. Si aparece un auth significa que el sistema remoto
     requiere identificación y verificación.

  7.11.  El script /etc/ppp/ip-up  no funciona.

  El proceso pppd ejecuta el script /etc/ppp/ip-up cuando la "capa" del
  protocolo IP se ha establecido correctamente. pppd 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
  /etc/ppp/ip-up como a un programa ejecutable y no como a un script. El
  programa se "lanza" mediante la función exec de Linux.  Esto quiere
  decir que si desea utilizar este script debe de hacer dos cosas:

  ·  Necesita tener el fichero marcado como ejecutable. Haga esto con
     chmod.  Los permisos correctos de funcionamiento deberían ser de
     100. Usando 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.

  ·  El fichero debe tener como primera línea:

         #!/bin/sh

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

  7.12.  No puedo conectar con la red merit.

  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 ?.

  8.  DIP

  8.1.  DIP no tiene soporte para ejecutar PPP.

  La versión más actual de dip-uri si soporta el uso de PPP, ya que
  utilizando la opción mode PPP, dip lanzará el proceso pppd
  automáticamente. Sin embargo, pppd necesita ser invocado con varias
  opciones para poder funcionar correctamente. Como dip no pasa estas
  opciones a pppd, dichas opciones deben de estar almacenadas en el
  fichero /etc/ppp/options.
  dip es un programa que controla el establecimiento de una conexión
  SLIP entre máquinas con la ayuda de otros programas: slattach,
  ifconfig y 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.

  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 connect. Sin
  embargo, usted tiene la opción de permitir que dip controle el enlace.
  Es indiferente como pppd sea ejecutado, lo que si es realmente
  importante es que debe ser ejecutato obligatoriamente, ya que es un
  programa imprescindible para el protocolo PPP.

  9.  Terminación del proceso.

  9.1.  ¿ Existe un comando similar a dip -k  para PPP ?.

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

  ______________________________________________________________________
    #!/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
  ______________________________________________________________________

  9.2.  PPP no cuelga el módem cuando termina.

  Hay varias razones para que ocurra esto:

  ·  ¿ Especificó la opción módem en la línea de comandos de pppd ?.
     Este parámetro controla si es 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 man de pppd.

  ·  ¿ Tiene el módem configurado para usar las señales DCD y DTR ?. La
     secuencia Hayes para el módem es normalmente &C1. Si resetea el
     módem durante la sesión con ATZ, 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 &D1 o &D2, siendo &D2
     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 .

  ·  ¿ 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.

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

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

     ___________________________________________________________________
          #!/bin/sh
          exec pppd -detach modem ...
     ___________________________________________________________________

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

  10.  Transferencia de datos.

  10.1.  ¿ En las transferencias con ftp, parece que la conexion muere
  cuando hago un put . Sin embargo, si hago get  funciona perfectamente.
  ¿ Qué ocurre ?.

  ¿ Está activado el control de flujo (flow control) ?. Esto se hace
  pasando a pppd la opción crtscts para usar control de flujo RTS/CTS
  (hardware) o 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).

  10.2.  ¿ Cómo debo usar el control de flujo XON/XOFF ?.

  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:

  ·  Necesita especificar la opción xonxoff en la línea de comandos de
     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.

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

  ·  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
     "R1&H4".

  10.3.  ¿ El módem parece que conecta a velocidades extrañas. Cuando
  uso 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 ?.

  Especifique la velocidad que desea en la línea de comandos de 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 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.

  10.4.  Cuando hago ftp, la operación get  es muy lenta, pero la
  operación put , sin embargo, es muy rápida. ¿ Porqué ?.

  ¿ Especificó la opción asyncmap 0 cuando ejecutó pppd ?. Si olvidó
  esto, el peer debe doblar todos los caracteres de control en el rango
  0x00..0x1F (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 ?.

  10.5.  La opción proxyarp  no encuentra la dirección hardware.

  Use el paquete ppp-2.1.2d.tar.gz. El proceso 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 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 #define que se encuentra en el módulo
  sys-linux.c.

  11.  Rutado y otros problemas.

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

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

  Pista: ¡ NO EJECUTE routed !.

  11.2.  ¿ 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 asig­
  nada dinámicamente). ¿ Cómo puedo hacer esto ?.

  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:

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

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

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

  11.3.  Conecto con la máquina del sistema remoto, pero no puedo hac­
  erlo con ninguna otra máquina de dicho sistema.

  ¿ Ha olvidado añadir el parámetro defaultroute a la línea de comandos
  de pppd ?. 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 pppd. 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 defaulrotute
  no se ejecuta por esta razón.

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

  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 IP forwarding. En el RFC de
  PPP se especifica que esta opción NO debe estar activada por defecto.
  Esta opción debe habilitarse. Para sistemas Linux, necesita volver a
  compilar el kernel y especificar que desea IP forwarding/gatewaying.

  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.

  ·  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.

  ·  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).

  ·  Use gated en todos los gateways y en el servidor de terminal. Con
     esto se consigue que el servidor de terminal 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.

  ·  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.

     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 bcastd de
  sunsite.unc.edu. Este programa genera las tramas RIP sin necesidad de
  que tenga que instalar y ejecutar gated.

  11.5.  No puedo hacer ping  a mi dirección IP local.

  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 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 telefónicamente para ellos. Esto depende de la
  configuración específica de cada servidor En general, no haga 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

       route add -host 192.187.163.32 lo

  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.

  12.  Interacción con otras implementaciones de PPP.

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

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

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

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

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

  12.3.  No puedo conectar con/desde mi máquina con Windows NT.

  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
  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 (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:

       *       ""      ""

  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):

         HKEY_LOCAL_MACHINE\eSYSTEM\eCurrentControlSet\eServices\eRemoteAccess\eP
                  Autodisconnect: REG_DWORD: 0

  y para conseguir que el rutado funcione correctamente:

         HKEY_LOCAL_MACHINE\eSYSTEM\eCurrentControlSet\eServices\eRasArp\eParamet
                  DisableOtherSrcPackets: REG_DWORD: 0

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

       HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\SPAP

  13.  Otros mensajes enviados al system log.

  13.1.  Alarm.

  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.

  13.2.  SIGHUP.

  El proceso 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 kill también puede ser usado para enviar esta
  señal al proceso pppd.  Cuando pppd recibe esta señal, empieza la
  secuencia de finalización del enlace de una manera ordenada.

  13.3.  SIGINT.

  El proceso 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 pppd se
  está ejecutando como un proceso de segundo plano (background).
  Igualmente kill también puede generar esta señal para el proceso pppd.
  De hecho, esta es la forma educada de finalizar la ejecución de pppd y
  terminar con el enlace. Vea la pregunta referida a dip -k (pregunta
  ``¿ 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, pppd termina con el enlace de una manera ordenada.

  13.4.  Unknow protocol (c025) received .

  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.

  13.5.  Unknow protocol (80fd) received .

  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
  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
  pppd.

  13.6.  La conexión falla con errores como ioctl(TIOCGETD): I/O error
  o ioctl(PPPIOCSINPSIG): I/O error .

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

  Si aparece PPP version 0.2.7, entonces tiene una versión actualizada
  de 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 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 pppd.

  Si aparece 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 pppd. El programa pppd
  versión 2.2 sólo funcionará con esta versión del driver.

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

  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, 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.

  13.8.  ifconfig  me proporciona una información extraña con PPP.

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

  ______________________________________________________________________

     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
  ______________________________________________________________________

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

  13.9.  El fichero proc/net/dev  parece que esta vacío.

  ¿ Tecleó el comando ls -l /proc/net 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:

  cat /proc/net/dev

  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 more, less o most tampoco
  deben usarse para visualizar este fichero. Si quiere un resultado
  similar haga

  cat /proc/net/dev | less

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

  Esto no es un problema. Este mensaje es el resultado de la llamada que
  hace el driver de PPP al procedimiento 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 #define que se encuentra en el fichero ppp.c y poner
  el valor que desee. Este será el número de dispositivos que serán
  cargados dinámicamente.

  13.11.  Acabo de comprobar que /proc/net/dev  no tiene ningún disposi­
  tivo PPP. ¿ Donde están ?.

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

  14.  Rutado con redes locales (usando PPP como un "bridge" económico).

  14.1.  Slattach  e ifconfig  no funcionan como con SLIP.

  No utilice slattach ni ifconfig con PPP. Estos programas se usan con
  SLIP. El proceso 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 ifconfig y slattach por pppd. La mayoria de
  los protocolos que se usan con PPP residen dentro del código de 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 pppd. No hay ninguna posibilidad de no añadir esta
  ruta. El proceso 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 defaultroute. Si ya existía una ruta por
  defecto anterior, pppd no definirá una nueva, sino que conservará la
  ya existente.

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

  ·  $0 : nombre del script que se esta ejecutando (/etc/ppp/ip-up o
     /etc/ppp/ip-down ).

  ·  $1 : nombre del dispositivo de red (ppp0 por ejemplo).

  ·  $2 : nombre del dispositivo tty (/dev/cua0 por ejemplo).

  ·  $3 : velocidad del dispositivo tty en bits por segundo (14400 por
     ejemplo).

  ·  $4 : la dirección IP local (en formato xxx.yyy.zzz.vvv).

  ·  $5 : la direccion IP remota (en formato xxx.yyy.zzz.vvv).

  ·  $6 : el valor del parámetro ipparam.

  14.2.  Quiero definir una ruta a la red entera y no sólo a un host de
  esa red.

  Existe en sunsite un paquete llamado 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 man del paquete.

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

  ______________________________________________________________________

    # 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
  ______________________________________________________________________

  15.  Otras características y protocolos.

  15.1.  ¿ Existe soporte para demand dial  ?.

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

  15.2.  ¿ Existe soporte para filtrado ( filtering ) ?.

  No hay intención de implementar filtrado dentro del código de PPP.  La
  versión 1.3 del kernel soporta una opción 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 ipfw, bien ipfwadm para definir las reglas que gobiernan el
  funcionamiento del cortafuegos que está dentro del kernel.

  15.3.  ¿ Existe soporte para IPX ?.

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

  15.4.  ¿ Existe soporte para NetBIOS ?.

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

  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.

  15.5.  ¿ Existe soporte para ISDN ?.

  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.

  15.6.  ¿ Existe soporte para multipuntos (multi-point) ?.

  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.

  15.7.  ¿ Existe soporte para PPP síncrono ?.

  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
  (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 nic.funet.fi
  <ftp://nic.funet.fi/pub/Linux/kernel/xnet-sync-driver-1.0.tar.gz>

  16.  Miscelánea

  16.1.  ¿ Existe un lector de correo compatible con PPP ?.

  ¿ 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.

  16.2.  ¿ Y un lector de news ?.

  Vuelva a leer la pregunta anterior.

  17.  Preguntas sobre chat .

  17.1.  Mi módem no marca cuando ejecuto chat .

  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 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 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.

       TIMEOUT 3 "" \rAT OK-+++\c-OK AT&D2&C1 TIMEOUT 60 OK ATDT555-1212 CONNECT

  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).

  17.2.  El módem solo marca en el segundo intento.

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

  17.3.  y nunca envía el password.  El script de chat  se para tras
  enviar el login al sistema remoto

  Algunos sistemas, especialmente SCO, vacían los buffers de recepción
  justo tras escribir el prompt de entrada del login y del password.
  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
  chat se pierde al vaciarse el buffer. Como el sistema remoto no ha
  recibido el login, no pregunta por el password y como chat está
  esperando precisamente eso, se ha llegado a un estado de bloqueo.

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

       ogin:--ogin: \d\daccount assword: \d\dhello2u2

  Donde cada  representa un retraso (delay) de un segundo a esperar por
  chat antes de enviar la respuesta.

