El día de mi suelta

El día de la suelta para un alumno piloto es un gran día, es el momento en el cual sus instructores estiman (ilusos ellos) que el alumno tiene las habilidades mínimas necesarias como para no matarse viajando solo en un avión.

Es un día especial donde la emoción y el susto se combinan para que tengas una sensación que nadie ha podido definir aún.

Este es el relato de mi día de la suelta.

Me había programado para volar el sábado temprano (9:00 a.m) porque en verano me gusta volar a primera hora de la mañana, así me evito turbulencias producidas por térmicas y el avión tiene mejor performance (aire más frío).

Volar a primera hora también tiene sus contras, tienes que pararte más temprano, tienes que ir con prisas para llegar a la oficina ARO de Cuatro Vientos (abren a las 8:30) y tienes que ser Usain Bolt para llegar rápido a la plataforma de la escuela que queda "llegando a Coslada" para ver si no te agarra el "atasco" en el punto de espera que parece la A6 en hora pico.

Para palear un poco estos contras, lo que hago es meter el plan de vuelo el día anterior por la tarde, así llego directo al control de seguridad el día del vuelo y me ahorro un poquito de tiempo (solo un poquito).

Pues bien, el viernes en la tarde veo la página de programación de la escuela que, aunque la información que sale ahí no es oficial sino hasta las 8 de la noche, a las 3 de la tarde es muy probable que esa información ya sea la definitiva (iluso pequeño saltamontes).

A eso de las 4 de la tarde y por "no dejar", reviso de nuevo la página de programación de la escuela y .... oh sorpresa, me habían cambiado al instructor y ahora decía "check". Por supuesto, puse cara de "ponchao", eso de check no lo había visto nunca y pensé que debían ser las nuevas políticas de la escuela que ahora te hacen chequeos teóricos frecuentemente.

No me parece mal, así te obligan a repasar la teoría siempre.

Pues bien, con eso en mente salgo de la oficina hacia Cuatro Vientos (LECU de ahora en adelante) a meter mi plan de vuelo para el sábado un poco preocupado porque, para que coloquen en la programación que me van a hacer un "check", pues debe ser importante, así que ya me veía yo llegando a la casa a estudiar y perderme las finales del viernes del mundial de natación Barcelona 2013.

Llego a LECU, estaciono delante de la terminal y vuelvo a intentar verificar  la programación de la escuela, no fuese a ser que cambiara de nuevo. En eso recibo una llamada, es este nuevo instructor que me han colocado diciéndome que me va a hacer un chequeo y que me prepare un routing El Alamo, Illescas, me parece raro, muy corto. Le pido que me confirme que es El Alamo, Illescas y nos devolvemos a Cuatro Vientos y me dice que si y que ponga la EOBT a las 9:15 locales y que me esperará en operaciones a las 8:30.

Sin problemas, me voy a la oficina ARO, meto mi plan de vuelo, consulto NOTAMS para el sábado y listo, sale mi plan de vuelo aprobado por la impresora y me voy para mi casa.

El camino de vuelta fue una elucubración constante, el routing era muy corto, seguro que era para evaluarme el timing en los puntos de referencia... uffff me toca afinar bastante en el cálculo de tiempos, y siendo tan corto, seguro me iba a freir con teoría....

Pienso también que.... y si es la suelta? OMG!!!!! .... no, no creo, estoy muy "pichón" pero igualito "huele mal".

Llego a las casa con "cara de circunstancias", mi esposa me pregunta que qué me pasa y le cuento lo del "check". Ella me dice que no me preocupe, que me lo tome con calma, que siempre me tomo las cosas muy a pecho. Tiene razón pero cuando llevas eso en el "firmware" poco se puede hacer....

Total que me pongo manos a la obra, saco mis "macundales" y me pongo a hacer el routing. Es tan pero tan corto que solo alcanzo a colocar un punto intermedio en cada tramo para llevar el timing... pienso que aquí está la "trampa", ve van a joder con eso.

Termino de hacer mis garabatos sobre la carta 1:500000, agarro el manual del avión y comienzo a leerme los fallos de motor, los fuegos, velocidades características, etc, etc.

Mi esposa, al verme así, me dice que me va a hacer la cena, que no me preocupe y siga estudiando :)

Termina la natación (damn it!!!! no vi casi nada), termino de cenar y agarro el "análisis de maniobras" que seguro me pone a hacer mil pérdidas y tres mil fallos de motor... "mínime!!!!!!"

Ya preocupado por la hora, me voy a dormir temprano para estar "despierto" al día siguiente.

Suena el despertador y partida!!!!!!! a bañarme, desayunar, sacar la meteo y los NOTAM's y "ráspalo" pa' LECU.

Llego a la terminal (casi vacía), paso el control de seguridad y "rumbo a Coslada".

Cuando llego a la plataforma de la escuela, veo al avión que me toca con las puertas abiertas, full flaps.... que raro.... será que me equivoqué de avión?? Bien bueno pues.....

Entro a la oficina y está extrañamente "llena", dos instructores, tres alumnos (WTF??!!). En fin, se presenta mi instructor (primera vez que lo veo), confirma mi nombre y me dice, "siéntate ahí"... listo, comienza "el parto".

Me pide certificado médico, tarjeta de alumno, plan de vuelo, meteo, plan de vuelo operacional, ruting, NOTAM's, nombre y pedigree de la mascota de mi hermana... (ok, se me fue la mano ;) ).

