Archivo de la etiqueta: kernel

Conectar Ubuntu 9.10 con Internet Everywhere de Orange usando wvdial

Con Ubuntu 9.10, Internet Everywhere de Orange con un modem Huawei E160E funciona «out of the box», es decir, enchufar y listo, al menos en mi sistema y con un kernel 2.6.31-20, que es el que actualmente se instala automáticamente con la actualización rutinaria de paquetes que lanza el sistema.

Pero si por cualquier motivo quieres usar wvdial, también puedes hacerlo.

Naturalmente, lo primero será instalar wvdial con «sudo apt-get install wvdial». Y después tienes que crear un fichero /etc/wvdial.conf tal que así:

[Dialer Orange]
Init1=ATZ
Init2=ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Phone=*99#
Username=ORANGE
Password=ORANGE
Modem=/dev/ttyUSB0

[Dialer pin]
Modem = /dev/ttyUSB0
Baud = 115200
Init1 = AT+CPIN=1234

Obviamente, tendrás que poner el verdader pin en la entrada «CPIN» de [Dialer pin].

Ahora, para conectarte, solo tendrás que hacer:

[lacofi@sophie]$ sudo su
password:
[root@sophie]# wvdial pin
[root@sophie]# wvdial Orange
--> Carrier detected.  Waiting for prompt.
--> Don´t know what to do!  Starting pppd and hoping for the best.
--> Starting pppd at Thu Sep 27 13:04:29 2007
--> Warning: Couldn´t modify /etc/ppp/pap-secrets: Permission denied
--> --> PAP (Password Authentication Protocol) may be flaky.
--> Warning: Couldn´t modify /etc/ppp/chap-secrets: Permission denied
--> --> CHAP (Challenge Handshake) may be flaky.
--> Pid of pppd: 15838
--> Using interface ppp0
--> local  IP address 83.188.171.59
--> remote IP address 10.64.64.64
--> primary   DNS address 130.244.127.161
--> secondary DNS address 130.244.127.169

Observa que hago la conexión como root. Si quieres hacerla como usario normal, lo único que tienes que hacer es meter a ese usuario en el grupo «dip», porque si no, no tendrás permisos suficientes para ejecutar pppd:

Para meter al usuario lacofi en el grupo dip, tienes que editar el fichero /etc/group, buscar la entrada «dip» y poner «lacofi» (o varios usuarios separados por comas) al final, así:

dip:x:30:lacofi,maria

Pero recuerda que para que el nuevo grupo entre en vigor tienes que deslogar y volver a logarte.

Cómo encriptar una partición de disco duro con dm-crypt

A mi me surgió esta «necesidad» porque quería asegurarme de que nadie pueda leer mi disco duro externo portátil en caso de que me lo roben, pero hay muchos motivos para hacerlo. Unos ejemplos:

  1. Quieres encriptar un disco duro externo USB por si te lo roban. En ese caso, podrias encriptarlo con una contraseña que solo tú sabes, y debes teclear cada vez que lo enchufas. Es el ejemplo más sencillo.
  2. Quieres encriptar todos los datos privados que hay en tu ordenador (carpetas personales, fotos, documentos, etc): si se te estropea el ordenador, quieres estar seguro de que el servicio técnico no toqueteará en tus cosas. En ese caso podrías usar una contraseña tecleada cada vez que arrancas la máquina, pero es un poco peñazo, ¿no?. Es más práctico generar una contraseña aleatoria de, por ejemplo, 1024 bytes y meterla en un fichero en un lápiz USB, de tal forma que si el ordenador arranca con ese lápiz metido, puedes acceder a tus datos, pero si no, no.
  3. Quieres encriptar un disco duro externo USB por si te lo roban, pero manejas datos empresariales, o muy confidenciales (como datos médicos), o simplemente eres un paranoico del carajo. En ese caso puede que desconfies de una contraseña tan sencilla como para poder recordarla, y tampoco te fias de que no te roben el lápiz USB con la contraseña aleatoria. En ese caso, puedes encriptar el fichero con la clave con GNUpg, de tal forma que te pida una contraseña tecleada para poder usarlo. Parece un trabalenguas, pero en la práctica significa que para que alguien pueda leer el disco duro USB necesita tener el lápiz USB con la contraseña, y saber la frase de paso que hay que teclear (y que solo tu sabes). Tendrían que robarte, registrarte y torturarte a la vez, vamos. ;-)

