Lo hice y lo entendí

El blog de Vicente Navarro
06 dic

Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP

En los PCs, la entrada estándar siempre ha sido el teclado, y la salida estándar, el monitor a través de la tarjeta de vídeo. Sin embargo, en los grandes sistemas UNIX, la entrada/salida estándar ha sido tradicionalmente a través de un terminal o un módem serie. Incluso en workstations UNIX enfocadas a CAD con monitor y teclado, siempre ha existido la posibilidad de gestionar la máquina desde el arranque por el puerto serie. En ocasiones, los fabricantes han redirigido esa conexión serie a un servidor de telnet para tener una “LAN Console” y en otras, a un servidor web, para tener una “Web Console”, pero en definitiva, los que hacen es facilitarnos el acceso a lo que sigue siendo internamente una consola serie estándar.

Los PCs no están bien preparados para tener como única posibilidad de entrada/salida un terminal serie. Al menos no durante el arranque y para configurar la BIOS. Una vez que el sistema operativo o el GRUB toma el control ya sí que podemos usar el puerto serie para gestionar el ordenador. Pero es precisamente en circunstancias muy dramáticas cuando nos puede interesar especialmente controlar el arranque remotamente. Por eso hay fabricantes de servidores x86 cuyos sistemas permiten redirigir la salida de la BIOS a un puerto serie, como por ejemplo la HP BIOS Serial Console. Para ampliar información sobre servidores con esta posibilidad, podemos leer sobre IPMI y sobre Out-of-band management o Lights-out management. En la web en japonés sobre la tarjeta Lights-Out 100 de HP podemos ver capturas de una BIOS por el puerto serie.

En cualquier caso, en PCs normales no tenemos esta posibilidad. El primer momento en el que podemos comenzar a redirigir la salida estándar es en el GRUB. El segundo momento es al arrancar el kernel de Linux. El tercero es cuando el sistema operativo ya está totalmente arriba.

Veamos cómo acceder a la consola por el puerto serie una vez que el sistema está arriba y luego veremos qué dificultades presentan los otros casos.

Debian nos lo pone muy fácil. Si examinamos el fichero /etc/inittab, vemos que tenemos preparados ejemplos para habilitar la consola en un puerto serie usando un cable null modem o usando un módem conectado al puerto serie:

# Example how to put a getty on a serial line (for a terminal)
#
#T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100
#T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100
 
# Example how to put a getty on a modem line.
#
#T3:23:respawn:/sbin/mgetty -x0 -s 57600 ttyS3

En los PCs no tiene mucha utilidad un terminal usando un cable null modem, ya que normalmente podremos usar el teclado y el ratón o podremos acceder por la red. Sin embargo, en entornos de servidores sin monitor puede ser necesario en situaciones en las que la tarjeta de red se haya roto. Incluso se me ocurre una máquina recién instalada en la que la tarjeta de red no esté configurada correctamente y la consola serie (usando un emulador de terminal) nos venga bien para copiar y pegar unos comandos de un guiaburros. En cualquier caso, tiene más utilidad la posibilidad de acceso por módem que nos permite acceder directamente a la consola de la máquina remota en momentos en que la red se haya podido haber caído.

Podemos hacer la primera prueba con un cable null modem y descomentando la línea:

T0:23:respawn:/sbin/getty -L ttyS0 9600 vt100

Para que el proceso init relea el inittab podemos usar el comando “telinit q“, operación que se confirma en el /var/log/syslog:

Dec  5 20:11:01 remoto init: Re-reading inittab

Para conectarnos tenemos que usar un emulador de terminal serie. En Linux el más famoso es el minicom. En Windows, el que viene por defecto es el Hyperterminal. Veamos cómo hacerlo con el Hyperterminal.

Tras ponerle un nombre a la conexión, configuramos el puerto serie que vamos a usar:

Hyperterminal null modem. Configuración del puerto serie.

Así como los parámetros de comunicación:

Hyperterminal null modem. Configuración de los parámetros de comunicación.

Y sólo con esto ya nos podemos conectar a la consola:

Hyperterminal null modem. Conectados.

Ahora hagamos lo mismo pero con módem, no con cable null modem. Para ello, si vamos a usar el mismo puerto serie comentamos la línea anterior del inittab y descomentamos la del mgetty:

T3:23:respawn:/sbin/mgetty -n 6 -x0 -s 57600 ttyS0

Hay que cambiar el puerto serie (ttySX) al que hayamos conectado el módem y además yo he añadido el parámetro “-n 6” para que el módem no descuelgue hasta el sexto timbrazo, evitando así que el módem descuelgue el teléfono inmediatamente impidiéndonos recibir otras llamadas normales.

En este punto, podemos usar el minicom para, tras configurar correctamente el puerto serie a usar y mediante comandos Hayes como ATZ, ATI0 o ATI3, verificar las características del módem y comprobar que responde:

Welcome to minicom 2.2

OPTIONS: I18n
Compiled on Jan  7 2007, 18:00:43.
Port /dev/ttyS0

               Press CTRL-A Z for help on special keys

AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
OK
ATI0
33600

OK
ATI3
V2.061.5-V34_ACF_DS1

OK
ATZ
OK

Por tanto, sólo con descomentar la línea del mgetty, configurar adecuadamente el puerto, y tras el necesario “telinit q“, ya podemos acceder con otro módem desde otra línea telefónica.

Tras ponerle nombre a la conexión, elegimos el módem a usar e introducimos el número de teléfono de la línea conectada al módem remoto:

Hyperterminal módem. Número de teléfono.

Vamos a las propiedades de la conexión:

Hyperterminal módem. Propiedades de la conexión.

y podemos configurar los parámetros del módem:

Hyperterminal módel. Parámetros del módem.

Llamamos:

Hyperterminal módem. Llamando…

y al sexto timbrazo ya nos conectamos:

Hyperterminal modem. Conectados.

Pero admás de permitirnos acceso a la consola remotamente, el mgetty nos facilita el acceso por RAS/PPP. Ésto es gracias a la siguiente línea del fichero de configuración /etc/mgetty/login.config que está habilitada por defecto:

#
# Automatic PPP startup on receipt of LCP configure request (AutoPPP).
#  mgetty has to be compiled with "-DAUTO_PPP" for this to work.
#  Warning: Case is significant, AUTOPPP or autoppp won't work!
#  Consult the "pppd" man page to find pppd options that work for you.
#
#  NOTE: for *some* users, the "-detach" option has been necessary, for 
#        others, not at all. If your pppd doesn't die after hangup, try it.
#
#  NOTE2: "debug" creates lots of debugging info.  LOOK AT IT if things
#         do not work out of the box, most likely it's a ppp problem!
#
#  NOTE3: "man pppd" is your friend!
#
#  NOTE4: max. 9 arguments allowed.
#
/AutoPPP/ -     a_ppp   /usr/sbin/pppd auth -chap +pap login debug

Es decir, que el mgetty detecta si la conexión entrante es de terminal remota o de PPP, en cuyo caso arranca el proceso pppd y le pasa el control.

Y ya que repasamos el login.conf del mgetty, fijémonos en la entrada que permite el login a los que intentan acceder por terminal remoto:

# This is the "standard" behaviour - *dont* set a userid or utmp
#  entry here, otherwise /bin/login will fail!
#  This entry isn't really necessary: if it's missing, the built-in
#  default will do exactly this.
#
*       -       -       /bin/login @