Me bombardea de preguntas e intento responderlas lo mejor que puedo y cuando terminamos me dice: vamos a avolar..... ajá!!!! aquí está la trampa!!!!! no he hecho la carga y centrado ni la exterior!!! pues nada, se lo digo al instructor y me dice que la exterior la hizo el y la hoja de carga y centrado también.

Lo miro con desconfianza y le insisto, "pero seguro"? y me responde el con mirada de "ya estamos con el mequetrefe este", si, ya lo hice yo, vámonos ya.

Ok, con esa capacidad de convencimiento, nos dirigimos al avión, doy una "ojeada rápida" por si las moscas y comenzamos con la checklist.

Todo perfecto, me dispongo a rodar y el instructorme dice "mío el avión", perfecto, agarra el avión como si fuese una bicicleta, lo saca de plataforma y me lo da. Me dice que me apure para que no nos agarre "el atasco". Bien, pruebo mis frenos y listo, el primer regaño, "no frenes así, no estás probado el ABS", ok, lo tendré en cuenta (uffff bonito comienzo)..

Seguimos hasta el punto de espera de la 28 y el instructor se pone a hablarme del anti skid..... fine.... a ver si se me olvidan los chequeos de brújula , direccional, bastón y bola.... le interrumpo diciéndole que voy a hacer las pruebas y me dice que ok...

Ya en el punto de espera con briefing's y prueba de motor lista, nos autorizan a despegar por la 28, viento en calma (muy bien!!!!).

Estando en viento en cara me dice el instructor que vamos a hacer 2 tomas y despegues, que hable con la torre en viendo en cola.... ok, perfecto, la torre nos autoriza y uffff, a ver como me sale esta toma, las últimas con full flaps me han salido un poco flojas, en cambio, con dos puntos de flaps, esas si me salen chéveres.

Pues bien, ya con toma asegurada y en la cabecera de la 28 con las que te conté de corbata, intento hacer una toma "buena".... uffff un poco dura... ya estamos.... sin embargo el instructor me dice que la toma bien, pero que tengo que rotar a 55 KIAS y no a 60 como siempre he practicado, pero bueno, que lo tenga en cuenta.

Seguimos con la segunda toma y la torre me dice que alargue el viento en cola y autoriza a un tráfico, que estaba en el punto de espera, a despegar.

El tráfico se demora un poco y el instructor me dice: "ves? cuando digas listo salida es listo salida porque haces esperar a los demás tráficos".

Entendido... ya me estaba poniendo nervioso porque ese viento en cola estaba llegando a Vallecas ( no es cierto ;) ) cuando veo que el tráfico despega. Viro a base y la torre nos autoriza a aterrizar.

Como el final fue "largo", me dió tiempo a colocarme bien y a "pensar mucho" en esa toma.... no meter flap's tan pronto que quedaba bastante tiempo, calma...

Ya con toma asegururada y full flap's presento el avión, comienzo la recogida tratando de que esta toma si fuese "buena".... suena la bocina de pérdida y pack, toma suave... coño!!! seguro tomé con 2 puntos de flaps... Verifico los flap's y no, están en full.... pues nada, limpiar el avión, full gases y nos vamos!!!.

Al menos esta toma si había salido como a mi me gusta.

Total que nos dirigimos a W, le comento como voy a hacer el routing, preparo frecuencias, carta, etc, notificamos en W, ponemos rumbo al Alamo y "saludamos" en aire-aire.

El instructor sigue hablándome no se si para distraerme o porque el es así, al menos el vuelo sería "entretenido".

Ya rumbo a Illescas comenzaron las "gracias", fallos de motor, preguntas trampa a ver si sabía en donde estaba pero lo más importante, consejos de "aviación práctica", no la que sale en los libros, la que me va a salvar la vida, cosa que se agradece mucho.

Así transcurrió el vuelo, más fallos de motor, más consejos prácticos, más fallos de alternador, batería, etc etc etc (creo que falló todo lo que tenía que fallar!!!!!).

Ya entrando en al circuito de LECU, escucho en frecuecia la frase "toma intermedia para suelta de alumno"..... de otros tráficos :( dos que recuerde.

Viendo que me quedaba mucho tiempo, le pregunté si esta era toma final o podíamos hacer más tomas y despegues, el me dice que llevará las comunicaciones y que yo me centre en el avión, pues bien, cada vez que el hablaba con la torre yo no escuchaba nada (medio fallo de radio!!!! lo que faltaba!!!!). Le dije que no lo escuchaba cuando hablaba con la torre y el me contestó de lo más tranquilo: "si, yo tampoco te escucho a ti cuando notificas, tengo que verte para saber que estás diciendo (WTF!!!!!!!!!???????????)

Seguimos en aproximación, tomo y le pregunto de nuevo "qué hacemos? plataforma?". No me contesta, liberamos pista, torre nos pasa con rodadura, el instructor sigue hablando con la controladora y yo nada que escucho, (fuck!!!!). Le insisto de nuevo " ya?, no vamos a hacer tomas y despegues?" y el me responde con : "quieres volar solo"? (WHAT!!!!!!!!) - eehhhmmmm mmmmm si... pero..... - y me sigue diciendo: "bueno, ahora llegamos a plataforma y te vas tu solo.... (OMFG!!!!!!!!!!!!!!!!!).

Seguimos a plataforma y antes de llegar a los caribou's me dice, mío el avión, hace un 360 y me dice, "lo agarras desde aquí, aprovecha el día que está muy bueno y no vengas antes de una hora" (GOOOOOOOOOOOOD!!!!!)

Por supuesto, no tenía routing de nada aparte del que había preparado así que le digo, bueno, a ver dónde me voy ahora, el me sugiere Toledo y me parece bien.

Me gusta mucho Toledo y ya la había sobrevolado una vez y es espectacular, así que con autorización, hasta punto de espera de la 28 y a Toledo....

Creo que todavía no me daba cuenta de que era mi suelta, estaba pendiente de checklist's, la ruta que iba a seguir, altitud, tráficos, etc... ya en W y en frecuencia aire-aire notifico que voy al Bosque de Batres, 3000 ft, al ratico notifican 2 tráficos que están cerca del bosque de Batres y que van a S.

Desde operaciones de la escuela "advierten" que estoy en mi suelta y que si pueden, amablemente, subirse 500 ft =) Los tráficos aceptaron sin problemas (desde aquí mil gracias por facilitarme las cosas), sin embargo, ya los tenía a la vista así que los podía evadir.

