longyear@netcom.com
.ragundo@bitmailer.net.
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
(este es el sitio oficial) o bien mediante WWW en
la Linux Documentation home page.
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.
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.
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
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
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.
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
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.
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.
Hay varias fuentes de información sobre la manera en que se ha implementado el protocolo PPP para Linux.
README
que viene junto con el paquete.
README.linux
que también viene junto con el paquete.
man
de pppd
.
El fichero HOWTO se encuentra en el lugar habitual para los HOWTOs de Linux. Actualmente están en sunsite.unc.edu.
La Network Administration Guide (Guia de Administración de Red ) puede obtenerse en sunsite.unc.edu. También está publicada en forma de libro impreso por la editorial 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 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.
Actualmente, la PPP FAQ está dividida en 8 partes.
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.
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).
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.
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.
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".
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.
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í.
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
).
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 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.
(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.
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.
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.
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".
/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
/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
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
.
pppd
.
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.
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.
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.
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.
/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)
.
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:
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).
Vea la pregunta anterior.
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:
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).
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
.
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:
LCP configure
en el log de la
conexión. Si aparece un auth
significa que el sistema remoto requiere
identificación y verificación.
/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:
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.
#!/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.
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 ?.
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.
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
Hay varias razones para que ocurra esto:
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
.
&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 .
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 ...
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.
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).
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:
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.
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
."R1&H4"
.
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.
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 ?.
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
.
Esta no es una pregunta que esté relacionada con PPP.
Pista: ¡ NO EJECUTE routed
!.
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:
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.
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
.
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.
¿ 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.
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.
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.
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
.
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.
Trumpet no acepta ningún tipo de compresión de cabeceras VJ. Utilize pppd
con la opción -vj
para desactivar esta compresión.
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.
Hasta que consiga esta actualización, no utilice compresión de cabeceras VJ.
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
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.
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.
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.
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.
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
.
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.
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.
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
nettools
por el de
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
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.
/proc/net/dev
no tiene ningún dispositivo 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.
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:
/etc/ppp/ip-up
o /etc/ppp/ip-down
).ppp0
por ejemplo)./dev/cua0
por ejemplo).ipparam
.
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
demand dial
?.Utilice el paquete
diald. Está en sunsite
, en el
mismo directorio que el código fuente de PPP.
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.
El soporte IPX sería muy fácil de implementar. Esto se está haciendo en la actualidad, gracias, sobre todo, al apoyo de Caldera.
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.
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.
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.
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
¿ 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.
Vuelva a leer la pregunta anterior.
chat
.
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).
Vea la pregunta anterior. Generalmente esto suele ser causado por el mismo problema que el descrito en la pregunta anterior.
chat
se para tras enviar el login al sistema remotoy nunca envía el password.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 \d representa un retraso (delay) de un segundo a esperar por chat
antes de
enviar la respuesta.