Para que la conexión PPP funcione, hemos de añadir a las opciones ya existentes en el fichero /etc/ppp/options al menos un par más para especificar qué IPs usará el proceso pppd y qué dirección de DNS le vamos a pasar, tal y como nos cuenta el “man pppd“:

       <local_IP_address>:<remote_IP_address>
              Set the local and/or remote interface IP addresses.  Either  one
              may  be  omitted.  The IP addresses can be specified with a host
              name or in  decimal  dot  notation  (e.g.  150.234.56.78).   The
              default  local  address  is the (first) IP address of the system
              (unless the noipdefault option is given).   The  remote  address
              will  be  obtained from the peer if not specified in any option.
              Thus, in simple cases, this option is not required.  If a  local
              and/or  remote  IP  address  is specified with this option, pppd
              will not accept a different value from  the  peer  in  the  IPCP
              negotiation,     unless     the     ipcp-accept-local     and/or
              ipcp-accept-remote options are given, respectively.

       ms-dns <addr>
              If pppd is acting as a server  for  Microsoft  Windows  clients,
              this  option  allows  pppd to supply one or two DNS (Domain Name
              Server) addresses to the clients.  The first  instance  of  this
              option  specifies  the  primary DNS address; the second instance
              (if given) specifies the secondary DNS  address.   (This  option
              was  present  in  some  older  versions  of  pppd under the name
              dns-addr.)

Si la red local del sistema es la 192.168.1.0/24, y el router que hace de servidor de DNS está en la dirección 192.168.1.1, podemos añadir por ejemplo las siguientes líneas para especificar que la nueva red punto a punto use las IPs 192.168.200.1 y 192.168.200.2 y además pasarle la configuración de DNS al sistema que se va a conectar:

192.168.200.1:192.168.200.2
ms-dns 192.168.1.1

El fichero /etc/ppp/pap-secrets está configurado por defecto para que los usuarios usen el password estándar que tienen en el sistema para acceder por RAS:

# INBOUND connections
 
# Every regular user can use PPP and has to use passwords from /etc/passwd
*       hostname        ""      *
 
# UserIDs that cannot use PPP at all. Check your /etc/passwd and add any
# other accounts that should not be able to use pppd!
guest   hostname        "*"     -
master  hostname        "*"     -
root    hostname        "*"     -
support hostname        "*"     -
stats   hostname        "*"     -

Pero tenemos que modificar el hostname de la segunda columna por el nombre real del sistema o por * o la autentificación no funcionará

# Every regular user can use PPP and has to use passwords from /etc/passwd
*       remoto        ""      *

o

# Every regular user can use PPP and has to use passwords from /etc/passwd
*       *        ""      *

o incluso si sólo queremos permitir el acceso a un usuario:

# Every regular user can use PPP and has to use passwords from /etc/passwd
supercoco       remoto        ""      *

Tras esto, sólo tenemos que configurar una conexión con el usuario y el número de teléfono apropiado y ya está:

RAS a Linux

En el fichero /var/log/syslog podemos seguir el establecimiento de la conexión:

Dec  5 20:48:21 remoto pppd[3374]: pppd 2.4.4 started by a_ppp, uid 0
Dec  5 20:48:21 remoto pppd[3374]: using channel 6
Dec  5 20:48:21 remoto pppd[3374]: Using interface ppp0
Dec  5 20:48:21 remoto pppd[3374]: Connect: ppp0 <--> /dev/ttyS0
Dec  5 20:48:21 remoto pppd[3374]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdf9b2ceb> <pcomp> <accomp>]
Dec  5 20:48:21 remoto pppd[3374]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xdf9b2ceb> <pcomp> <accomp>]
Dec  5 20:48:24 remoto pppd[3374]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x1edc25c0> <pcomp> <accomp> <callback CBCP>]
Dec  5 20:48:24 remoto pppd[3374]: sent [LCP ConfRej id=0x2 <callback CBCP>]
Dec  5 20:48:24 remoto pppd[3374]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x1edc25c0> <pcomp> <accomp>]
Dec  5 20:48:24 remoto pppd[3374]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> <magic 0x1edc25c0> <pcomp> <accomp>]
Dec  5 20:48:24 remoto pppd[3374]: sent [LCP EchoReq id=0x0 magic=0xdf9b2ceb]
Dec  5 20:48:24 remoto pppd[3374]: rcvd [LCP Ident id=0x4 magic=0x1edc25c0 "MSRASV5.10"]
Dec  5 20:48:24 remoto pppd[3374]: rcvd [LCP Ident id=0x5 magic=0x1edc25c0 "MSRAS-0-LOCAL"]
Dec  5 20:48:24 remoto pppd[3374]: rcvd [PAP AuthReq id=0x1 user="supercoco" password=<hidden>]
Dec  5 20:48:24 remoto pppd[3374]: user supercoco logged in
Dec  5 20:48:24 remoto pppd[3374]: PAP peer authentication succeeded for supercoco
Dec  5 20:48:25 remoto pppd[3374]: Cannot determine ethernet address for proxy ARP
Dec  5 20:48:25 remoto pppd[3374]: local  IP address 192.168.200.1
Dec  5 20:48:25 remoto pppd[3374]: remote IP address 192.168.200.2
Dec  5 20:48:49 remoto pppd[3374]: LCP terminated by peer (^^M-\%M-@^@<M-Mt^@^@^@^@)
Dec  5 20:48:49 remoto pppd[3374]: Connect time 0.4 minutes.
Dec  5 20:48:49 remoto pppd[3374]: Sent 3776 bytes, received 21960 bytes.
Dec  5 20:48:50 remoto pppd[3374]: Hangup (SIGHUP)
Dec  5 20:48:50 remoto pppd[3374]: Modem hangup
Dec  5 20:48:50 remoto pppd[3374]: Connection terminated.
Dec  5 20:48:50 remoto pppd[3374]: Exit.