Ya con el Bosque de Batres a mi izquierda, notifico que voy rumbo sur a Recas, 3000 ft. Que sorpresa, otro tráfico estaba sobre Recas a 3000 ft y rumbo a Toledo, bien bueno pues, hoy es el día de ir a Toledo me dije :)

Decido entonces notificar cuado llegue a Lomichar, así saben que el rookie de la suelta anda por ahí. Escucho a otro tráfico sobre Chozas de Canales y creo recordar que iba hacia Casarrubios, perfecto, más gente para la fiesta.

Abro los ojos lo más que puedo y comienzo a hacer el scan del cielo a ver si aparece "algo"... nada.... ya sobre Lomichar vuelvo a notificar y escucho a mi precedente sobre Olias del Rey... bien, vamos en caravana...

Como ven, de disfrutar poco, siempre pendiente de los tráficos, la altitud, el mapa, los pueblos.... ufffff.

Por fin en Recas, notifico y mi precedente dice que está en Toledo y que se sube a 4500 ft, bien, parece que podré orbitar sobre Toledo sin problemas...

La cosa se relaja un poco sobre Olías del Rey, ya tenía a Toledo en el morro y nadie se había reportado por la zona, hora de descansar orbitando sobre el oeste de Toledo..... el casco histórico es impresionante desde 3000 ft... esta es parte de la recompensa después de haber sufrido a Adsuar.

No se cuantas vueltas di al oeste de Toledo, creo que no me canso de verla :), para asegurarme el disfrute reporté que iba a estar orbitando sobre Toledo, así sabrían que había alguien por ahí.

Miré la hora y decidí regresarme, justo en ese momento se reporta un tráfico que venía de Recas a Toledo, no se si se había reportado antes, yo estaba muy "ocupado" :)

Notifiqué que abanonaba Toledo rumbo Olías del Rey y me aparté un poco a la derecha por si las moscas.

El tramo de vuelta fue tranquilo, la frecuencia estaba callada y fue ahí donde me di cuenta que estaba volando yo solo y que era el día de mi suelta.

Receptor ADS-B con linux

En este post voy a colocar los pasos que seguí para construir un receptor ADS-B con linux.

Primero, algo de teoría, aunque si estás leyendo este post, probablemente ya sepas que es ADS-B, sin embargo, algo de teoría no cae mal.

Según skybrary, ADS-B son unas siglas que significan Automatic Dependent Surveillance Broadcast. Es un sistema mediante el cual los aviones o cualquier vehículo aeroportuario emiten información generada en sus sistemas de abordo mediante radiodifución (Skybrary, ADS-B).

Existen en el mercado varios receptores para estas emisiones, por ejemplo, el SBS-3 de Kinetic Avionics que cuesta alrededor de £ 500.

En el sitio Flightradar24 se puede apreciar un ejemplo de la data que pueden recopilar estos receptores y de lo que se puede hacer con ella.

Como £ 500 es realmente mucho y existen opciones más baratas disponibles, voy a hablar de una opción que cae en el grupo de las baratas (aproximadamente 8 € !!!!!!!!!).

Hardware

El aparatico que hace la magia es un receptor de radio y televisión digital USB. Según he leido, este es un dispositivo que entra en la categoría de SDR (Radio de software) y lo interesante es que se puede sintonizar a la frecuencia de 1090 MHz que es la frecuencia en la cual se transmite  la información ADS-B.

Uno de los modelos más populares de este "dongle" son los que están basados en los chips RTL2832U+R820T.

Yo compré uno por ebay y me costó 8€ con envío. Este es el link del producto
FM+DAB USB DVB-T RTL2832U+R820T w/ MCX antenna y esta es la foto del producto en su caja, como me llegó:

Este "dongle" viene con una antena que hace un trabajo bastante bueno y que sirve para iniciarse en el mundo del radiospotting.

Esta es la salida de lsusb montrando al "dongle"

Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T

Y esta es lo que muestra el syslog cuando el "dongle" se conecta al puerto USB