Hay mucha documentación en la red para los que quieren encriptar una partición o un fichero loopback con dm-crypt. Por lo que tengo entendido, es el sistema recomendado, incluso por encima de loop-AES, que sería la alternativa más cercana. Si quieres probar con loop-AES, puedes echar un vistazo a la documentación. Yo lo he probado y te aseguro que funciona a la perfección.

Pero como parece que en los foros se recomienda más dm-crypt, al final me decidí por él.

Como está todo bien explicado en la red, lo que te pongo aquí es solo un resumen rápido de los pasos que seguí yo. Asumo que tienes Gentoo como yo, pero se puede hacer lo mismo en una Debian o un Ubuntu con muy pocas modificaciones. Si quieres más detalles o hacer algunas virguerías, échale un vistazo al HOWTO en castellano, al Tutorial resumido que usé yo, o al Gentoo Wiki más completo, que viene con un montón de detalles.

Lo primero que necesitas es un kernel adecuado. Muchas distribuciones ya incluyen el soporte a la encriptación dm-crypt de serie, como por ejemplo Fedora. Si no es así, entonces tendrás que compilar uno a medida.

Te animo a que compiles un kernel propio, incluso aunque el kernel de serie te funcione sin problemas. Un kernel propio te proporciona mucha flexibilidad a la hora de añadir cosas «finas» a tu sistema. Encriptar una partición de disco duro es un ejemplo, pero como esto hay muchas más, cosas que puedes ajustar o añadir, pero necesitas activar ciertas opciones del kernel. Modificar un kernel ya creado es muy facil, pero hacer uno nuevo desde cero puede ser un poco tortuoso, asi que piensa que tener un kernel propio es como tener mucho trabajo adelantado de cara al futuro.

Haz un «make menuconfig», entra en «Device Drivers» y luego en la opción que dice «RAID and LVM support». Activa las opciones «Multiple devices driver support (RAID and LVM)», «Device mapper support», y «Crypt target support». Ahora vuelve a la raiz y entra en «Cryptographic Options». Ahí yo lo activaría todo como módulos, pero tú tienes que activar al menos «AES cipher algorithims (i586)». Ahora vuelve a la raiz y entra en «Device Drivers» y luego en «Block Devices». Ahí, activa «Loopback device support». Vuelve al sistema y recompila.

Ojo, si quieres tener simultáneamente una unidad loop-AES, además de dm-crypt, has de saber que loop-AES te exige que desactives la opción «Loopback device support» del kernel, y que hagas un «emerge loop-aes» para compilar una versión modificada del módulo «loop» que está en Portage. Hazlo así, a dm-crypt no le importará, siempre y cuando te acuerdes de hacer un «modprobe loop» para que dm-crypt no se queje de que le falta el soporte de dispositivos loopback.

Bien, si vas a usar un fichero de contraseña, lo primero es crear el fichero, claro. Esto lo puedes hacer así, lo que crearía una contraseña fuerte de 1024 caracteres aleatorios (a que no hay narices a memorizarlos):

[root@jeanne ~]# head -c 1024 /dev/urandom > /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chown lacofi:users /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chmod go-rwx /mnt/usbdisk/.clave_discoduro.txt

Si quieres encriptar ese fichero con GnuPG, entonces será necesario teclear una passphrase cada vez que quieras usar el archivo de contraseña. Eso es algo así como usar una contraseña para desencriptar tu contraseña:

[root@jeanne ~]# head -c 3172 /dev/urandom | \
				uuencode -m - | grep -v ==== | tail -n 65 | \
				gpg --symmetric -a > /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chown lacofi:users /mnt/usbdisk/.clave_discoduro.txt
[root@jeanne ~]# chmod go-rwx /mnt/usbdisk/.clave_discoduro.txt

Y por supuesto, si no quieres complicarte la vida, puedes no especificar ningún fichero de contraseña. Te pedirá una sobre la marcha y tendrás que teclearla a mano todas las veces que montes la unidad.