e incluso podemos ver si la autentificación no se puede completar porque el pap-secrets no está bien configurado:

Dec  5 20:47:11 remoto pppd[3275]: pppd 2.4.4 started by a_ppp, uid 0
Dec  5 20:47:11 remoto pppd[3275]: using channel 5
Dec  5 20:47:11 remoto pppd[3275]: Using interface ppp0
Dec  5 20:47:11 remoto pppd[3275]: Connect: ppp0 <--> /dev/ttyS0
Dec  5 20:47:11 remoto pppd[3275]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xada58980> <pcomp> <accomp>]
Dec  5 20:47:11 remoto pppd[3275]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xada58980> <pcomp> <accomp>]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x20ef517a> <pcomp> <accomp> <callback CBCP>]
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP ConfRej id=0x2 <callback CBCP>]
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0xada58980> <pcomp> <accomp>]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x20ef517a> <pcomp> <accomp>]
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP ConfAck id=0x3 <asyncmap 0x0> <magic 0x20ef517a> <pcomp> <accomp>]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0xada58980> <pcomp> <accomp>]
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP EchoReq id=0x0 magic=0xada58980]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP Ident id=0x4 magic=0x20ef517a "MSRASV5.10"]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP Ident id=0x5 magic=0x20ef517a "MSRAS-0-LOCAL"]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [PAP AuthReq id=0x0 user="supercoco" password=<hidden>]
Dec  5 20:47:14 remoto pppd[3275]: no PAP secret found for supercoco
Dec  5 20:47:14 remoto pppd[3275]: sent [PAP AuthNak id=0x0 "Login incorrect"]
Dec  5 20:47:14 remoto pppd[3275]: PAP peer authentication failed for supercoco
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP TermReq id=0x2 "Authentication failed"]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP EchoRep id=0x0 magic=0x20ef517a]
Dec  5 20:47:14 remoto pppd[3275]: rcvd [LCP TermReq id=0x6 " \37777777757Qz\000<\37777777715t\000\000\002\37777777663"]
Dec  5 20:47:14 remoto pppd[3275]: sent [LCP TermAck id=0x6]
Dec  5 20:47:15 remoto pppd[3275]: Hangup (SIGHUP)
Dec  5 20:47:15 remoto pppd[3275]: Modem hangup
Dec  5 20:47:15 remoto pppd[3275]: Connection terminated.
Dec  5 20:47:15 remoto pppd[3275]: Exit.