kernel: [  167.908218] usb 1-8: new high-speed USB device number 3 using ehci_hcd
kernel: [  168.052057] usb 1-8: New USB device found, idVendor=0bda, idProduct=2838
kernel: [  168.052067] usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
kernel: [  168.052075] usb 1-8: Product: RTL2838UHIDIR
kernel: [  168.052081] usb 1-8: Manufacturer: Realtek
kernel: [  168.052087] usb 1-8: SerialNumber: 00000001

Aparte del "dongle", se necesita una computadora con un puerto USB 2.0.

Software

Sistema operativo: En mi caso utilicé Debian Wheezy.

SDR: Para la sintonización utilicé las utilidades rtl-sdr.

Decodificador ADS-B (Opcional pero muy recomendado): Como decodificador adicional de ADS-B utilicé dump1090 que es una herramienta muy útil a la hora de visualizar los tráficos de una manera amigable.

Manos a la obra

Lo primero que hay que hacer es preparar el sistema operativo para compilar, ya que ninguno de estos programas (rtl-sdr y dump1090) están precompilados en los repositorios oficiales de debian.

# aptitude install build-essential git cmake libusb-1.0-0-dev

Ahora hay que bajarse el software para compilarlo.

rtl-sdr

# cd /usr/local/src
# git clone git://git.osmocom.org/rtl-sdr.git
# mkdir -p rtl-sdr/build
# cd rtl-sdr/build
# cmake  -DINSTALL_UDEV_RULES=ON ../
# make
# make install

Ya con esto deberíamos tener rtl-sdr instalado. Los binarios estarán en /usr/local/bin.

Ahora hay que probar que podemos trabajar con el "dongle", para esto, lo insertamos en un puerto USB y ejecutamos los siguiente (Ctrl+c para volver al prompt):

# rtl_test

Esta es la salida que obtengo yo:

Found 1 device(s):
  0:  ezcap USB 2.0 DVB-T/DAB/FM dongle

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Supported gain values (29): 0.0 0.9 1.4 2.7 3.7 7.7 8.7 12.5 14.4 15.7 16.6 19.7 20.7
22.9 25.4 28.0 29.7 32.8 33.8 36.4 37.2 38.6 40.2 42.1 43.4 43.9 44.5 48.0 49.6

Info: This tool will continuously read from the device, and report if
samples get lost. If you observe no further output, everything is fine.

Reading samples in async mode...
lost at least 68 bytes

No me preocupo por los bytes perdidos, lo que interesa es que el dispositivo está reconocido y más aún, que reconoció el radio Rafael Micro R820T.

Ahora hay que conectar la antena (si es que ya no está conectada) y probar si recibimos data ADS-B.

Si es posible colocar la antena cerca de la ventana y tener visión del cielo sin obstáculos, mejor.

En mi caso, como las pruebas las estoy haciendo en una laptop, me es fácil ubicarme cerca de una ventana.

Ejecutamos lo siguiente (Crtl+c para volver al prompt):

# rtl_adsb -V

Y deberíamos tener una salida como esta

Found 1 device(s):
  0:  Realtek, RTL2838UHIDIR, SN: 00000001

Using device 0: ezcap USB 2.0 DVB-T/DAB/FM dongle
Found Rafael Micro R820T tuner
Tuner gain set to automatic.
Tuned to 1090000000 Hz.
Sampling at 2000000 Hz.
Exact sample rate is: 2000000.052982 Hz
*8d405f1391404839a80495d13bdd;
DF=17 CA=5
ICAO Address=405f13
PI=0xd13bdd
Type Code=18 S.Type/Ant.=1
--------------
*8d505ec162b98399033c73ba8256;
DF=17 CA=5
ICAO Address=505ec1
PI=0xba8256
Type Code=12 S.Type/Ant.=2
--------------
*8d34150e9901650a80b296f522d3;
DF=17 CA=5
ICAO Address=34150e
PI=0xf522d3
Type Code=19 S.Type/Ant.=1
--------------
*8597c521e0e38161319e05f52f61;
DF=16 CA=5
ICAO Address=97c521
PI=0xf52f61
Type Code=28 S.Type/Ant.=0
--------------
*8e44ce719910e92280809106d31b;
DF=17 CA=6
ICAO Address=44ce71
PI=0x06d31b
Type Code=19 S.Type/Ant.=1
--------------

Señores, ahí están los tráficos!!!!!!!, el receptor funciona y tenemos información. Las líneas que salen como "ICAO Address" son la identificación de los tráficos que tienen transponders en Modo S. Más información Aquí.

Por supuesto, esta representación no nos dice mucho, lo que realmente queremos es ver los tráficos en un mapa y conocer su altitud, velocidad, heading, call sign, tipo de avión, etc, etc, etc, y para eso se necesita un visualizador.

Para linux he encontrado dos, el dump1090 que es decodificador y visualizador y el Virtual Radar Server que está escrito en C# (Mono) y aseguran que corre en linux. Yo solo lo he probado en windows y dada mi nula habilidad en ese sistema operativo, poco puedo aportar, salvo que me ha dado uns resultados bastante "aceptables" pero me sigo sintiendo "incómodo". Por esa razón, solo voy a hablar de dump1090 que si corre bien en linux y además de decodificador es visualizador.

dump1090

Dump1090 es muy versátil, permite decodificar la información ADS-B, mostrarla en modo texto de una manera amigable y además tiene un servidor web en el que se pueden ver los tráficos al estilo Flightradar24.