Observa que me he asegurado de que el fichero que contiene la contraseña es accesible por mí y por nadie más, pero ahí puedes jugar un poco con los permisos según tus necesidades.

Ahora instala cryptsetup.

[root@jeanne ~]# emerge cryptsetup

Ahora MACHACA el contenido de la partición. ¡Cuidado, este comando que sigue destruirá permanentemente cualquier dato que esté en la partición!. ¡De eso se trata, así que no te confundas!.

[root@jeanne ~]# shred -n 1 -v /dev/lacie_backup1
shred: /dev/lacie_backup1: pass 1/1 (random)...
shred: /dev/lacie_backup1: pass 1/1 (random)...16MiB/120.0GiB 1%
shred: /dev/lacie_backup1: pass 1/1 (random)...87MiB/120.0GiB 2%
shred: /dev/lacie_backup1: pass 1/1 (random)...108MiB/120.0GiB 3%
(tómate un café, porque esto puede tardar un buen rato...)

Luego crea un dispositivo mapper (al final, lo que acabarás montando será este dispositivo mapper, y no el dispositivo real). Las instrucciones originales recomiendan también encriptar la partición swap, para que nadie pueda acceder a los datos temporales, pero como yo solo quiero proteger un disco duro portátil y ahí no habrá ninguna partición swap, puedo saltarme este paso.¡Cuidado, este comando que sigue también destruirá permanentemente cualquier dato que esté en la partición, no te confundas de sitio!.

Si estás usando un fichero de contraseña:

[root@jeanne ~]# cryptsetup -v luksFormat /dev/lacie_backup1 /mnt/usbdisk/.clave_discoduro.txt

WARNING!
========
This will overwrite data on /dev/lacie_backup1 irrevocably.

Are you sure? (Type uppercase yes): <YES>
Command successful.

Si omites /mnt/usbdisk/.clave_discoduro.txt te pedirá una passphrase en la línea de comandos. En ese caso te recomiendo que uses la opción «-y», para que te la pida dos veces, y así no tendrás problemas en caso de que te equivoques al teclear.

Si prefieres encriptar el fichero de contraseña con GnuPG:

[root@jeanne ~]# gpg --quiet --decrypt /mnt/usbdisk/.clave_discoduro.txt | \
> cryptsetup -v luksFormat /dev/lacie_backup1
Introduce la passphrase: <aqui metes la passphrase>
gpg: ATENCIÓN: la intgridad del mensaje no está protegida
Command successful.

Observa que el dispositivo que uso es /dev/lacie_backup1 y no /dev/sdb1. Eso es porque tengo bien configurado UDEV. Te lo recomiendo sinceramente.

Ahora tienes que abrir el dispositivo mapper que acabas de crear.

Si usas un fichero de contraseña:

[root@jeanne ~]# cryptsetup --key-file /mnt/usbdisk/.clave_discoduro.txt \
> luksOpen /dev/lacie_backup1 encriptado
key slot 0 unlocked.
Command successful.

Si omites «–key-file /mnt/usbdisk/.clave_discoduro.txt» debería pedirte la contraseña en línea de comandos. Obviamente no serás capaz de recordarla, si la contraseña son 1024 caracteres aleatorios, pero sí si es solo una contraseña tecleada. En cualquier caso, con esto queda abierto y accesible el dispositivo mapper con nombre «encriptado».

Si usas un fichero de contraseña encriptado con GnuPG:

[root@jeanne ~]# gpg --decrypt /mnt/usbdisk/.clave_discoduro.txt 2>/dev/null | \
> cryptsetup luksOpen /dev/lacie_backup1 encriptado
key slot 0 unlocked.
Command successful.

Ahora ya tienes el dispositivo /dev/mapper/encriptado que es con lo que vas a trabajar. Para tí, /dev/lacie_backup1 ya no importa. Bien, pues ahora tienes que formatear el dispositivo. Algunos recomiendan no usar un sistema con journaling porque teoricamente puede producir corrupción de datos. Yo estoy usando ext3 hasta ahora sin problemas.

[root@jeanne ~]# mkfs.ext3 /dev/mapper/encriptado

Y ahora ya puedes crear el punto de montaje y montarlo:

[root@jeanne ~]# mkdir /mnt/lacie_backup
[root@jeanne ~]# mount /dev/mapper/encriptado /mnt/lacie_backup -t ext3 -o rw

El siguiente paso sería meter una entrada nueva en tu fstab:

/dev/mapper/encriptado  /mnt/lacie_backup  ext3  user,noauto,rw  0 0

Con esto, la configuración ya está.

A partir de ahora, para acceder a tu partición metiendo la contraseña a mano (sin fichero de contraseñas) tendrás que ejecutar, también a mano:

[root@jeanne ~]# cryptsetup luksOpen /dev/lacie_backup1 encriptado
(aquí pedirá la contraseña)
[root@jeanne ~]# exit
[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Aunque si estás usando un fichero de contraseña en un lápiz USB, puedes meter los comandos en los scripts de inicio del sistema, de tal forma que si está el lápiz enchufado, la máquina desencripte y monte los directorios seguros automáticamente.

Y para desmontar:

[lacofi@jeanne ~]$ umount /mnt/lacie_backup
[lacofi@jeanne ~]$ su
password:
[root@jeanne ~]# cryptsetup remove encriptado
(mientras no hagas esto último, la partición seguirá estando accesible sin
contraseña)

Si usas un fichero de contraseñas encriptado con GnuPG, tendrías que hacer más o menos lo mismo. Para montar:

[root@jeanne ~]# gpg --decrypt /mnt/usbdisk/.clave_discoduro.txt 2>/dev/null |\
> cryptsetup luksOpen /dev/lacie_backup1 encriptado
(aquí pedirá la passphrase)
[root@jeanne ~]# exit
[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Y para desmontar, igual que antes.

Otra opción para automatizar el proceso sería por ejemplo, entrar en /etc/udev/rules.d/10-local.rules, ir a la entrada que identifica el disco duro lacie_backup1 y añadir en esa entrada una regla tal que así:

RUN+="cryptsetup --key-file /mnt/usbdisk/.clave_discoduro.txt luksOpen /dev/lacie_backup1 encriptado"

Con lo que cada vez que enchufes el disco duro portátil en ese ordenador, se abrirán todos los cerrojos y quedará listo para montarlo (siempre y cuando esté metido el lápiz USB con las claves):

[lacofi@jeanne ~]$ mount /mnt/lacie_backup

Observa que ya ni siquiera necesitamos ser root.

Pero la mejor automatización es la que viene ya de serie en todas las distribuciones Linux actuales, que tienen luksOpen integrado en el sistema, de tal manera que si tienes encriptado un disco, será reconocido directamente en el arranque sólo configurando /etc/crypttab con las claves y /etc/fstab con el punto de montaje.

Así, puedes introducir en /etc/crypttab una línea tal que así:

# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/ paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: Do not list your root (/) partition here, it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
#
#                                                                                                                          
encriptado	UUID=bb792154-e58e-4fd8-a2c0-ba3c8cb4cbd8	/mnt/usbdisk/.clave_discoduro.txt

Observa la última línea, donde se especifica el dispositivo mapper que estará asociado al disco, el UUID del disco y el fichero de claves. Esta configuración será leída en el arranque, después de montar todas las unidades, con lo que el dispositivo mapper estará listo y cargado para que que /etc/fstab pueda montarlo.

/dev/mapper/encriptado  /mnt/lacie_backup  ext3  user,noauto,rw  0 0

Que lo disfrutes.

He actualizado mi kernel, y ahora mi Pinnacle PCTV solo mete ruido

Tienes un kernel 2.6.12, y un buen día decides actualizarlo a uno más nuevo, por ejemplo un 2.6.18, como me ocurrió a mí. Y entonces descubres que tu tarjeta capturadora de televisión, una Pinnacle PCTV que usa el módulo bttv, ha perdido el sonido, y solo se oye un horroroso ruido de estática.

Acabas de encontrar un bug en los kernels superiores a 2.6.12, que hace que el audio se vaya al carajo cuando se cargan los modulos automáticamente en el arranque o usando «modprobe bttv» y dejando que las dependencias lo resuelvan todo. Si te ocurre esto, prueba a cargar primero el módulo tuner y despues el módulo bttv.

 
[lacofi@jeanette ~]$ su
password:
[root@jeanette /home/lacofi]# rmmod bttv tuner
[root@jeanette /home/lacofi]# modprobe tuner
[root@jeanette /home/lacofi]# modprobe bttv

Si esto te funciona correctamente, puedes meter los comandos en algún fichero de autoarranque, para que siempre se carguen los módulos en el orden adecuado ya desde el boot. En el caso de Gentoo, puedes editar el fichero /etc/conf.d/local.start y poner los comandos:

 
# Fichero /etc/conf.d/local.start
rmmod bttv tuner
modprobe tuner
modprobe bttv

En mi caso, esto solucionó el problema.

Tras actualizar mi kernel, compilar slmodem da errores «warning» y rechaza instalarse

Has compilado una versión reciente de tu kernel, y despues haces un «emerge slmodem» (en el caso de Gentoo). La compilación da varios errores tipo warning que no abortan el proceso, por lo que acaba compilándose de todas formas.

Sin embargo, cuando intentas instalar los drivers te encuentras con que el kernel dice que nones:

[root@lynette]# modprobe slamr
FATAL: Error inserting slamr (/lib/modules/2.6.15-kal/extra/slamr.ko): 
Unknown symbol in module, or unknown parameter (see dmesg)

Vale. Acudes a dmesg para ver que te dice, y te suelta esto:

[root@lynette]# dmesg
[bla bla bla...]
slamr: Unknown symbol class_simple_device_add
slamr: Unknown symbol get_device
slamr: Unknown symbol class_simple_destroy
slamr: Unknown symbol put_device
slamr: Unknown symbol class_simple_device_remove
slamr: Unknown symbol class_simple_create
slamr: Unknown symbol device_release_driver

¿Que significa esto y cómo se soluciona?. Bueno, lo que está pasando es que tu nuevo kernel ya no tiene determinados simbolos que slmodem necesita: en otras palabras, o tu kernel es demasiado nuevo o tu versión de slmodem es demasiado vieja. Tienes que reducir la versión del kernel, o instalar un slmodem más reciente.

Asumiendo que no quieres regresar a un kernel más viejo, solo te queda instalar una versión más calentita de slmodem.

En mi caso, este problema me surgió al actualizar a un kernel 2.6.15 para un slmodem 2.9.9d. El problema es que al hacer «emerge slmodem», esa era la versión que se instalaba. Asi que la solución en Gentoo es sencilla: hay que desenmascarar el paquete slmodem para permitir que se instalen las versiones más nuevas (e inestables):

[root@lynette]# echo "net-dialup/slmodem ~x86" >> /etc/portage/package.keywords &&
> emerge slmodem
Calculating dependencies ...done!
>>> emerge (1 of 1) net-dialup/slmodem-2.9.11_pre20051101 to /
>>> md5 files   ;-) slmodem-2.9.9d.ebuild
[etc... ]

Desde que cambié a UDEV, he perdido /dev/lp0

Si has cambiado a un sistema UDEV puro, puede que descubras que tu impresora paralelo deja de funcionar. Si rascas un poco, te encontrarás con que el dispositivo /dev/lp0 no existe.

En realidad no es un problema de UDEV, sino del kernel. Resulta que en los kernels más nuevos, se asume que no es necesario el módulo que controla el puerto paralelo. ¿Por qué?. Bueno, hoy en día la mayoría de las impresoras son USB, así que el puerto paralelo está un poco en desuso (solo se usa para eso, y ya ni para eso). Asi que el kernel no carga ese módulo salvo que se le indique específicamente con una órden:

[lacofi@jeanette ~]$ su
Password:
[lacofi@jeanette /home/lacofi]# modprobe lp

Una vez cargado el módulo, comprobarás que se ha creado correctamente el dispositivo /dev/lp0.

Si tienes una impresora paralelo, seguramente querrás que este módulo se cargue siempre en el arranque. Para eso, solo tienes que meterlo en el listado de /etc/modules.autoload.d/kernel-2.6:

# /etc/modules.autoload.d/kernel-2.6:  kernel modules to load.
# $Header: [bla bla bla] azarah Exp $
#
# Note that this file is for 2.6 kernels.
#
# Add the names of modules that you'd like to load when the system
# starts into this file, one per line.  Comments begin with # and
# are ignored.  Read man modules.autoload for additional details.

# For example:
# 3c59x

kqemu
lp # <-- ahí

He recompilado mi kernel, pero ahora no funcionan los gráficos

Si has actualizado alguna vez tu kernel, tal vez hayas comprobado que una vez recompilado e instalado, es muy posible que dejen de funcionar algunas cosas como la red WiFi, los gráficos (X Window), etc.

Ocurre que hay una serie de funciones en el sistema que se compilan como módulos del kernel. Por eso, si has cambiado de kernel, los modulos ya no están o, aunque estén, posiblemente no sirvan porque son de versión incorrecta.

La solución es muy simple: tendrás que recompilar también todo ese software, cada vez que cambies o recompiles tu kernel. En el momento de redactar estas líneas, el software de mi ordenador portátil que es «sensible a la recompilación del kernel» es: El subsistema de red ieee80211, el driver WiFi (ipw2100), el driver del linmodem SmartLink 56K AC’97 (slmodem), y el driver propietario ATI (ati-drivers).

De esta forma, cada vez que recompilo mi kernel, después tengo que hacer (en un sistema Gentoo):

[lacofi@lynette ~]$ su
password:
[root@lynette /home/lacofi]# emerge ieee8011 &&
> emerge ipw2100 &&
> emerge slmodem &&
> emerge ati-drivers

Lucent Winmodem en Knoppix

Cuando estoy en casa, el ordenador portatil se conecta al de sobremesa y ambas comparten la salida a Internet repartiéndose el ancho de banda como buenas hermanas. Bien… esto puede hacerse usando una red Ethernet convencional o una red WiFi, que es lo más normal hoy en día. Pero además de conectarlos en red, se puede incluso conectar el portátil como «terminal tonto» del de sobremesa, con lo que éste último está siendo entonces usada por dos usuarios simultáneos, pero no voy a contar aquí ese tema, puesto que los chicos de Bulma ya lo han hecho muy bien (de hecho, ese truco lo aprendí de ellos).

El problema es cuando NO estas en casa. En ese momento el portátil no puede salir a Internet porque le falta su salida habitual a la red.

Los Toshiba Satellite 2100 CDS, como mi vieja moira, estaban equipados de serie con un módem interno, con el que podría conectar con otro proveedor. Pero se trata de un Winmodem, con lo que lo primero es conseguir que funcione en linux. :-(

Afortunadamente, el fabricante del modem es Lucent, que tiene el buen sentido de publicar drivers para linux, tanto en forma de módulos instalables, como en forma de código fuente.

Aunque cuando estaba en activo moira, Lucent incluía módulos para RedHat, Debian, etc… pero no para Knoppix.

Vale, ¿qué se podía hacer?.

Pues se podía instalar el código fuente, claro. Pero eso exige instalar las fuentes del kernel, entre otras cosas. Sin entrar en detalles, digamos que como que no me apetecía demasiado. Claro que Knoppix viene a ser una Debian testing, ¿no?.

Pues sí, lo es. Así que nos vamos a la página adecuada, seguimos el enlace con los drivers de Lucent (si nos deja, porque la última vez que lo intenté, me pedía un login y una contraseña para entrar). Luego nos bajamos el paquete Debian correcto y lo instalamos. Ya está, digo yo.

Pues no. Porque resulta que son módulos compilados para el kernel 2.4.20, y Knoppix usa el 2.4.20-xfs (uuuuyyyy…), con lo que si intentamos hacer un modprobe nos saltan todos los unresolved symbols y a freir espárragos. Eso, sin tener en cuenta que los módulos no están donde deberían…

Vale. La solución más fácil y rápida (también la menos ortodoxa) era forzar la carga de los módulos:

[root@moira lacofi]# insmod -f /lib/modules/2.4.20/ltmodem/lt_modem.o

Y nos contesta:

Warning: kernel-module version mismatch
/lib/modules/2.4.20/ltmodem/lt_modem.o was compiled for kernel
version 2.4.20 while this kernel is version 2.4.20-xfs
Warning: loading /lib/modules/2.4.20/ltmodem/lt_modem.o will
taint the kernel: non-GPL license - UNKNOWN
See http://www.tux.org/lkml/#export-tainted for information about
tainted modules
Warning: loading /lib/modules/2.4.20/ltmodem/lt_modem.o will
taint the kernel: forced load
Module lt_modem loaded, with warnings

(Que traducido, significa «¡Uy lo que me ha dicho!. Vale, no es muy ortodoxo y te aviso, pero lo hago»).

Ahora cargamos el segundo módulo (el orden es importante, al reves no lo admite):

[root@moira lacofi]#insmod -f /lib/modules/2.4.20/ltmodem/lt_serial.o
Warning: kernel-module version mismatch
/lib/modules/2.4.20/ltmodem/lt_serial.o was compiled for kernel
version 2.4.20 while this kernel is version 2.4.20-xfs
Warning: loading /lib/modules/2.4.20/ltmodem/lt_serial.o will
taint the kernel: forced load
See http://www.tux.org/lkml/#export-tainted for information about
tainted modules
Module lt_serial loaded, with warnings

Tras esto nos aseguramos de que exista el dispositivo /dev/ttyLT0, que es el que representa al propio modem. Si no es así, podemos crearlo a mano:

[lacofi@moira lacofi]$ ls /dev/ttyLT0
ls: /dev/ttyLT0: No existe el fichero o el directorio
[lacofi@moira lacofi]$ su
password:
[root@moira lacofi]# cd /dev
[root@moira dev]# mknod /dev/ttyLT0 c 62 64
[root@moira dev]# chown root.root /dev/ttyLT0
[root@moira dev]# chmod a+rw /dev/ttyLT0
[root@moira dev]# ln -s /dev/ttyLT0 /dev/modem
[root@moira dev]# exit
[lacofi@moira lacofi]$

También convendría crear un enlace /dev/modem apuntando a /dev/ttyLT0, porque muchos programas acuden automáticamente a /dev/modem cuando necesitan usarlo.

[root@moira rc5.d]# ln -s /dev/ttyLT0 /dev/modem

Sin embargo, comprobaremos que el enlace /dev/modem desaparece cada vez que rearrancamos la máquina. Esto ocurre porque lo borra el script /etc/init.d/knoppix-autoconfig, que es el que ejecuta toda la maravillosa autoconfiguración del Knoppix en el arranque. Bueno, pues solo hay que editarlo, irse a la linea donde dice:

# Delete obsolete links and files before starting autoconfig
rm -f /dev/cdrom* /dev/cdwriter* /dev/mouse* /dev/modem*
/dev/scanner* /etc/sysconfig/i18n /etc/sysconfig/keyboard \
/etc/sysconfig/knoppix 2>/dev/null

… y borrar lo que he marcado en color cian. Lo principal ya está. Ahora arrancamos el KPPP y veremos que detecta el modem y conecta sin problemas. Pero en mi caso, quería tener los módulos cargados desde el arranque, así que pongo en /etc/init.d un script llamado «ltmodem», con permisos de lectura y ejecución:

#!/bin/sh
insmod -f /lib/modules/2.4.20/ltmodem/lt_modem.o
insmod -f /lib/modules/2.4.20/ltmodem/lt_serial.o

A continuación se hace un link a /etc/rc5.d

[lacofi@moira lacofi]$ cd /etc/rc5.d
[lacofi@moira rc5.d]$ su
Password:
[root@moira rc5.d]# ln -s ../init.d/ltmodem S29ltmodem

Y esto fue todo. El módem siempre listo y la Red siempre a punto, por los siglos de los siglos… :-)

Naturalmente, todo esto es probablemente inútil a estas alturas, porque el tiempo ha pasado y tanto Knoppix como todas las demás distribuciones deberían soportar de serie los Winmodems Lucent. Así que la respuesta correcta probablemente sea: «actualiza tu sistema operativo, por Dios». Pero además porque moira ha muerto dejando su sitio a lynette. En cualquier caso, dicho queda para nostálgicos y curiosos a modo de ejercicio. Quizás le de alguna idea a alguien, con otro problema de hardware distinto, en Knoppix.