Una vez conectados por RAS/PPP, necesitamos conseguir que el cliente de RAS/PPP pueda acceder con libertad a la red remota e incluso salir a Internet si el router de 192.168.1.1 que hemos nombrado antes da acceso a ello. Para ello, tenemos dos posibilidades: Configurar rutas para llegar a la red 192.168.200.0/24 en los sistemas de la red 192.168.1.0/24, incluyendo el router, o NATear los paquetes de la conexión PPP.

En ambos casos necesitaremos habilitar el IP forwarding:

echo "1" > /proc/sys/net/ipv4/ip_forward

Y si nos decidimos a NATear la conexión PPP, será suficiente con usar este comando (cambiando el eht0 por el interfaz que usemos de salida) en nuestro servidor de RAS:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Redirigiendo el GRUB y la salida del kernel a un puerto serie

El Remote Serial Console HOWTO nos cuenta cómo hacerlo de forma muy clara.

Para el GRUB podemos usar una configuración como esta en el /boot/grub/menu.lst en la que permitimos una consola serie junto con la estándar (Using GRUB via a serial line) usando los comandos serial y terminal :

serial --unit=0 --speed=9600 --word=8 --parity=no --stop=1
terminal --timeout=10 serial console

Y al kernel también le podemos especificar que use un puerto serie como consola también en el /boot/grub/menu.lst:

title           Debian GNU/Linux VIC serial
root            (hd0,0)
kernel          /boot/vmlinuz root=/dev/hda1 ro console=tty0 console=ttyS0,9600n8
initrd          /boot/initrd.img
savedefault

En el fichero Documentation/kernel-parameters.txt de las fuentes del kernel vemos las posibles opciones para el parámetro console:

      console=        [KNL] Output console device and options.

                tty  Use the virtual console device .

                ttyS[,options]
                ttyUSB0[,options]
                        Use the specified serial port.  The options are of
                        the form "bbbbpnf", where "bbbb" is the baud rate,
                        "p" is parity ("n", "o", or "e"), "n" is number of
                        bits, and "f" is flow control ("r" for RTS or
                        omit it).  Default is "9600n8".

                        See Documentation/serial-console.txt for more
                        information.  See
                        Documentation/networking/netconsole.txt for an
                        alternative.

                uart,io,[,options]
                uart,mmio,[,options]
                        Start an early, polled-mode console on the 8250/16550
                        UART at the specified I/O port or MMIO address,
                        switching to the matching ttyS device later.  The
                        options are the same as for ttyS, above.

Conectamos el cable null modem, abrimos el Hyperterminal, reiniciamos, y ya tenemos un acceso por el puerto serie al arranque de la máquina (excepto a la parte de la BIOS).

Como hemos configurado el GRUB para aceptar salida por el puerto serie y por la consola normal, nos muestra el mensaje “Press any key to continue” en ambos sitios para que él sepa dónde tiene que presentar el menú en función de dónde se pulse una tecla:

serial GRUB “Press any key to continue”

Si pulsamos la tecla en el terminal serie, nos aparecerá el menú normal de GRUB:

serial GRUB menú

Si elegimos un kernel sin opciones para consola serie, lo último que veremos en el terminal serie (hasta que el getty, si está configurado, tome el control de la línea) es el mensaje del kernel que se arranca:

serial load kernel

y si elegimos uno con salida al puerto serie podremos seguir el arranque remotamente:

serial kernel booting

y la parada (vemos que los códigos para cambiar el color del texto han dejado modificado el color de las fuentes):

serial kernel halting

Sin embargo, no es fácil hacer esto mismo a través de módem, porque se requiere un dumb modem, algo bastante raro hoy en día. Un dumb modem de verdad no acepta comandos Hayes o tiene un modo para configurarlo para que no los use. Típicamente se configura con DIP switches y simplemente está conectado al puerto serie, contesta la llamada (si está configurado para ello) y pasa lo que recibe al puerto serie sin más complicaciones.

Un módem normal de los modernos es capaz de hacer muchas más cosas y además se configura con comandos Hayes. Es posible usar una serie de comandos para hacer que un módem normal se comporte como un dumb modem, pero al reiniciarlos apagándolos y encendiéndolos pierden la configuración, por lo que en muchos casos no nos son realmente útiles.