En mi caso, con la antena que viene el "dongle", dentro del apartamento (1° piso) y con una visión sin obstáculos de un sector "pequeño" del norte de Madrid, he podido seguir tráficos a altitudes de entre 5000 ft y FL380 (Madrid está a 2000 ft aproximadamente) y a una distancia de 110 NM.

Ye que le he hecho tanta propaganda a dump1090, hay que compilarlo:

# cd /usr/local/src
# git clone https://github.com/antirez/dump1090.git
# cd dump1090
# make

Esto genera el binario dump1090. Ahora solo resta copiar el binario y el archivo gmap.html a un directorio apropiado.

Entre las opciones que tiene dump1090 están, la visualización en modo texto (--interactive), la visualización por web y la posibilidad de compartir la data decodificada con otros visualizadores.

Para conocer todas las opciones de dump1090 hay que ejecutar:

# ./dump1090 -h

Dejo unas capturas de dump1090 en funcionamiento.

dump1090 en modo texto:

Visualización de la data en modo web proporcionada por dump1090:

Eso es todo, espero que sea de utilidad.

DNIe en Debian wheezy

Este es un post más sobre como usar el DNI electrónico en linux en una distribución diferente a las que tiene listadas la policía, en este caso es en Debian Wheezy de 32 bits.

Hardware

Una de las cosas importantes es contar con un lector de tarjetas inteligentes compatible con linux. Hay varios en el mercado, yo compré este:

Es un lector marca bit4id usb. Esto es lo que sale de un lsusb:

Bus 005 Device 003: ID 072f:90cc Advanced Card Systems, Ltd ACR38 SmartCard Reader

y esto es parte de lo que sale cuando conecto el lector en el puerto USB

usb 5-1: new full-speed USB device number 3 using uhci_hcd
usb 5-1: New USB device found, idVendor=072f, idProduct=90cc
usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 5-1: Product: CCID USB Reader
usb 5-1: Manufacturer: ACS

Esta compañía tiene un sitio web donde tienen algo de información para linux

http://www.bit4id.com/es/soporte/instalacion.php

Nota: Cuando hice la prueba de insertar el DNI, el led no permaneció encendido 15 segundos, pero si 5.

Instalación de software

Esta es la parte "complicada" porque no hay paquetes de opensc para wheezy ni en la página de la policía ni en los repositorios oficiales de Debian que sea capaces de leer el DNIe.

La gente de opendnie tiene un .deb de opensc que es una modificación del "oficial" de Debian y es esta modificación la que hace que opensc funcione con el DNI electrónico. Todo esto al momento de escribir este post (24 de Febrero de 2013)

A continuación coloco los pasos que seguí para el DNIe funcionara en wheezy:

1. Verificar que se tienen estos paquetes instalados:
   

   libltdl7
   libssl1.0.0
   zlib1g



2. Descargar e instalar opensc_0.12.1-1-svn385_i386.deb
   

   # cd /usr/local/src
   
   # wget https://forja.cenatic.es/frs/download.php/file/1305/opensc_0.12.1-1-svn385_i386.deb
   
   # dpkg -i opensc_0.12.1-1-svn385_i386.deb
   



3. Instalar los paquetes  pcscd y pcsc-tools
   

   # aptitude install  pcscd pcsc-tools



4. Como instalamos un opensc que no es el oficial, debemos evitar que se actualice cuando hagamos un aptitude upgrade.
   

   # aptitude hold opensc



5. Creamos un enlace simbólico para  libpcsclite.so.1
   

   # cd /usr/lib
   
   # ln -s /usr/lib/i386-linux-gnu/libpcsclite.so.1



6. Instalar los siguientes paquetes para tener algunas utilidades importantes para trabajar con cualquier tarjeta inteligente
   

   aptitude install pinentry-gtk2 libnss3-tools

Hasta aquí la instalación de software.

Verificación

Para verificar que todo está correcto, utilizamos el programa pcsc_scan y así comprobar que el lector funciona y lee el DNIe.

Insertamos el lector en un puerto usb y en un terminal ejecutamos

pcsc_scan

Deberíamos obtener una salida parecida a esta:

$ pcsc_scan
PC/SC device scanner
V 1.4.20 (c) 2001-2011, Ludovic Rousseau <ludovic.rousseau@free.fr>
Compiled with PC/SC lite version: 1.8.3
Using reader plug'n play mechanism
Scanning present readers..
0: ACS AET65 00 00

Sun Feb 24 11:09:37 2013
Reader 0: ACS AET65 00 00 
 Card state: Card removed, 

El programa no devuelve prompt, así que no se susten.

Insertamos el DNIe en el lector y deberíamos ver como salen una serie de mensajes en el terminal. Las últimas líneas deberían ser algo como esto:

       DNI electronico (Spanish electronic ID card)
       http://www.dnielectronico.es

Si esto es así, el sistema operativo reconoce al lector y es posible usar el DNIe en wheezy, si no es así, revisar los pasos anteriores.

Ya podemos salirnos del terminal y desconectar el lector.

Configuración de Firefox para utilizar el DNIe.

En esta sección describiré como hacer funcionar el DNIe con firefox ya que es lo interesante, entrar a los sitios como el banco o hacienda (es interesante entrar en el sitio de hacienda?????) para realizar operaciones que requieran nuestra identificación.

Básicamente, lo que haremos es bajar e instalar el certificado raíz de la policía, decirle a firefox que use el DNIe como dispositivo de seguridad e instalar el plugin de java de Sun ya que con el icedtea no me funcionó la petición de PIN que hace el banco para identificar a alguien con DNIe.

