Linux PPP HOWTO

Linux PPP HOWTO
Al Longyear, [email protected].
(INSFLUG), [email protected]
v1.0, 9 Marzo 1996

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

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

18. Anexo: El INSFLUG
______________________________________________________________________

1. Prefacio.

Si tiene alguna correcci�n sobre este documento, por favor,
notif�quesela a Al Longyear ([email protected]). Si tiene alguna
correcci�n relativa a la traducci�n, contacte con Rafael Agundo
([email protected]).

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 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. puedo conseguir documentaci�n adicional sobre PPP ?. � (D�nde
est� la documentaci�n ?. � Hay un HOWTO ?, etc.). � D�nde

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. comprender c�mo se han escrito ?. � Podr�a alguien enviarme
scripts para PPP, de tal manera que pueda

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. din�mica de direcciones IP ?. �� Cada vez que conecto obtengo
una direcci�n IP distinta !!!. � C�mo debo usar PPP con un sistema
remoto que usa asignaci�n

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. usa asignaci�n din�mica de direcciones ?. � C�mo puedo saber
que direcci�n IP me ha sido asignada cuando se

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. un servidor PPP?. � Puedo usar la misma direcci�n IP local
para todas las l�neas de

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. Me gustar�a saber si existe alguna para HP-UX o AIX o ... �
Existen otras implementaciones de PPP distintas a la de Linux ?.

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. alg�n ejemplo disponible ?. � Cu�l es el formato del fichero
/etc/pap-secrets ?. � Hay

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. Hay alg�n ejemplo disponible ?. � Cu�l es el formato del
fichero /etc/chap-secrets ?. �

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. yo estoy seguro de haber habilitado la opci�n al recompilarlo.
pppd dice que el kernel no est� configurado para PPP. Pero

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. directory . Obtengo el mensaje: unable to create pid file: no
such file or

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. directory . Obtengo el mensaje: /etc/ppp/options: no such file
or

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. tramas, pero parece como si la conexi�n no fuese completa. �
Qu� significa esto ?. El software PPP conecta con el sistema remoto,
env�a unas cuantos

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. cuando hago un put . Sin embargo, si hago get funciona perfec�
tamente. � Qu� ocurre ?. � En las transferencias con ftp, parece que
la conexion muere

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

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. operaci�n put , sin embargo, es muy r�pida. � Porqu� ?. Cuando
hago ftp, la operaci�n get es muy lenta, pero la

� 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. unos 3 minutos y ha vuelto a desaparecer. � Ayuda !. � Mi ruta
al sistema remoto sigue desapareciendo !. Estuvo activa

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

Pista: � NO EJECUTE routed !.

11.2. 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 ?. � Me gustar�a conec�
tar los ordenadores de mi red a Internet usando

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. con ninguna otra m�quina de dicho sistema. Conecto con la
m�quina del sistema remoto, pero no puedo hacerlo

� 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. m�quinas. � Y ahora que hago ?. Tengo una ruta por defecto
pero sigo sin poder acceder al resto de

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. termina. � Porqu� ocurre esto ?. Estoy usando Trumpet (para
MSDOS) y la conexi�n simplemente

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. hacer nada m�s que ping o nslookup . � Porqu� ocurre esto ?.
Estoy usando dp-3.1.2 (con SunOS) y el sistema no me permite

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 ([email protected]):

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. error o ioctl(PPPIOCSINPSIG): I/O error . La conexi�n falla
con errores como ioctl(TIOCGETD): I/O

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. ioctl(TIOCSETD): I/O error o ioctl(TIOCNXCL): I/O error . �
Porqu� ocurre esto ?. Ocurren errores del tipo ioctl(PPPIOCGDEBUG):
I/O error ,

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
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. "desactivados" cuando el sistema empieza a arrancar. El ker�
nel informa que los dispositivos PPP est�n siendo

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. dispositivo PPP. � Donde est�n ?. Acabo de comprobar que
/proc/net/dev no tiene ning�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
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
([email protected]) 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 \d representa un retraso (delay) de un segundo a esperar
por chat antes de enviar la respuesta.

18. Anexo: El INSFLUG

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

En el INSFLUG se orienta preferentemente a la traducci�n de documentos
breves, como los COMOs y PUFs (Preguntas de Uso Frecuente, las FAQs.
:) ), etc.

Dir�jase a la sede del INSFLUG para m�s informaci�n al respecto.

En la sede del INSFLUG encontrar� siempre las �ltimas versiones de las
traducciones: www.insflug.org. Aseg�rese de comprobar cu�l es la
�ltima versi�n disponible en el Insflug antes de bajar un documento de
un servidor r�plica.

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

Francisco Jos� Montilla, [email protected].