:wq

Entradas relacionadas

19 Comentarios a “Configurar Linux para permitir el acceso remoto por módem a la consola y por RAS/PPP”

  • Fernando dice:

    Me encanta el articulo ! No se porque sigo encontrando mucho gusto cuando configuro cualquier cosa mediante puerto serie y nunca se me había ocurrido hacerlo a mi Debian.

  • Fernando Me alegro de que te haya gustado. Tienes razón, el acceso por puerto serie da usa sensación como a algo como muy obsoleto (muchos ordenadores ya ni lo llevan) pero a la vez muy consolidado en el mundo de la informática.

    Y la verdad es que ahora Debian lo pone muy fácil. Hace muchos años configuré un viejo XT como “terminal tonto” de un Linux desde MS-DOS y me costó sudor y lágrimas conseguir que funcionara.

  • Lucas Perez dice:

    Me parecen muy buenos tus artículos. Enhorabuena.

  • Lucas Perez ¡Me alegro de que te gusten! ¡Gracias por la visita!

  • RuBiCK dice:

    Muy interesante. Con cosas como estas se consigue que un pc se “parezca” más a los caros servidores.

    Lo próximo es hacer un libro de todos tus posts :)

  • RuBiCK ¡Gracias! ¡Me alegro de que te haya parecido interesante!

    Lo del libro es como excesivo, ¿no? ;-)

  • Iván dice:

    Me ha parecido muy interesante el artículo, sobre todo lo del servidor RAS, aunque la redirección del grub por el puerto serie es muy curiosa.
    Yo también hace muchos años configuré un antiguo portatil 286 como cliente de mi linux (por aquel entonces creo que era un Redhay myu muy antiguo) y lo hice desde msdos con el cliente kermit (que también utilizaba con mi HP48GX). Qué tiempos aquellos…

    Saludos, Iván.

  • @Iván ¡Me alegro de que te haya gustado! ¿Tú también eres de la banda de los de la HP48GX y el Kermit? ¡Vaya follón para transferir los ficheros siempre! ;-)

  • Ringmaster dice:

    SuperCoco: Un consejillo: reduce la resolución del ordenador cuando hagas pantallazos; habrá gente con pocos recursos que también querrá aprender y las imágenes se le saldrán de su pantalla de 800×600… jeje.

  • @Ringmaster Sí, tienes razón. Si te fijas, procuro no pasar de 400px de ancho en las imágenes. 600px a lo sumo. Sin embargo, en este caso, quería poner las capturas tal cual eran, y han quedado un poco grandes.

    Gracias por el consejo

  • AlBundy dice:

    Im-presionante. Un 10.

  • Iván dice:

    ERA de la banda de la HP48GX. Como ya hacía mucho (muchísimo) tiempo que no la usaba y la tenía por ahí escondida en un cajón. Cuando la encontré hace unos meses y vi que seguía funcionando a la perfección y que estaba como nueva (sin golpes, arañazos y demás), me decidí a venderla.
    En fin, qué buenos ratos me dio la calculadora…

    Saludos, Iván.

  • Fede dice:

    Se puede poner consultas aqui? Tengo un problema con la conexion remota por modem a un servidor unix. Gracias
    Fede

  • @Fede No, me temo que este no es el sitio adecuado…

  • Fernando dice:

    Necesito hacer una conexion entre 2 pcs, una con linux y otra con windows.
    Ese tipo de conexion es “cable nulo”? o es con cables por el puerto serial
    directamente? Segui las instrucciones para conectarlo por COM3 pero no funciona

    tenes alguna idea que me pueda ayudar?

    saludos!

  • @Fernando Si quieres conectar un Windows y un Linux por el puerto serie seguro que lo puedes hacer con el protocolo PPP, de una forma muy parecida a la que se ha seguido aquí pero sin los módems. Lo que pasa es que como no he probado a hacerlo nunca no sé los detalles de cómo hacerlo.

Trackbacks y pingbacks:

Tema LHYLE09, creado por Vicente Navarro