Nota importante: El paso en el que le decimos a firefox que use el DNIe como un dispositivo de seguridad requiere que firefox no esté corriendo.

Certificado raíz de la Policía

Debemos ir a este sitio;

http://www.dnielectronico.es/seccion_integradores/autoridades_cert.html

y bajarnos el certificado raíz de la policía, en mi caso, el archivo que me bajé fue:

Certificado pkcs1-sha256WithRSAEncryption

http://www.dnielectronico.es/ZIP/ACRAIZ-SHA2.zip

Una vez descargado, hay que descomprimir el zip y obtendremos un archivo llamado  ACRAIZ-SHA2.crt

En firefox (18.0.2) realizamos el siguiente procedimiento:

Edit -> Preferences -> Advanced -> Encryption -> View Certificates -> Authorities -> Import

Buscamos y elegimos el certificado descargado ACRAIZ-SHA2.crt.

Nos saldrá una ventana preguntándonos para qué porpósitos vamos a confiar en este certificado y seleccionaremos todas las opciones.

Hacemos click en OK y listo, ya tenemos la CA de la policía en nuestro repositorio de certificados de firefox.

Ahora viene un paso muy muy importante y es necesario cerrar firefox, por lo tanto, hay que copiar el siguiente comando en algún lado y ejecutarlo como usuario "normal" (no como root) solo cuando firefox esté cerrado. En este paso le diremos a firefox que use al DNIe como dispositivo de seguridad.

Repito, este comando debe ejecutarse cuando firefox no esté corriendo. Cuando firefox esté cerrado, ejecutarlo como usuario, no como root.

$ modutil -dbdir ~/.mozilla/firefox/$(cat ~/.mozilla/firefox/profiles.ini | \

grep Path | awk -F"=" '{print $2}') -add "DNIe" -libfile /usr/lib/opensc-pkcs11.so

El comando debería ejecutase sin problemas.

Para verificar que tenemos el DNIe como dispositivo de seguridad en firefox realizamos lo siguiente en este orden:

1. Desconectamos el lector de trajetas inteligentes (si no lo hemos hecho ya)
2. Reiniciamos el demonio pcscd
   

   # /etc/init.d/pcscd stop
   # /etc/init.d/pcscd start
   

   
   
3. Conectamos de nuevo el lector de tarjetas inteligentes
4. Abrimos firefox y vamos a Edit -> Preferences -> Advanced -> Encryption -> Security Devices
   
   y deberíamos obtener algo como esto:

 Si no obtenemos esto, es probable que no se hayan seguido los pasos anteriores. Habría que cerrar firefox, desconectar el lector, reiniciar pcscd, conectar el lector y ejecutar firefox.

No se si es un bug, pero el lector tiene que estar conectado antes de ejecutar firefox (la mayoría de las veces).

 Instalación del plugin de java de SUN

Solo resta instalar el plugin de java de SUN (Oracle). No coloco las instrucciones porque hay muchos sitios que ya lo hacen.

A mi no me funcionó el icedtea, cada vez que un sitio me iba a pedir el PIN me salía el mensaje de error  "changing the securitymanager is not allowed".

Referencias

https://forja.cenatic.es/projects/opendnie/

https://wiki.tegnix.com/wiki/DNI_electronico


Eso es todo, espero que sirva.

El problema "magenta"

Después de comprarme una EOS 550D comencé a notar que, cuando editaba fotos con zonas "quemadas", estas zonas presentaban un color magenta. Este color magenta desaparecía cuando sobreexponía la foto (por software).

El problema es el siguiente, dcraw tiene una lista de cámaras soportadas. Dentro de las muchas cosas que se definen para cada cámara soportada, está el nivel de saturación de cada uno de los sensores.

Aparentemente, había un error en el nivel de saturación correspondiente al sensor de la 550D.

Afortunadamente, el programa dcraw sugiere una manera de conocer el nivel de saturación en una foto determinada.

Buscando por internet conseguí que, aplicándo ese procedimiento a fotos tomadas con ISO 100, podías conseguir el valor "absoluto" de nivel de saturación del sensor que hizo dicha fotografía.

El nivel de saturación es la máxima cantidad de luz que puede recibir el sensor de la cámara. Más allá de este nivel, el sensor es incapaz de percibir diferencias en la luz.

Como uso ufraw para procesar mis raw y este programa utiliza dcraw, el problema me aparecía cada vez que procesaba una foto con zonas quemadas.

Con esto en mente, voy a explicar como hice para conocer el valor del nivel de saturación del sensor de la EOS 550D y que me ha funcionado hasta ahora.

Nota: Este procedimiento está realizado y probado en linux utilizando dcraw, ufraw y netpbm.

Requisitos

Para realizar este procedimiento se necesita:

• Linux
• ufraw (fuentes)
• dcraw (fuentes)
• pamsumm (viene en el paquete netpbm. En Debian esto no es así por lo que habría que bajarse las fuentes y compilarlo)
• Una colección de archivos raw tomados con ISO 100

Procedimiento

1. Descargarse la versión más reciente de dcraw (fuentes) y compilarla


2. Asegurarse de tener instalado el binario pamsumm que es parte del paquete netpbm. En Debian no lo es, así que hay que bajarse las fuentes y compilarlas.


