experiencia de internet 3G en linux


Al hilo del artículo de ayer referente a la situación de Linux en el nuevo mercado de las comunicaciones de datos 3G, en concreto de la conexión a Internet por medio de las redes de comunicaciones móviles 3G (en concreto tecnología móvil 3,5G), voy a contar mi fugaz experiencia en la conexión a Internet por medio de una tarjeta vendida comercialmente por Movistar, que tuve la oportunidad de probar en mi última semana de trabajo en mi anterior empresa.

Además las condiciones de prueba, haciéndolo con Linux (Ubuntu), lo han hecho más interesante todavía. De momento solamente me interesa como una cuestión de curiosidad, ya que las tarifas y restricciones de uso se salen de mi perfil de uso y mis posibilidades económicas.

Iré desgranando mi experiencia en este artículo principal y en los comentarios en días posteriores (hice una especie log de lo que iba experimentando y tengo que ordenar lo que puede ser útil y lo que no, cosa que necesita tiempo y que haré este fin de semana)

He tenido acceso a una tarjeta PCMCIA módem 3G Huawei E612 y a un módem 3,5G USB ZTE MF 620. La experiencia con la primera terminó nada más intentar introducirla en la ranura de expansión ExpressCard de mi portátil. Resulta que PC-Card (ex-PCMICIA) y ExpressCard son tecnologías distintas e incompatibles. Es una pena, porque este tipo de tarjetas de esta compañía china prometen en el mundo Linux como demuestra el producto Huawei E220 producido para Vodafone Mobile Connect (se puede ver un tutorial de instalación que puede servir de modelo para el de ZTE en foro de Ubuntu) Este último es muy parecido otro modelo, que distribuye en este caso Movistar …

El segundo dispositivo es un módem USB externo, lo cual en principio representa un reto en el mundo Linux, como ha ocurrido con todos los módems externos que se han producido, también en el caso de las redes fijas (ADSL, por ejemplo) En este caso me ha resultado muy complicado encontrar información sobre su uso o intento de uso en Linux. Una de las referencias más interesantes para investigar me la he encontrado en un blog personal que presenta un intento, aparentemente con éxito, de configurar un modelo ligeramente más avanzado de módem. Por lo visto este dispositivo tiene una doble personalidad :) Al conectarse al interfaz USB simula ser un dispositivo de almacenamiento externo, que es detectado como un CD, en el que se encuentra software para instalar en Windows (en este caso drivers y la utilidad de Escritorio Movistar) La siguiente vez que se conecta o si se deja pasar un rato, el dispositivo se convierte en un módem.

El secreto es aprovechar el sistema udev de Linux para detectar la inserción del dispositivo y sus cambios de personalidad, ejecutando los comandos adecuados de inserción y borrado de módulos del kernel para la comunicación con el dispositivo, mediante un script especial de udev que viene en la entrada del blog. Luego es cuestión de usar un programa clásico de conexión como ppp en su forma de dominio pppd (quizá con ayuda de alguna utilidad extra como wvdial), opcionalmente con su interfaz gráfico en gnome o kde. También, según el autor de la entrada del blog se puede acudir a programas específicos como UMTSMon.

Hay métodos alternativos a udev, a los que el autor de la entrada del blog acudió antes de hacer el script pero sin éxito. Uno de ellos muy interesante, con soporte experimental del módem ZTE MF620, es USB ModeSwitch. Esta utilidad está especialmente diseñada para los que llama Switchable USB Devices, que son estos dispositivos de doble personalidad :)

He realizado una primera prueba a lo loco de conectar el módem USB a ver que pasa en los logs y en los módulos cargados dinámicamente en el kernel por udev de Ubuntu. Lo único que he pillado es el log de /var/log/messages:

< Dec 27 18:39:10 yerart kernel: [675613.560000] usb 2-1: new full speed USB device using uhci_hcd and address 6
Dec 27 18:39:10 yerart kernel: [675613.720000] usb 2-1: configuration #1 chosen from 1 choice
Dec 27 18:39:10 yerart kernel: [675613.724000] scsi4 : SCSI emulation for USB Mass Storage devices
Dec 27 18:39:21 yerart kernel: [675624.336000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:21 yerart kernel: [675624.488000] scsi 4:0:0:0: CD-ROM ZTE Corp USB Storage 2.31 PQ: 0 ANSI: 2
Dec 27 18:39:21 yerart kernel: [675624.496000] sr1: scsi3-mmc drive: 10x/0x xa/form2 caddy
Dec 27 18:39:21 yerart kernel: [675624.496000] sr 4:0:0:0: Attached scsi generic sg2 type 5
Dec 27 18:39:22 yerart kernel: [675624.928000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:32 yerart kernel: [675635.184000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:33 yerart kernel: [675635.744000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:33 yerart kernel: [675636.304000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:34 yerart kernel: [675636.824000] usb 2-1: reset full speed USB device using uhci_hcd and address 6
Dec 27 18:39:34 yerart kernel: [675637.232000] usb 2-1: USB disconnect, address 6
Dec 27 18:39:34 yerart kernel: [675637.232000] sr 4:0:0:0: scsi: Device offlined – not ready after error recovery
Dec 27 18:39:34 yerart kernel: [675637.348000] usb 2-1: new full speed USB device using uhci_hcd and address 7
Dec 27 18:39:35 yerart kernel: [675637.908000] usb 2-1: new full speed USB device using uhci_hcd and address 8
Dec 27 18:39:35 yerart kernel: [675638.468000] usb 2-1: new full speed USB device using uhci_hcd and address 9
Dec 27 18:39:36 yerart kernel: [675638.988000] usb 2-1: new full speed USB device using uhci_hcd and address 10

Dec 27 18:51:30 yerart kernel: [676353.436000] usb 2-1: new full speed USB device using uhci_hcd and address 11
Dec 27 18:51:31 yerart kernel: [676354.000000] usb 2-1: new full speed USB device using uhci_hcd and address 12
Dec 27 18:51:31 yerart kernel: [676354.568000] usb 2-1: new full speed USB device using uhci_hcd and address 13
Dec 27 18:51:32 yerart kernel: [676355.096000] usb 2-1: new full speed USB device using uhci_hcd and address 14

Luego me he enterado que podría haber utilizado lsusb para averiguar el dispositivo detectado en USB. Con lsmod intenté ver los módulos relevantes (usb_storage, usbserial, …) pero no supe sacar nada en claro.

5 comentarios en “experiencia de internet 3G en linux

  1. Realicé una búsqueda más concreta en Google sobre soporte en Linux del módem USB de ZTE.

    Es curioso que casi todos los enlaces que aparecen en primeras posiciones con contenidos relacionados con la instalación estén en portugués :) Además en los foros de Ubuntu hay un hilo de discusión que apunta a una entrada a un blog de hace solamente diez días en la que el autor afirma que le ha funcionado en tres distribuciones: fedora 8, Ubuntu 7.10 (yo tengo instalada la anterior) y PC Linux OS 2007 (también hay una referencia a este artículo en el blog de debian en portugal)

    Por cierto que hay un escritorio movistar para Linux open source y con licencia GPL. Creo que puedo cotillear en el código y su documentación para poder integrar el uso de sus funcionalidades tras poner en marcha el módem ZTE en Linux :) Por otra parte el sitio del movilforum es bastante interesante en sí mismo.

    He pensado que, además de poder utilizar un terminal dedicado exclusivamente a la transmisión de datos, podría utilizar un teléfono avanzado 3G para realizar la misma función, utilizándolo como módem 3G a través de la conexión de un cable de datos USB (o serie, en último caso) o mucho mejor por conexión inalámbrica bluetooth. Todo esto con la misma técnica que con el módem ZTE. He investigado un poco un Nokia N73. En las características técnicas se tiene que viene con un Cable de Conectividad Nokia CA-53. Además, siempre según las especificaciones, existen tres formas de conexión:

    * Pop-Port (TM) con conexión USB 2.0 de alta velocidad
    * Tecnología Bluetooth 2.0
    * Infrarrojos

    que en teoría junto con la utilidad Nokia PC Suite podría conseguir (en windows :)) el milagro de convertirlo en un módem.

    En los foros de Ubuntu he encontrado un hilo de discusión donde se indica que hay gente que ha elaborado un howto de cómo conectar a Internet desde un portátil con el N73 a través de bluetooth!! :)

    Decir a todo esto que el teléfono no es 3G sino que se conecta como GPRS/EDGE. Tendría que buscar un teléfono más avanzado para obtener las prestaciones equivalentes UMTS/HSDPA de ZTE o Huawei …

  2. De la lectura de la entrada del blog ufsoft, se me ocurrió mirar cuál es la configuración udev que tengo en mi Ubuntu y a hacer tres pruebas de conexión previas de dispositivos USB: una webcam y dos discos USB externos (uno tipo llave y otro normal) para ver cuál es su efecto en los módulos cargados en el kernel y en la detección por parte del sistema del tipo de dispositivo USB (Ids …)

    En cada experimento anoté la salida de los comandos: lsmod, lsusb y el contenido relevante de /var/log/messages, además de comprobar el estado de los dispositivos en el directorio /dev y en /proc

    Relato de lo que hice (I)

    En primer lugar la configuración de udev. Aparte de la información y enlaces que tengo ya, he encontrado dos bastante interesantes de RedHat Magazine y de GNU/Linux Desktop Survival Guide by Graham Williams de una empresa australiana llamada Togaware que hace aplicaciones Open Source. La configuración de mi Ubuntu se encuentra en el directorio /etc/udev que contiene el fichero de configuración principal udev.conf que parece contener directivas para introducir entradas en el syslog:

    # udev.conf
    # The initial syslog(3) priority: “err”, “info”, “debug” or its
    # numerical equivalent. For runtime debugging, the daemons internal
    # state can be changed with: “udevcontrol log_priority=”.
    udev_log=”err”

    Luego hay un fichero de reglas llamado libpisock9.rules que contiene las reglas para los dispositivos Pilot Link. Y finalmente hay un directorio llamado rules.d donde se encuentran más ficheros de reglas, ordenadas por prioridad:


    $ ls /etc/udev/rules.d/

    00-init.rules 65-persistent-input.rules
    05-options.rules 65-persistent-storage.rules
    20-names.rules 80-programs.rules
    25-dmsetup.rules 85-alsa.rules
    25-iftab.rules 85-brltty.rules
    30-cdrom_id.rules 85-hdparm.rules
    40-permissions.rules 85-hplj10xx.rules
    45-hplip.rules 85-hwclock.rules
    45-libgphoto2.rules 85-ifupdown.rules
    45-libsane.rules 85-pcmcia.rules
    50-xserver-xorg-input-wacom.rules 90-modprobe.rules
    60-libpisock.rules 95-hal.rules
    60-symlinks.rules 99-udevmonitor.rules
    60-vboxdrv.rules README
    65-libmtp.rules

    El fichero README contiene la explicación del contenido y organización del directorio:

    The files in this directory are read by udev(7) and used when events
    are performed by the kernel. The udev daemon watches this directory
    with inotify so that changes to these files are automatically picked
    up, for this reason they must be files and not symlinks to another
    location as in the case in Debian.

    Files should be named xx-descriptive-name.rules, the xx should be
    chosen first according to the following sequence points:

    00 rules that it is critical to be run first, usually
    only WAIT_FOR_SYSFS

    20 rules that change the name from the device from the default
    (cannot be overriden)

    40 rules that set the permissions of device nodes
    (can be overriden by later rules)

    60 rules that add symlinks to device nodes
    (adds to those set in earlier rules)

    80 rules that run programs (but do not load modules)

    90 rules that load modules

    99 rules that it is critical to be run last

    This scheme has been chosen so that user-supplied rules are normally
    named 50-*.rules for the right thing to happen.

    Packages should chose the approriate sequence point and add 5 to it
    (e.g. 25-iftab.rules, 45-libsane.rules, etc.) unless there is a need
    for a particular order.

    Parece ser que el funcionamiento del asunto es el siguiente. Yo inserto un dispositivo USB en cualquiera de los tres conectores externos. Esta acción es detectada por udev que inicia un proceso de reconocimiento del dispositivo. En función de las identificaciones que reconoce, ejecuta un script (si existe) de los guardadod en rules.d. Este script se encarga de cargar los módulos de kernel que sean necesarios y de crear una entrada en /dev con los permisos necesarios para que el dispositivo pueda ser utilizado por otros programas.

    Ahora antes de hacer las pruebas de conexión de dispositivos USB, voy a ver el estado previo de los módulos cargados en memoria relacionados con USB (como ya he hecho muchas conexiones anteriormente de sicos USB externos y del módem USB ZTE esta relación está un poco adulterada :)):


    $ lsmod|egrep -i '(usb)'

    Module Size Used by

    usb_storage 72256 0
    usbserial 32488 0
    libusual 17936 1 usb_storage
    scsi_mod 142348 6 usb_storage,sbp2,sg,sr_mod,sd_mod,libata
    usbcore 134280 7 usb_storage,usbserial,libusual,ov511,uhci_hcd,ehci_hcd

    Y la lista de dispositivos USB es:


    $ lsusb

    Bus 005 Device 001: ID 0000:0000
    Bus 004 Device 001: ID 0000:0000
    Bus 003 Device 001: ID 0000:0000
    Bus 002 Device 001: ID 0000:0000
    Bus 001 Device 001: ID 0000:0000

    NOTAS: Aparecen 5 dispositivos porque son tres externos más dos internos (la webcam y el interface bluetooth, que aparecen como 0000 porque no están activados)

  3. Qué es lo que hice (II)

    Conectamos el pendrive en un interfaz. El resultado es el siguiente visto desde distintos puntos de vista:

    (1) syslog

    Dec 29 15:44:07 yerart kernel: [837903.820000] usb 1-1: new high speed USB device using ehci_hcd and address 17
    Dec 29 15:44:07 yerart kernel: [837903.992000] usb 1-1: configuration #1 chosen from 1 choice
    Dec 29 15:44:07 yerart kernel: [837903.992000] scsi8 : SCSI emulation for USB Mass Storage devices
    Dec 29 15:44:12 yerart kernel: [837909.012000] scsi 8:0:0:0: Direct-Access Alcor Flash Disk 8.07 PQ: 0 ANSI: 2
    Dec 29 15:44:12 yerart kernel: [837909.016000] SCSI device sdb: 2015232 512-byte hdwr sectors (1032 MB)
    Dec 29 15:44:12 yerart kernel: [837909.016000] sdb: Write Protect is off
    Dec 29 15:44:12 yerart kernel: [837909.020000] SCSI device sdb: 2015232 512-byte hdwr sectors (1032 MB)
    Dec 29 15:44:12 yerart kernel: [837909.020000] sdb: Write Protect is off
    Dec 29 15:44:12 yerart kernel: [837909.020000] sdb: unknown partition table
    Dec 29 15:44:12 yerart kernel: [837909.020000] sd 8:0:0:0: Attached scsi removable disk sdb
    Dec 29 15:44:12 yerart kernel: [837909.020000] sd 8:0:0:0: Attached scsi generic sg2 type 0

    (2) usb

    $ lsusb

    Bus 005 Device 001: ID 0000:0000
    Bus 004 Device 001: ID 0000:0000
    Bus 003 Device 001: ID 0000:0000
    Bus 002 Device 001: ID 0000:0000
    Bus 001 Device 017: ID 058f:6387 Alcor Micro Corp.
    Bus 001 Device 001: ID 0000:0000

    $ lsusb -t

    Bus# 5
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 4
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 3
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 2
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 1
    `-Dev# 1 Vendor 0x0000 Product 0x0000

    (3) /proc/bus/usb/devices

    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 17 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=058f ProdID=6387 Rev= 1.41
    S: Manufacturer=Generic
    S: Product=Mass Storage
    S: SerialNumber=D18BB30D
    C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
    I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    (4) módulos del kernel

    $ lsmod|egrep -i ‘(usb)’

    usb_storage 72256 1
    usbserial 32488 0
    libusual 17936 1 usb_storage
    scsi_mod 142348 6 usb_storage,sbp2,sg,sr_mod,sd_mod,libata
    usbcore 134280 7 usb_storage,usbserial,libusual,ov511,uhci_hcd,ehci_hcd

    Como se puede ver el sistema lo ha detectado como un sistema de almacenamiento USB, ha utilizado el driver usb_storage y lo ha puesto como dispositivo removible sdb y dispositivo genérico sg2. Se pueden ver esos dispositivos:


    $ ls -l /dev/sg2

    crw-rw---- 1 root root 21, 2 2007-12-29 15:44 /dev/sg2


    $ ls -l /dev/sdb

    brw-rw---- 1 root plugdev 8, 16 2007-12-29 15:44 /dev/sdb

    Y estos tres misteriosos:

    crw-rw—- 1 root root 254, 10 2007-12-29 17:17 usbdev1.19_ep00

    crw-rw—- 1 root root 254, 11 2007-12-29 17:17 usbdev1.19_ep01

    crw-rw—- 1 root root 254, 12 2007-12-29 17:17 usbdev1.19_ep82

    donde vemos que hay una diferencia entre los dos dispositivos, siendo el primero de tipo character y el segundo del tipo block. Por otra parte el grupo asignado a sdb, plugdev es un grupo al que pertenece el usuario del sistema. Los grupos a los que pertenece son:


    $ sudo cat /etc/group|egrep -i '(ubuntu)'

    adm:x:4:ubuntu
    dialout:x:20:cupsys,ubuntu
    cdrom:x:24:haldaemon,ubuntu
    floppy:x:25:haldaemon,ubuntu
    audio:x:29:ubuntu
    dip:x:30:ubuntu
    video:x:44:ubuntu
    plugdev:x:46:haldaemon,ubuntu
    scanner:x:104:cupsys,hplip,ubuntu
    netdev:x:112:ubuntu
    lpadmin:x:113:ubuntu
    powerdev:x:115:haldaemon,ubuntu
    admin:x:117:ubuntu
    ubuntu:x:500:

    El disco aparece montado en el sistema de archivos:


    $ df

    ...
    /dev/sdb 1007344 83280 924064 9% /media/disk

    La pregunta puede ser ahora, ¿qué regla de udev se ha activado para identificar el dispositivo? Uno de los que se ha ejecutado seguro es /etc/udev/rules.d/65-persistent-storage.rules, que es responsable de colocar el dispositivo en sdb y sg2.

    Al desconectar el dispositivo (previo desmontaje de la unidad) desaparecen el recurso sutilizado por el módulo del kernel usb_storage, y los dispositivos en /dev. Además se añade una escueta entrada en syslog:

    Dec 29 16:23:41 yerart kernel: [840277.168000] usb 1-1: USB disconnect, address 17

    El script de reglas que se ejecuta (deducido por inspección visual del contenido) es 95-hal.rules. El HAL (Hardware Abstraction Layer) es un demonio de Linux que se encarga del acceso a la información del hardware.

    Veamos ahora que pasa con la webcam:

    (1) syslog

    Dec 29 16:31:40 yerart kernel: [840756.436000] usb 2-1: new full speed USB device using uhci_hcd and address 29
    Dec 29 16:31:40 yerart kernel: [840756.604000] usb 2-1: configuration #1 chosen from 1 choice
    Dec 29 16:31:40 yerart kernel: [840756.604000] ubuntu/media/ov511/ov511.c: USB OV511+ video device found
    Dec 29 16:31:40 yerart kernel: [840756.608000] ubuntu/media/ov511/ov511.c: model: Creative Labs WebCam 3
    Dec 29 16:31:40 yerart kernel: [840756.900000] ubuntu/media/ov511/ov511.c: Sensor is an OV7620AE
    Dec 29 16:31:40 yerart kernel: [840756.900000] ubuntu/media/ov511/ov511.c: Enabling 511+/7620AE workaround
    Dec 29 16:31:41 yerart kernel: [840757.352000] ubuntu/media/ov511/ov511.c: Device at usb-0000:00:1d.0-1 registered to minor 0

    (2) usb

    $ lsusb

    Bus 005 Device 001: ID 0000:0000
    Bus 004 Device 001: ID 0000:0000
    Bus 003 Device 001: ID 0000:0000
    Bus 002 Device 029: ID 05a9:a511 OmniVision Technologies, Inc. OV511+ WebCam
    Bus 002 Device 001: ID 0000:0000
    Bus 001 Device 001: ID 0000:0000

    $ lsusb -t

    Bus# 5
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 4
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 3
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 2
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    `-Dev# 29 Vendor 0x05a9 Product 0xa511
    Bus# 1
    `-Dev# 1 Vendor 0x0000 Product 0x0000

    (3) /proc/bus/usb/devices

    T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 29 Spd=12 MxCh= 0
    D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
    P: Vendor=05a9 ProdID=a511 Rev= 1.00
    C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
    I: If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms
    I: If#= 0 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms
    I: If#= 0 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 129 Ivl=1ms
    I: If#= 0 Alt= 3 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 257 Ivl=1ms
    I: If#= 0 Alt= 4 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 385 Ivl=1ms
    I: If#= 0 Alt= 5 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 513 Ivl=1ms
    I: If#= 0 Alt= 6 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 769 Ivl=1ms
    I: If#= 0 Alt= 7 #EPs= 1 Cls=ff(vend.) Sub=00 Prot=00 Driver=ov511
    E: Ad=81(I) Atr=01(Isoc) MxPS= 961 Ivl=1ms

    (4) módulos del kernel

    $ lsmod|egrep -i ‘(ov)’

    ov511 79904 0
    videodev 28160 1 ov511
    usbcore 134280 7 usb_storage,usbserial,libusual,ov511,uhci_hcd,ehci_hcd

    Es curioso observar cómo a pesar de haber introducido el dispositivo en el mismo conector que en el caso del disco USB, el sistema lo ha detectado como un bus diferente. La segunda observación es que utiliza otro controlador de dispositivo distinto uhci_hcd, al contrario que el disco USB que utilizaba ehci_hcd.

    Hacemos una inspección al directorio /dev y encontramos dos dispositivos creados con toda probabilidad por udev como consecuencia de la conexión de la webcam:


    $ ls -l /dev/video0

    crw-rw---- 1 root video 81, 0 2007-12-29 16:31 /dev/video0


    $ ls -l /dev/usbdev2.29_ep00

    crw-rw---- 1 root root 254, 10 2007-12-29 16:31 /dev/usbdev2.29_ep00

    El grupo video tiene como componente al usuario ubuntu, indicando con ello que puede usar el dispositivo :) Aquí nos hacemos la misma pregunta sobre udev que en el caso anterior, ¿cuál es el archivo rules que se ha ejecutado? Ahora tenemos menos pistas. Solamente disponemos de los dispositivos creados. No lo encuentro … NECESITO MAS INFO :(

    Al desconectar la cámara, aparece el mensaje de syslog:

    Dec 29 17:09:43 yerart kernel: [843039.572000] usb 2-1: USB disconnect, address 29

    desaparecen los dispositivos creados en /dev y el módulo ov511 se queda sin recursos ocupados, pero no se descarga de memoria:


    $ lsmod|egrep -i '(ov)'

    ov511 79904 0
    videodev 28160 1 ov511
    usbcore 134280 7 usb_storage,usbserial,libusual,ov511,uhci_hcd,ehci_hcd

    Con el disco externo sucede lo mismo que con el disco llave USB:

    (1) syslog

    Dec 29 17:20:35 yerart kernel: [843691.588000] usb 1-1: new high speed USB device using ehci_hcd and address 20
    Dec 29 17:20:35 yerart kernel: [843691.720000] usb 1-1: configuration #1 chosen from 1 choice
    Dec 29 17:20:35 yerart kernel: [843691.720000] scsi10 : SCSI emulation for USB Mass Storage devices
    Dec 29 17:20:40 yerart kernel: [843696.720000] scsi 10:0:0:0: Direct-Access SAMSUNG MP0402H UC10 PQ: 0 ANSI: 0
    Dec 29 17:20:40 yerart kernel: [843696.720000] SCSI device sdb: 78242976 512-byte hdwr sectors (40060 MB)
    Dec 29 17:20:40 yerart kernel: [843696.720000] sdb: Write Protect is off
    Dec 29 17:20:40 yerart kernel: [843696.724000] SCSI device sdb: 78242976 512-byte hdwr sectors (40060 MB)
    Dec 29 17:20:40 yerart kernel: [843696.724000] sdb: Write Protect is off
    Dec 29 17:20:41 yerart kernel: [843696.724000] sdb: sdb1
    Dec 29 17:20:41 yerart kernel: [843697.140000] sd 10:0:0:0: Attached scsi disk sdb
    Dec 29 17:20:41 yerart kernel: [843697.140000] sd 10:0:0:0: Attached scsi generic sg2 type 0

    (2) usb

    $ lsusb

    Bus 005 Device 001: ID 0000:0000
    Bus 004 Device 001: ID 0000:0000
    Bus 003 Device 001: ID 0000:0000
    Bus 002 Device 001: ID 0000:0000
    Bus 001 Device 020: ID 067b:2506 Prolific Technology, Inc.
    Bus 001 Device 001: ID 0000:0000

    $ lsusb -t

    Bus# 5
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 4
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 3
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 2
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    Bus# 1
    `-Dev# 1 Vendor 0x0000 Product 0x0000
    `-Dev# 20 Vendor 0x067b Product 0x2506

    (3) /proc/bus/usb/devices

    T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 20 Spd=480 MxCh= 0
    D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=067b ProdID=2506 Rev= 1.00
    S: Manufacturer=Prolific Technology Inc.
    S: Product=Mass Storage Device
    S: SerialNumber=000000000000
    C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA
    I: If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
    E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

    (4) módulos del kernel

    $ lsmod|egrep -i ‘(usb)’

    usb_storage 72256 0
    usbserial 32488 0
    libusual 17936 1 usb_storage
    scsi_mod 142348 6 usb_storage,sbp2,sg,sr_mod,sd_mod,libata
    usbcore 134280 7 usb_storage,usbserial,libusual,ov511,uhci_hcd,ehci_hcd

    Y además se crean los siguientes dispositivos:

    brw-rw—- 1 root plugdev 8, 16 2007-12-29 17:20 sdb
    brw-rw—- 1 root plugdev 8, 17 2007-12-29 17:20 sdb1
    crw-rw—- 1 root root 21, 2 2007-12-29 17:20 sg2

    crw-rw—- 1 root root 254, 10 2007-12-29 17:20 usbdev1.20_ep00
    crw-rw—- 1 root root 254, 11 2007-12-29 17:20 usbdev1.20_ep01
    crw-rw—- 1 root root 254, 12 2007-12-29 17:20 usbdev1.20_ep82

    Como dato curioso, este disco no se monta de forma automática. Es por eso que en los módulos de kernel cargados no aparece el recurso consumido. Si se monta el disco el usb_storage se pone a 1. Al quitarlo, como en todos los casos, aparece la correspondiente entrada en el syslog:

    Dec 29 17:28:54 yerart kernel: [844189.804000] usb 1-1: USB disconnect, address 20

    y desparacen todos los dispositivos en el /dev

    NOTA: Otro experimento interesante es qué pasa si conectamos todos los dispositivos a la vez :)

  4. Qué es lo que hice (III)

    Ahora vamos a realizar la prueba definitiva con el módem USB. Para ello en primer lugar vamos a leer la documentación que hemos recopilado.

    En este momento está claro que nos encontramos con un dispositivo múltiple USB que tiene un almacenamiento FLASH o de otro tipo con el contenido del driver, escritorio movistar y documentación, y un dispositivo módem HDSPA (3,5G) En microsoft Windows la primera vez que se conecta pasa a modo dispositivo de almacenamiento, que simula un CD autoarrancable (ZeroCD) e instala el driver y el escritorio movistar. En cuanto esto ocurre, el sistema operativo da la orden a través del driver al dispositivo para que pase de modo CD a modo módem. Las siguientes veces que se conecta recibe directamente la orden antes de que todo el proceso de modo CD se complete. La orden es un mensaje USB de bajo nivel (quizás en este punto sea conveniente leerse detenidamente la información disponible sobre la tecnología USB)

    Los programadores y colaboradores del proyecto usb_modeswitch conocen ese mensaje para el modelo ZTE MF620 (a nivel experimental, capturado con un sniffer USB de windows):


    ########################################################
    # ZTE MF620 (Experimental)
    #
    # Message string taken from a sniffer log. Untested!
    #
    # Contributor: Flávio Moringa

    ;DefaultVendor= 0x19d2
    ;DefaultProduct= 0x2000

    ;TargetVendor= 0x19d2
    ;TargetProduct= 0x0001

    ;MessageEndpoint=0x04
    ;MessageContent="5553424308a0b7870000000000000600000000000000000000000000000000"

    y han hecho un programa en C (que hace uso de la librería libusb, de la que hay que instalar la versión de desarrollo, libusb-dev, si se quiere compilar el programa) que permite mandar ese mensaje de forma automática si se le introduce en un fichero de configuración udev (rules), lo que permite ejecutarlo cuando se inserta el dispositivo y se le identifica con los IDs apropiados.

    He intentado con ayuda de ese programa hacer el paso de CD a módem, pero sin éxito. Al conectar el dispositivo se detecta el ZeroCD (comprobado haciendo el lsusb: Bus 002 Device 121: ID 19d2:2000 ), se carga el módulo usb_storage en el kernel y aparece como 1 un recurso utilizado. En ese momento ejecuto el programa con los siguientes parámetros:


    ubuntu@yerart:/home/gmg/temp/usb_modeswitch$ ./usb_modeswitch -v 0x19d2 -p 0x2000 -m 0x04 -V 0x19d2 -P 0x0001 -M 5553424308a0b7870000000000000600000000000000000000000000000000

    pero a pesar de encontrar el dispositivo, no logra contactar con él:

    * usb_modeswitch: tool for controlling “flip flop” mode USB devices
    * Version 0.9.2 (C) Josua Dietze 2007
    * Works with libusb 0.1.12 and probably other versions

    Looking for target device
    OK, target device not found. Action required
    Looking for default device
    Ok, found default device. Prepare switching
    Looking for active default driver to detach it
    No driver found. Device probably not initialized. Trying to continue …
    Error: could not claim interface (error -1). Can’t communicate. Aborting

    Yo creo que esto es debido a que el CD no es configurado de forma apropiada y por lo tanto no logra pillar el dispositivo.

    También he intentado hacerlo siguiendo la receta del udev y colocando como comando de ejecución el modeswitch pero parece que el archivo de rules del udev ni se ejecuta.

    Como conclusión considero esta experiencia con Ubuntu y ZTE un fracaso.

  5. Qué es lo que hice (IV)

    Finalmente me he decidido a seguir la conexión portuguesa. Para descubrir que la manera que tienen de detectarlo es la misma que he intentado yo más arriba, si bien ellos lo hacen de una forma más ordenada y hasta al final. Siendo así me decido a seguir su receta:

    (1) Me bajo e instalo correctamente el usb_modeswitch

    El lo compila pero yo utilizo el binario que viene ya compilado en la distribución de código fuente. Instalo el binario en /usr/sbin. También cojo la parte del fichero de configuración, usb_modeswitch.conf, relativa al módem ZTE MF620 y la pongo en /etc.

    (2) Instalo los programas adicionales necesarios

    Los programas añadidos que hay que instalar son wvdial y gcom (Option GlobeTrotter GPRS/EDGE/3G/HSDPA and Vodafone 3G/GPRS datacard control tool), cosa que hago con apt-get (el primero ya estaba instalado)

    (3) Creo el fichero de reglas udev

    /etc/udev/rules.d/15-zte-mf620.rules

    ACTION!=”add”, GOTO=”ZTE_End”

    # Is this the ZeroCD device?
    SUBSYSTEM==”usb”, SYSFS{idProduct}==”2000″,
    SYSFS{idVendor}==”19d2″, GOTO=”ZTE_ZeroCD”

    # Is this the actual modem?
    SUBSYSTEM==”usb”, SYSFS{idProduct}==”0001″,
    SYSFS{idVendor}==”19d2″, GOTO=”ZTE_Modem”

    LABEL=”ZTE_ZeroCD”
    # This is the ZeroCD part of the card, remove
    # the usb_storage kernel module so
    # it does not get treated like a storage device
    #RUN+=”/sbin/rmmod usb_storage”
    RUN+=”/usr/sbin/usb_modeswitch -d 1 -v 0x19d2 -p 0x2000 -V 0x19d2 -P 0x0001″

    LABEL=”ZTE_Modem”
    # This is the Modem part of the card, let’s
    # load usbserial with the correct vendor
    # and product ID’s so we get our usb serial devices
    RUN+=”/sbin/modprobe usbserial vendor=0x19d2 product=0x0001″,
    # Make users belonging to the dialout group
    # able to use the usb serial devices.
    MODE=”660″, GROUP=”dialout”

    LABEL=”ZTE_End”

    (4) En este momento hago un inciso para hacer la prueba de conectar el módem. Esta vez la cosa es distinta que experiencias anteriores :) Siguiendo lo que pasa en el syslog:

    * primero se detecta el dispositivo de almacenamiento USB e inmediatamente entran en funcionamiento las reglas (rules) de udev, pasándose el módem a su estado natural y creándose los dispositivos necesarios:

    Dec 30 14:26:00 yerart kernel: [919610.912000] usb 2-1: new full speed USB device using uhci_hcd and address 15
    Dec 30 14:26:00 yerart kernel: [919611.068000] usb 2-1: configuration #1 chosen from 1 choice
    Dec 30 14:26:00 yerart kernel: [919611.088000] Initializing USB Mass Storage driver…
    Dec 30 14:26:00 yerart kernel: [919611.088000] scsi22 : SCSI emulation for USB Mass Storage devices
    Dec 30 14:26:00 yerart kernel: [919611.088000] usbcore: registered new interface driver usb-storage
    Dec 30 14:26:00 yerart kernel: [919611.088000] USB Mass Storage support registered.
    Dec 30 14:26:00 yerart kernel: [919611.204000] usbcore: registered new interface driver usbserial
    Dec 30 14:26:00 yerart kernel: [919611.204000] drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
    Dec 30 14:26:00 yerart kernel: [919611.204000] usbcore: registered new interface driver usbserial_generic
    Dec 30 14:26:00 yerart kernel: [919611.204000] drivers/usb/serial/usb-serial.c: USB Serial Driver core
    Dec 30 14:26:29 yerart kernel: [919640.400000] usb 2-1: USB disconnect, address 15
    Dec 30 14:26:33 yerart kernel: [919644.428000] usb 2-1: new full speed USB device using uhci_hcd and address 16
    Dec 30 14:26:33 yerart kernel: [919644.592000] usb 2-1: configuration #1 chosen from 1 choice
    Dec 30 14:26:33 yerart kernel: [919644.592000] usbserial_generic 2-1:1.0: generic converter detected
    Dec 30 14:26:33 yerart kernel: [919644.592000] usb 2-1: generic converter now attached to ttyUSB0
    Dec 30 14:26:33 yerart kernel: [919644.596000] usbserial_generic 2-1:1.1: generic converter detected
    Dec 30 14:26:33 yerart kernel: [919644.596000] usb 2-1: generic converter now attached to ttyUSB1
    Dec 30 14:26:33 yerart kernel: [919644.600000] usbserial_generic 2-1:1.2: generic converter detected
    Dec 30 14:26:33 yerart kernel: [919644.600000] usb 2-1: generic converter now attached to ttyUSB2
    Dec 30 14:26:33 yerart kernel: [919644.600000] usbserial_generic 2-1:1.3: generic converter detected
    Dec 30 14:26:33 yerart kernel: [919644.600000] usb 2-1: generic converter now attached to ttyUSB3

    Durante diez segundos se comprueban los dispositivos USB detectados y se observa el cambio de Bus 002 Device 015: ID 19d2:2000 a Bus 002 Device 016: ID 19d2:0001. También se ven los nuevos dispositivos creados:

    crw-rw—- 1 root dialout 188, 0 2007-12-30 14:26 ttyUSB0
    crw-rw—- 1 root dialout 188, 1 2007-12-30 14:26 ttyUSB1
    crw-rw—- 1 root dialout 188, 2 2007-12-30 14:26 ttyUSB2
    crw-rw—- 1 root dialout 188, 3 2007-12-30 14:26 ttyUSB3
    crw-rw—- 1 root dialout 254, 10 2007-12-30 14:26 usbdev2.16_ep00
    crw-rw—- 1 root dialout 254, 13 2007-12-30 14:26 usbdev2.16_ep02
    crw-rw—- 1 root dialout 254, 19 2007-12-30 14:26 usbdev2.16_ep03
    crw-rw—- 1 root dialout 254, 15 2007-12-30 14:26 usbdev2.16_ep04
    crw-rw—- 1 root dialout 254, 17 2007-12-30 14:26 usbdev2.16_ep05
    crw-rw—- 1 root dialout 254, 11 2007-12-30 14:26 usbdev2.16_ep81
    crw-rw—- 1 root dialout 254, 12 2007-12-30 14:26 usbdev2.16_ep82
    crw-rw—- 1 root dialout 254, 18 2007-12-30 14:26 usbdev2.16_ep83
    crw-rw—- 1 root dialout 254, 14 2007-12-30 14:26 usbdev2.16_ep84
    crw-rw—- 1 root dialout 254, 16 2007-12-30 14:26 usbdev2.16_ep85

    Los módulos cargados en el kernel son los siguientes (previamente al experimento se habían desregistrado los módulos usb_storage y usbserial, de experimentos anteriores, con un rmmod)

    ~# lsmod |egrep -i ‘(usb)’
    usbserial 32488 0
    usb_storage 72256 0
    libusual 17936 1 usb_storage
    scsi_mod 142348 6 usb_storage,sbp2,sg,sr_mod,sd_mod,libata
    usbcore 134280 7 usbserial,usb_storage,libusual,ov511,uhci_hcd,ehci_hcd

    Finalmente la información del bus en proc confirma que el módem está en marcha:

    T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=12 MxCh= 0
    D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
    P: Vendor=19d2 ProdID=0001 Rev= 0.00
    S: Manufacturer=Qualcomm, Incorporated
    S: Product=ZTE CDMA Technologies MSM
    C:* #Ifs= 4 Cfg#= 1 Atr=a0 MxPwr=500mA
    I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
    E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=128ms
    E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
    E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=04(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
    E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=05(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    I: If#= 3 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=usbserial_generic
    E: Ad=83(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms
    E: Ad=03(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms

    Para completar la prueba, ejecutamos un comando que viene en el blog de correcaminos que puede darmos una salida muy interesante:


    gcom -d /dev/ttyUSB0 /usr/share/doc/gcom/examples/operator

    Que nos saca:

    ~# gcom -d /dev/ttyUSB0 /usr/share/doc/gcom/examples/operator
    SIM ready
    Waiting for Registration..(120 sec max)
    Registered on Home network: “movistar”,2
    Signal Quality: 8,99
    Getting Operator list: .

    +ZUSIMR:2

    ==============================================================
    Format: (Access,Long Name, Short Name, Network ID [,Technology])
    Access: 2 – Registered, 1 – Available, 3 – Forbidden
    Technology: 0 – GSM/GPRS, 2 – UMTS (Not available on all cards)

    Enter the Network ID to attempt manual registration
    [blank = automatic selection]:
    Registration request accepted
    Command was: AT+COPS=0

    Lo cual indica que todo ha salido perfecto.

    (5) configurar wvdial para la conexión

    editar /etc/wvdial.conf

    (hechar un vistazo a cómo se hace en el blog de correcaminos)

    [Dialer Defaults]
    Phone = *99***1#
    Username = movistar
    Password = movistar
    Stupid Mode = 1
    Dial Command = ATDT
    New PPPD = yes

    [Dialer hsdpa]
    Modem = /dev/ttyUSB0
    Baud = 460800
    Init2 = ATZ
    Init3 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    ISDN = 0
    Modem Type = Analog Modem

    [Dialer 2gonly]
    Init4 = AT+COPS=0,0,”movistar.es”,0

    [Dialer 3gonly]
    Init4 = AT+COPS=0,0,”movistar.es”,2

    [Dialer movistar]
    Init5 = AT+CGDCONT=1,”IP”,”movistar.es”;

    [Dialer 384k]
    Init6 = AT+CGEQMIN=1,4,64,384,64,384
    Init7 = AT+CGEQREQ=1,4,64,384,64,384

    [Dialer 144k]
    Init6 = AT+CGEQMIN=1,4,64,144,64,144
    Init7 = AT+CGEQREQ=1,4,64,144,64,144

    [Dialer 64k]
    Init6 = AT+CGEQMIN=1,4,64,64,64,64
    Init7 = AT+CGEQREQ=1,4,64,64,64,64

    Modifica igualmente la configuración del wvdial para ppp (/etc/ppp/peers/wvdial) con esta información:

    plugin passwordfd.so
    noauth
    name wvdial
    replacedefaultroute
    noipdefault
    nomagic
    usepeerdns
    ipcp-accept-local
    ipcp-accept-remote
    nomp
    noccp
    nopredictor1
    novj
    novjccomp
    nobsdcomp

    Una vez hecho esto, en teoría para establecer la conexión hay que realizar la siguiente secuencia de comandos:


    # /sbin/usb_modeswitch -d 1 -v 0x19d2 -p 0x2000 -V 0x19d2 -P 0x0001
    # /usr/bin/gcom -d /dev/ttyUSB0
    # /usr/bin/wvdial hsdpa movistar

    Hacemos la prueba y obtenemos:

    :~# wvdial hsdpa movistar
    –> WvDial: Internet dialer version 1.56
    –> Cannot get information for serial port.
    –> Initializing modem.
    –> Sending: ATZ
    ATZ
    OK
    –> Sending: ATZ
    ATZ
    OK
    –> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
    OK
    –> Sending: AT+CGDCONT=1,”IP”,”movistar.es”;
    AT+CGDCONT=1,”IP”,”movistar.es”;
    OK
    –> Modem initialized.
    –> Sending: ATDT*99***1#
    –> Waiting for carrier.
    ATDT*99***1#
    CONNECT
    –> Carrier detected. Starting PPP immediately.
    –> Starting pppd at Sun Dec 30 23:59:42 2007
    –> Pid of pppd: 32132
    –> Using interface ppp0
    –> local IP address 88.31.2.66
    –> remote IP address 10.64.64.64
    –> primary DNS address 194.179.1.100
    –> secondary DNS address 194.179.1.101

    con:

    $ /sbin/ifconfig

    ppp0 Link encap:Point-to-Point Protocol
    inet addr:88.31.2.66 P-t-P:10.64.64.64 Mask:255.255.255.255
    UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
    RX packets:314 errors:53 dropped:0 overruns:0 frame:0
    TX packets:268 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:3
    RX bytes:39414 (38.4 KiB) TX bytes:31153 (30.4 KiB)

    Un éxito. :)

    Para pararlo hay que dar un Ctrl-C (esto habría lógicamente que automatizarlo de alguna manera), apareciendo lo siguiente en la consola:

    Caught signal 2: Attempting to exit gracefully…
    –> Terminating on signal 15
    –> Connect time 20.8 minutes.
    –> Disconnecting at Mon Dec 31 00:20:32 2007

    El último consumo realizado antes de desconectar (tras realizar apenas un par de navegaciones y ver un vídeo de youtube) ha sido: RX bytes:8649158 (8.2 MiB) TX bytes:1005223 (981.6 KiB).

    En el syslog también se ha podido seguir la aventura:

    Dec 30 23:59:42 yerart pppd[32132]: Plugin passwordfd.so loaded.
    Dec 30 23:59:42 yerart kernel: [954031.228000] PPP generic driver version 2.4.2
    Dec 30 23:59:42 yerart pppd[32132]: pppd 2.4.4 started by root, uid 0
    Dec 30 23:59:42 yerart pppd[32132]: Using interface ppp0
    Dec 30 23:59:42 yerart pppd[32132]: Connect: ppp0 /dev/ttyUSB0
    Dec 30 23:59:42 yerart pppd[32132]: No CHAP secret found for authenticating us to UMTS_CHAP_SRVR
    Dec 30 23:59:42 yerart pppd[32132]: CHAP authentication succeeded
    Dec 30 23:59:42 yerart pppd[32132]: CHAP authentication succeeded
    Dec 30 23:59:46 yerart pppd[32132]: Could not determine remote IP address: defaulting to 10.64.64.64
    Dec 30 23:59:46 yerart pppd[32132]: local IP address 88.31.2.66
    Dec 30 23:59:46 yerart pppd[32132]: remote IP address 10.64.64.64
    Dec 30 23:59:46 yerart pppd[32132]: primary DNS address 194.179.1.100
    Dec 30 23:59:46 yerart pppd[32132]: secondary DNS address 194.179.1.101

    Dec 31 00:20:32 yerart pppd[32132]: Terminating on signal 15
    Dec 31 00:20:32 yerart pppd[32132]: Connect time 20.8 minutes.
    Dec 31 00:20:32 yerart pppd[32132]: Sent 1068561 bytes, received 8730075 bytes.
    Dec 31 00:20:32 yerart pppd[32132]: Connection terminated.
    Dec 31 00:20:32 yerart pppd[32132]: Exit.

    NOTA: El autor del blog portugués indica que a veces no se reconoce el módem cuando se conecta al portátil y que eso pasa tanto en windows como en Linux. La solución que propone, curiosamente ya la he aplicado :) Consiste en quitar la batería y volverla a poner. Yo he hecho estos experimentos sin la batería puesta ;)

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s