3. Con el dcraw compilado y un archivo raw a ISO 100,  correr el siguiente comando:
   
   ./dcraw -D -4 -j -c archivo.raw | pamsumm -max


Este comando debería mostrar un mensaje como el siguiente:


"the maximum of all samples is 13584"

Este es el valor del nivel de saturación. Su equivalente hexadecimal es lo que tenemos que colocar en el archivo dcraw.cc en las fuentes de urfaw.



4. En el archivo dcraw.cc de las fuentes de ufraw, reemplazar la línea
   { "Canon EOS 550D", 0, 0x3dd7, { 6941,-1164,-857,-3825,11597,2534,-416,1540,6039 } },
   
   por la línea
   
   { "Canon EOS 550D", 0, 0x3510, { 6941,-1164,-857,-3825,11597,2534,-416,1540,6039 } },
   
   El valor 0x3510 es el equivalente hexadecimal de 13584.




5. Compilar ufraw y hacer las pruebas

Configurar sendmail para que use a Gmail como smarthost con Debian Wheezy

Recientemente monté un "servidor multimedia" en la casa, básicamente una laptop vieja con debian Wheezy para utilizarla como servidor NAS y DLNA. Fue entonces cuando me surgió la idea de utilizar el SMTP de gmail como smarthost y de esa manera, todos los correos que se generen en el "servidor multimedia" saldrían por gmail ya que la mayoría de los ISP's colocan deliberadamente las IP's de los clientes en las listas negras de spam.

El procedimiento que explico lo realicé utilizando todo "out of the box", así que debería ser de muy fácil mantenimiento (debian way).

Elementos de software que utilicé
Distribución: Debian Wheezy
Sendmail: 8.14.4-2
sasl2-bin: 2.1.25.dfsg1-4
libsasl2-2: 2.1.25.dfsg1-4
libsasl2-modules: 2.1.25.dfsg1-4

Nota: Si falta algún otro paquete, por favor decirlo. No recuerdo si sendmail ya instala las librerías sasl.


Configuración

1. Hacer un respaldo del /etc/mail/sendmail.mc


2. Editar el /etc/mail/sendmail.conf y colocar MSP_MODE="None"


3. Editar el /etc/sendmail.mc y colocar toda la sección de "Default Mailer setup" al final del archivo.


4. Añadir la siguiente sección antes de "Masquerading options"
   
   
   dnl ###################################
   dnl # Comienzo pruebas de gmail
   dnl #
   dnl #
   dnl # Soporte para TLS (para pruebas de gmail)
   dnl #
   include(`/etc/mail/tls/starttls.m4')dnl
   dnl #
   dnl #
   dnl #
   define(`SMART_HOST',`smtp.gmail.com')dnl
   define(`RELAY_MAILER_ARGS',`TCP $h 587')dnl
   define(`ESMTP_MAILER_ARGS',`TCP $h 587')dnl
   FEATURE(`authinfo', `hash /etc/mail/client-info-gmail.db')dnl
   define(`confAUTH_MECHANISMS',`EXTERNAL GSSAPI DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
   TRUST_AUTH_MECH(`EXTERNAL DIGEST-MD5 CRAM-MD5 LOGIN PLAIN')dnl
   dnl #
   dnl #
   dnl # Fin de pruebas de gmail
   dnl ##################################
   
   
   Nota: Cuidado al copiar esto ya que aveces las comillas se malinterpretan. Yo recomiendo copiar secciones del .mc y luego editarlas para evitar problemas. Dicho queda.




5. Editar el archivo (nuevo) /etc/mail/client-info-gmail y colocar la siguiente información:
   
   AuthInfo:smtp.gmail.com "U:root" "I:usuario@gmail.com" "P:password" "M:LOGIN PLAIN"
   AuthInfo:smtp.gmail.com:587 "U:root" "I:usuario@gmail.com" "P:password" “M:LOGIN PLAIN"
   
   Nota: Cuidado al copiar las comillas dobles, mejor hacerlo a mano, sendmail puede no entenderlas bien y el servidor de gmail nos mostrará un error diciendo "530-5.5.1 Authentication Required".
   
   Nota 2: Cada "AuthInfo" es una sola línea


6. Hacer el mapa con el siguiente comando:
   makemap -r hash client-info-gmail.db < client-info-gmail


7. Asegurarse de que saslauthd está arrancado (si no, arrancarlo) y verificar que arranque en el inicio (update-rc.d saslauthd defaults).


8. Ejecutar sendmailconfig y verificar que no salga ningún error.


9. Ejecutar update-rc.d sendmail defaults para que arranque en el inicio.

Eso debería ser todo, solo queda probar.

Linux como servidor DLNA

Hace algunos meses compré un televisor Samsung LED UE37C6000. El televisor es una joya, la imágen excelente, la nitidez impresionante, es super delgado y liviano (muy apropiado para paredes de pladur) y el sonido, mejorable aunque bueno para propósitos generales.

Como todo televisor "moderno" tiene la opción de DLNA, conectores USB, HDMI, etc, etc, etc.

La primera prueba "importante" fue reproducir series y películas desde un penn drive. Bueno, eso es otra cosa, se ve impresionante y eso que están comprimidas en XviD.

Me faltaba probar la conexión a la red y la reproducción de contenido utilizando DLNA. Este televisor solo viene con un conector rj45, así que con un cable bastante largo lo conecté a un router linksys en la habitación contigua.

El televisor viene configurado de fábrica como cliente DHCP, así que se conectó sin problemas a la red. Comenzaba entonces mi aventura para conseguir un servidor DLNA para Linux.

El primero que utilicé fué mediatomb. Lo instalé en mandriva 2009.1 sin problemas (urpmi). Después de leer en varios foros, configuré el mediatomb. Es necesario agregar algunos encabezados especiales para que los videos puedan reproducirse en algunos dispositivos (como el mío). Aquí tengo un enlace si a alguien le interesa.

Que el media player el televisor viese los archivos compratidos por DLNA ya me parecía un milagro tecnológico pero cuando pude reproducir las películas fue el "non plus ultra".

Como todo en la vida, siempre hay un "plus ultra" y cuando no pude ver los subtítulos de las películas (archivos srt) me di cuenta de eso.

Volví a leer y a leer los foros, proponían una solución con mediatomb que no me gustó, consistía en hacer un "transcoding" del video adjuntándole los subtítulos al stream que se le manda al televisor, de esta manera, el cliente DLNA (el televisor) obtendría un stream con todo mezclado.

Esa solución no me gustó nada porque al hacer transcoding, el cpu estará trabajando casi al 100% todo el tiempo de reproducción lo que no es eficiente y podría afectarme en la fluidez del stream de video.

Seguí investigando y encontré MiniDLNA. Este es un pequeño servidor DLNA, muy simple, que las personas de los foros reportaban que funcionaba muy bien casi casi "out of the box". Desafortunadamente, mandriva 2009.1 no empaqueta MiniDLNA por lo que tuve que bajarlo de aquí. El programa viene en formato binario compilado estáticamente, con lo que solo necesité descomprimirlo, editar el archivo de configuración y ejecutarlo.

Eureka!!!, el MiniDLNA funciona correctamente, el televisor es capaz de reproducir una película con los subtítulos en un archivo aparte (archivo srt).

Coloco un resúmen de las cosas que se pueden hacer con MiniDLNA:

• Reproducción de subtítulos contenidos en un archivo separado.
• Funciones de pausa, stop, avance y retroceso rápido con las teclas de "cursor" del control remoto (las negras) no con las teclas de la sección de reproducción (las blancas).

A continuación coloco mi archivo minidlna.conf como ejemplo


port=8200

network_interface=eth0

media_dir=V,/peliculas

friendly_name=Linux DLNA Server

album_art_names=Cover.jpg/cover.jpg/AlbumArtSmall.jpg/albumartsmall.jpg/AlbumArt.jpg/albumart.jpg/Album.jpg/album.jpg/Folder.jpg/folder.jpg/Thumb.jpg/thumb.jpg

inotify=yes

enable_tivo=no

notify_interval=900

serial=12345678

model_number=1

Usar HTC Desire como módem en Linux

Recientemente compré un HTC Desire. Aún estoy maravillado con las cosas que puedo hacer con este "smartphone". Es un teléfono super completo y eso de que tenga Android... ufffff lo máximo.

Para explotar todo el potencial de este tipo de teléfonos, hay que contratar un plan de datos de tarifa plana porque si no, la factura es descomunal.

Ok, pasando al tema en cuestión, mi proveedor de telefonía (Orange España al momento de escribir esto) permite utilizar el teléfono como modem para conectarse a internet y el HTC Desire viene con ese "modo" incluido de fábrica. Solo faltaba tratar de hacerlo funcionar en Linux ya que el manual solo se limita a hacerlo con el HTCSync.

Como era de esperarse, el HTCSync no viene para Linux, así que me puse a probar por mi cuenta.

Cuando conectas el HTC Desire a una computadora (yo lo hice en mi laptop) sale un mensaje proponiendo una serie de opciones:

• Solo cargar el teléfono
• Utilizarlo como un dispositivo de almacenamiento (acceso a la SD que trae)
• Compartir conexión

La opción que nos interesa es la última, compartir conexión. Hay que tener en cuenta que el teléfono solo comaprte conexión cuando está habilitado el sistema 3G, es decir, cuando estamos conectados a la red de datos del proveedor de telefonía móvil. Si no está activado el modo 3G, sale un aviso recordándonos que debemos activar el 3G. Si le damos en "Aceptar", pasamos a la pantalla de configuración de conexiones inalámbricas. Desde aquí podemos activar el 3G.

Una vez activado el 3G, en el syslog de Linux saldrá un mensaje diciendo que hay una nueva interfaz usb (usb0 si no se tiene otra).

Con el comando ip addr show deberían salir todas las interfaces y entre ellas la usb0 con el flag de "DOWN". Simplemente debemos correr ifconfig usb0 up y verificar que ahora muestra el flag "UP".

Falta colocarle un IP, un default gateway y los servidores DNS. Afortunadamente, el teléfono tiene un servidor dhcp con lo que basta ejecutar:

dhclient usb0

y esperar a que tengamos IP, DNS's y default gateway.

Verificar con route -n que tenemos default gateway y ejecutar dig para ver si obtenemos respuesta.

En mi caso si la tuve. Eso es todo, ya estamos conectados a internet utilizando el HTC Desire.

Todo este procedimiento se puede automatizar escribiendo unas simples reglas de udev, pero eso queda a gusto del consumidor.

Espero que esto le sirva a alguien, agradecería sus comentarios.