"Después del juego es antes del juego"
Sepp Herberger

jueves, 30 de abril de 2015

OpenWrt+USBIP+Smartboard 680 (Episodio I)

Ye he relatado mas de una vez la relación de amor/odio que tengo con las pizarras SmartBoard. En este caso me tocó enfrentarme con una SmartBoard 680: recordemos que tanto la alimentación como el flujo de datos van por el mismo cable USB, de tal forma que si el cable es demasiado largo (mas de 2 o 3 metros) la conectividad de la pizarra se resiente bastante, perdiendo la señal continuamente y haciendo inmanejable el instalache.

En este caso tengo un aula con una organización peculiar que hace que la distancia del PC a la pizarra fuese de mas de 10m. En principio compramos un cable USB activo, porque nos aseguraron que eso iba a funcionar. Ni de coña: la señal de la pizarra era solo un poco mas estable, pero al final acababa perdiendose la conexión y fallando el driver en el momento mas inoportuno.

¿Estaba todo perdido?. Pues no nos resignamos: el que no llegue el cable USB no quiere decir que no se pueda meter la señal USB por un ordenador o dispositivo, encapsularla en paquetes TCP/IP y hacerla llegar hasta el ordenador del profesor en el cual está el software de la pizarra: es lo que se llama USBIP. La idea es sencilla:

  • Conectamos la pizarra a la entrada USB un "servidor usbip" que esté cercano, para poder usar un cable corto que nos garantice una conexión estable.
  • En ese "servidor usbip" comparte  desde su IP la conexión USB a la pizarra mediante el demonio "usbipd".
  • El ordenador del profesor actúa de "cliente usbip" y se conecta al dispositivo USB compartido desde el "servidor usbip" mediante el programa cliente  "usbip", creando un puerto usb virtual, que está enganchando mediante un túnel TCP con la conexión USB de la pizarra.
  • El resultado final es que se engaña al driver, que se piensa que la pizarra (o el dispositivo que sea) está efectivamente conectada a un puerto USB del ordenador del profesor.

Un esquema visual:

¿Que utilizamos como "servidor usbip"?. Primero pensé en algún PC antiguo, con pocos recursos ya que no se necesita mucho hardware para ejecutar el servicio. Luego pensé en una Raspberry Pi, que además es pequeña y resultona. Pero al final escogí lo mas divertido: podía usar un router ADSL viejo que tuviese entrada USB y permitiese instalar OpenWrt, ya que tiene soporte para usbip.

El router ADSL elegido es un ARV7518PW, que era un router blanco Astoria que daba Ya.com:

Es un router que tiene un puerto USB, memoria flash de 8Gb y en el que, con ciertas precauciones, se puede instalar OpenWrt. También tenia el modelo anterior, un ARV4518PW de color gris, pero no lo usé ya que solo tiene una memoria flash de 4Gb y andaba un poco justito para meter el Openwrt.

La instalación de OpenWrt es un poco mas complicada que la que hice hace un tiempo para un Huawei, ya que hay que conectar por el puerto serie interno del router y reemplazar el brnboot por uboot (esto es como la bios+grub del router) y enviar la imagen con el OpenWrt. No es difícil siguiendo estas guías paso a paso:

En ambas guías se habla de instalar (o compilar desde cero) la versión 12.09 (Attitude Ajustement) de OpenWrt, pero yo me decanté por usar la versión 14.07 (Barrier Breaker), ya que cuando se hicieron esas guías todavía no había salido una versión estable de ésta. La causa es que el software es mas moderno y que se soluciona un bug en el driver la tarjeta wifi que hacía que solo funcionase a una potencia de 3db, permitiendo ahora ponerla hasta 20db y freir el cerebro de todos los hipocondriacos en varios cientos de metros a la redonda. La URL del sistema Barrier Breaker para este router, ya preparado para flashear es: https://downloads.openwrt.org/barrier_breaker/14.07/lantiq/xway/openwrt-lantiq-xway-ARV7518PW-squashfs.image.

Bueno, una vez tenemos el Barrier Breaker en el router, lo hemos conectado a la red por cable, puesto una IP fija y hemos cambiado la contraseña de root, nos conectamos a él por ssh como a cualquier otro Linux OpenWrt y empezamos a configurarlo para convertirlo en un servidor usbip, vamos allá:

# opkg update
# opkg install kmod-usbip kmod-usbip-client kmod-usbip-server
# opkg install kmod-usb-ohci
# opkg install libsysfs libwrap
# opkg install http://downloads.openwrt.org/attitude_adjustment/12.09/lantiq/danube/packages/usbip_1.1.1-2_lantiq.ipk
# opkg install http://downloads.openwrt.org/attitude_adjustment/12.09/lantiq/danube/packages/usbip-client_1.1.1-2_lantiq.ipk
# opkg install http://downloads.openwrt.org/attitude_adjustment/12.09/lantiq/danube/packages/usbip-server_1.1.1-2_lantiq.ipk
# reboot

Con esto instalamos los drivers y el software, después de reiniciar verificamos si está todo:

# opkg list-installed | grep usbip
kmod-usbip - 3.10.49-1
kmod-usbip-client - 3.10.49-1
kmod-usbip-server - 3.10.49-1
usbip - 1.1.1-2
usbip-client - 1.1.1-2
usbip-server - 1.1.1-2
#

Ahora enchufamos la pizarra al puerto USB del router y vemos si la detecta:

# opkg update
# opkg install usbutils
# lsusb
Bus 001 Device 001: ID 0b8c:0001 SMART Technologies Inc.
#

Ahi está. Veamos si se puede compartir con usbip:

# usbip list -l
Local USB devices
=================
 - busid 1-1 (0b8c:0001)
         1-1:1.0 -> usbip-host
#

Ahi está, conectada al bus 1-1, que es como lo identifica usbip. Para que se comparta el usb cada vez que arranque el sistema operativo del router  lo mejor es meter en /etc/rc.local el código siguiente:

# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

usbipd -D &
sleep 1
usbip bind -b 1-1

exit 0

Son dos instrucciones: "usbipd -D", que arranca el servidor en modo daemon, y "usbip bind -b 1-1" , que enlaza el servidor usbip con el dispositivo conectado al bus 1-1, en este caso la pizarra Smart, de tal manera que dicho dispositivo queda compartido por el demonio.

Reiniciamos y, suponiendo que 172.20.41.57 es la IP del router donde tenemos conectada la pizarra,  al hacer:

# usbip list -r 172.20.41.57
Exportable USB devices
======================
- 172.20.41.57
1-1: SMART Technologies Inc. : unknown product (0b8c:0001)
: /sys/devices/platform/ifxusb_hcd/usb1/1-1
: (Defined at Interface level) (00/00/00)
: 0 - Human Interface Device / No Subclass / None (03/00/00)

Nos aparece la pizarra lista para conectar a ella. Una comprobación mas:

#  netstat -alpt
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:3240 0.0.0.0:* LISTEN 1079/usbipd
tcp 0 0 0.0.0.0:domain 0.0.0.0:* LISTEN 1015/dnsmasq

Ahí tenemos el demonio usbipd esperando conexiones por el puerto 3240, para exportar la conexión USB de la pizarra a quien quiera conectarse a él.

Bueno, ya tenemos la parte servidora. En la próxima entrada veremos la parte cliente, que puede ser en Windows o en Linux.

 

martes, 21 de abril de 2015

Forzar la impresión en escala de grises en una impresora en color usando tea4cups.

Recientemente hemos adquirido una impresora Brother DCP-9020CDW. Mi intención era definir sobre ella dos colas, que se comportarían como dos impresoras virtuales: una para imprimir en blanco y negro y la otra para imprimir en color. La causa es que si dejo una sola cola, seguramente la mayoría de las veces la impresión será en color por simple descuido o dejadez a la hora de configurar las propiedades del trabajo de impresión, con el consiguiente desperdicio de dinero que necesitamos para pagar el billón de euros de deuda pública.

La primera idea fue manipular el fichero .ppd, haciendo una versión del mismo que dijese que la impresora era en blanco y negro, y usar dicho fichero .ppd para dar de alta la impresora correspondiente. Pues no funcionó: si se manda imprimir en color desde un puesto el trabajo salía en color independientemente de lo que dijese el .ppd que estaba permitdo.

No me quedaba otra que usar tea4cups, esa estupenda navaja suiza para las colas de impresión. Descargamos el fichero de http://www.pykota.com/software/tea4cups/download, lo descomprimimos e instalamos cada cosa en su sitio:

  • El fichero tea4cups en el directorio de backends de impresión: /usr/lib/cups/backend/
  • El fichero tea4cups.conf en el directorio de configuración de cups: /etc/cups/..

Una vez hecho esto, modificamos tea4cups.conf según nuestras necesidades. El fichero está profusamente autodocumentado con varios ejemplos de todas las virguerías que se pueden hacer con las colas de impresión, yo lo he modificado mínimamente añadiendo al original las líneas en rojo:

server:~# cat /etc/cups/tea4cups.conf 
# $Id: tea4cups.conf 120 2006-08-10 21:42:16Z jerome $
#
# Tea4CUPS : Tee for CUPS
.......
[global]
......
debug : yes
........
directory : /var/spool/cups/
.........
prehook_accounting : /root/scripts/seguimiento_impresion
..................................
...................
# posthook_dialog2 : cat >/tmp/result2

#Se incluye un filtro para la cola "BN_SALAPROFESORES" que convierte a BN los trabajos de impresión
#mandados a color, modificando el .prn bruto antes de ser procesado.
[BN_SALAPROFESORES]
filter : sed "0,/@PJL SET RENDERMODE=COLOR/{s/@PJL SET RENDERMODE=COLOR/@PJL SET RENDERMODE=GRAYSCALE/}"

El fichero /root/scripts/seguimiento_impresión del prehook_accounting será el script que se ejecutará cada vez que se mande un trabajo a cualquier impresora de CUPS. En mi caso lo uso para llevar una contabilidad de los trabajos de impresión y para otras tareas de depuración. Su contenido es:

server:~# cat /root/scripts/seguimiento_impresion
#!/bin/bash

function valid_ip()
{
local ip=$1
local stat=1

if [[ $ip =~ ^[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}$ ]]; then
OIFS=$IFS
IFS='.'
ip=($ip)
IFS=$OIFS
[[ ${ip[0]} -le 255 && ${ip[1]} -le 255 \
&& ${ip[2]} -le 255 && ${ip[3]} -le 255 ]]
stat=$?
fi
return $stat
}


#URLEncode para el titulo del documento
TEATITLE=$(python -c "import sys, urllib as ul; print ul.quote_plus(sys.argv[1])" "$TEATITLE")

#Echo copia en /tmp/ el trabajo de impresión en bruto para depuración.
#cp "$TEADATAFILE" "/tmp/$TEAJOBID.prn"

dominio=$(host -d -t CNAME servidor | grep domain | cut -f1 -d".")
paginas=$(pkpgcounter "$TEADATAFILE")

#Hay que convertir el valor de TEACLIENTHOST en un nombre de equipo.
if [ "$TEACLIENTHOST" == "localhost" -o "$TEACLIENTHOST" == "" ]
then
equipo=$(hostname -s)
else
if valid_ip $TEACLIENTHOST
then
equipo=$(host $TEACLIENTHOST | cut -d" " -f5 | cut -d"." -f1)
else
equipo=$TEACLIENTHOST
fi
fi

#Con todos estos parámetros que vienen del backend de /usr/lib/backend/teac4cups podemos llevar la contabilidad....
#En el ejemplo es un simple fichero de log, pero podría llevarse a un fichero .csv, guardarse en una BBDD o enviarse a una
#aplicacion web.
echo $TEAPRINTERNAME $TEAJOBID $TEAUSERNAME $TEATITLE - $equipo.$dominio - $TEACOPIES `pkpgcounter $TEADATAFILE` $TEAJOBSIZE>>/var/log/printaccounting.log

exit 0

Para que nuestros trabajos de impresión pasen por el backend de tea4cups y sean enviados a este script anterior, hay que modificar su definición en el el fichero /etc/cups/printers.conf, retocando el DeviceURI tal que así (ojo al parche, esto hay que hacerlo con el servicio CUPS parado):

server:~# cat /etc/cups/printers.conf
# Printer configuration file for CUPS v1.5.3
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
<Printer BN_SALAPROFESORES>
UUID urn:uuid:b21a4e7f-1d82-35aa-63cc-440dad3b7ada
Info BN_SALAPROFESORES
Location Sala de Profesores-Blanco y Negro
MakeModel Brother DCP-9020CDW CUPS
DeviceURI tea4cups://socket://172.19.196.23
State Idle
..........
</Printer>
<Printer COLOR_SALAPROF>
UUID urn:uuid:2336104b-3317-3748-702f-3063db09d1fe
Info COLOR_SALAPROF
Location Sala de Profesores-Color
MakeModel Brother DCP-9020CDW CUPS
DeviceURI tea4cups://socket://172.19.196.23
State Idle
..........
</Printer>

Siendo 172.19.196.23 la IP de nuestra impresora en la red.

En cuanto a:

filter : sed "0,/@PJL SET RENDERMODE=COLOR/{s/@PJL SET RENDERMODE=COLOR/@PJL SET RENDERMODE=GRAYSCALE/}"

esa línea es la madre del cordero y la que se encarga de dar el cambiazo de color a blanco y negro a cualquier trabajo enviado a la cola de impresión BN_SALAPROFESORES. ¿Cómo funciona esto?. Bueno, pues hay repasar como procesa los datos CUPS:

  • Las aplicaciones mandan los trabajos de impresión a CUPS. Originalmente esos trabajos están en el formato de la aplicación: odt, pdf, jpeg, xls, lo que sea.
  • CUPS procesa con el driver el trabajo de impresión y lo convierte a un lenguaje inteligible por la impresora destino. Este lenguaje puede ser PCL3/4/5, PCLXL, PostScript, ZJS, HBP, etc, etc, etc.
  • Este fichero en bruto en uno de los formatos indicados anteriormente se envía directamente a la impresora, que con su firmware lo interpreta e imprime.

En mi caso se trataba de averiguar en que formato estaba el fichero en bruto enviado para la impresora en cuestión. Eso se hace fácilmente capturando dicho fichero mediante tea4cups, en el script seguimiento_impresion:

......
......
#Echo copia en /tmp/ el trabajo de impresión en bruto para depuración.
cp "$TEADATAFILE" "/tmp/$TEAJOBID.prn"
......
......

Así conseguiremos una copia del fichero en bruto una vez  procesado por el driver en /tmp/$jobid.prn. Simplemente mandamos imprimir algo por la impresora y una vez impreso nos vamos a /tmp/$jobid.prn" y husmeamos que hay dentro. En nuestro caso es lo siguiente (marco en rojo las partes relevantes):

ESC%-12345X@PJL 
@PJL SET REPRINT=OFF
@PJL SET HOLD=OFF
@PJL SET USERNAME="root"
@PJL SET JOBNAME="Manual Centralita 7962G.pdf"
@PJL SET LOGINUSER="root"
@PJL JOB NAME="Manual Centralita 7962G.pdf"
@PJL PRINTLOG ITEM = 1,PRINTER
@PJL PRINTLOG ITEM = 2,Tue,14 Apr 2015 13:47:5
@PJL PRINTLOG ITEM = 3,Administrador
@PJL PRINTLOG ITEM = 4,CONSERJERIA
@PJL SET JOBTIME = "20150414134705"
@PJL SET STRINGCODESET=HPROMAN8
@PJL COMMENT ECONOMODE=OFF
@PJL SET ECONOMODE=OFF
@PJL SET RENDERMODE=COLOR
@PJL SET COLORADAPT=OFF
@PJL SET APTMODE=OFF
@PJL SET LESSPAPERCURL=OFF
@PJL SET FIXINTENSITYUP=OFF
@PJL SET RESOLUTION=600
@PJL ENTER LANGUAGE=XL2HB
) BROTHER XL2HB;1;0
<C0>^@<F8><86><D1>X^BX^B<F8><89>A<C0>^@<F8><88><C0>^A<F8><82>H<C0>^@<F8>(<C0>^A<F8>&<C0>^B<F8>%<C8><C0>^HdRegular<F8>'<C0>^@<F8>4C<D3>d^@d^@<F8>*u<C0>^@<F8>d<C0>^@<F8>b<C1><A0>^R<F8>l<C1><9E>^Z<F8>kѠ^R<9E>^Z<F8>g<C9><C1>^W^@^@^@^C^@^@^@^A^@^E^@^@^@^D^@^H^D^A^@^E^@^A^@^D^@^Q^D^A^@^E^@^B^@^D^@^Q^D^A^@^E^@^C^@^D^@
..........
..........

Este fichero se compone de una cabecera, legible, seguida por los datos de impresión ya en el formato interno de la impresora. El lenguaje de impresión es XL2HB, que buscando un poco en internet resulta ser una versión de PCLXL hecha por  Brother.

La cabecera está también en un formato bastante popular llamado PJL, que es un lenguaje de control de trabajos de impresión. La parte interesante es esta:

@PJL SET RENDERMODE=COLOR

que es donde se define si el trabajo está en blanco y negro o en color. Esta claro que si justo antes de enviarlo a la impresora, hacemos una búsqueda en el fichero en bruto y cambiamos la línea anterior por:

@PJL SET RENDERMODE=GRAYSCALE

el trabajo llegará en blanco y negro, habiendo dado el cambiazo en el último momento. Esto se hace con una orden sed de sustitución ya archiconocida de Linux y Unix:

# sed "0,/@PJL SET RENDERMODE=COLOR/{s/@PJL SET RENDERMODE=COLOR/@PJL SET RENDERMODE=GRAYSCALE/}" < infile >outfile

Esta linea dice "búscame la primera aparición de @PJL SET RENDERMODE=COLOR y, si la hay, cámbiala por @PJL SET RENDERMODE=GRAYSCALE"

Al estar la orden dentro del fichero teacups.conf, en la clausula filter y en la sección de BN_SALAPROFESORES:

[BN_SALAPROFESORES]
filter : sed "0,/@PJL SET RENDERMODE=COLOR/{s/@PJL SET RENDERMODE=COLOR/@PJL SET RENDERMODE=GRAYSCALE/}"

se aplicará a todo trabajo de impresión que pase por la cola BN_SALAPROFESORES antes de enviarlo a la impresora, como era nuestro objetivo inicial.

Nota adicional: el formato XL2HB no está inicialmente soportado por pkpgcounter, por lo que da un número de páginas estrambótico al hacer la contabilidad. No problem, existe un parche sencillo sobre /usr/share/pyshared/pkpgpdls/pclxl.py (recordemos que es una variante de PCLXL) para que funcione:

Y con esto acabamos por esta vez.. Le estoy dando una caña tremenda al OpenWrt sobre los Astoria ARV7518PW, a ver si pronto tengo algo que contar, pero los Linux embebidos son duros...

 

miércoles, 15 de abril de 2015

Plugins rebeldes en Firefox y Chrome.

Adobe no es una empresa que se caracterice por su amor a Linux y a Firefox. Una de sus jugarretas ha sido dejar abandonada en la versión 11 el plugin de Flash para Firefox. La causa está en que Firefox utiliza el interface NPAPI para incluir plugins y Adobe decidió no actualizar mas el Flash con ese API en Linux. En cambio siguió actualizándolo para PPAPI, el API usado por Google Chrome, de tal forma que el Flash para Chrome ya va por la versión 17.
 
Afortunadamente, un máquina ruso decidió construir un wrapper de PPAPI a NPAPI que permite instalar el Flash Player diseñado para PPAPI en Firefox y otros navegadores basados en Mozilla, de tal forma que podamos disfrutar de versiones mas recientes de Flash en los mismos. Aquí van un par de enlaces con el software necesario:
Básicamente el truco está en descargarse el Pepper Flash Plugin, que es el que trae Chrome, copiarlo a la carpeta de plugins de Mozilla/Firefox e instalar o compilar el wrapper según las instrucciones de los enlaces.
 
Otro problema que tenemos son los plugins que ni siquiera existen en Linux,como el de Shockwave Player, también de Adobe, o el Silverlight de Microsoft. Pues tambien hay otra solución: Pipelight. Este es otro wrapper que permite instalar ambos plugins (y alguno mas, como el de Flash) dentro de Firefox, Chrome o Midori. Con Chromium parece ser que no funciona .
 
En este caso se usan los plugins originales de Windows mediante una versión tuneada de Wine que permite embeberlos dentro el navegador como un plugin más. Ojo al parche: no se instala el Firefox para Windows con los plugins dentro de Wine, lo que se hace es usar el Firefox de Linux y correr dentro los plugins usando un Wine customizado. Ahí es nada. 
 
Los enlaces son:
Básicamente hay que añadir su repositorio e instalar el paquete con el pipelight-plugin. Una vez hecho esto tan solo hay que activar los plugins. Según dicen en su página, soportan los siguientes plugin de Windows dentro de un Firefox para Linux:
  • Silverlight
  • Adobe Flash
  • Shockwave Player
  • Unity Web Player
  • Widevine
  • npactivex
  • Adobe Reader
  • Foxit PDF Reader
  • Grandstream Plugin
  • Hikvision Plugin
  • Roblox Plugin
  • Vizzed Retro Game Room
  • Viewright Caiway
  • Triangleplayer
  • Unity Web Player (64-bit)
  • Adobe Flash (64-bit)
Seguramente no sean infalibles y tengamos algún problema con ellos, pero no está mal esto de darle vueltas para hacer funcionar cosas a priori impensables. Cualquier día hacen funcionar el Autocad en Wine y yo me caigo de la silla.
 
 

jueves, 9 de abril de 2015

Obtener IP sabiendo la MAC

En una de las redes que administro casi todos los PC tienen IP dinámica. Cuando necesito conectarme a uno de ellos me encuentro con que no sé que IP tienen, aunque si que conozco su MAC. Una opción es usar nmap, pero normalmente es bastante lento ya que suele hacer mas cosas que una simple búsqueda de IP. Hace poco descubrí la utilidad arp-scan, ideal para mis fines y mucho mas rápida que nmap. La idea es hacer un script que dado un nombre de PC o bien una MAC, me averigüe su la IP que tiene en ese momento

Para ello, primero tenemos que hacer una lista de PC y MACs, y almacenarlos en un fichero "inventario.txt" con la estructura:

PC1=84:c9:b2:66:fa:c0
PC2=e8:61:94:26:3f:93

El script busca-ip.sh sería:

#!/bin/bash
#Esto debe ejecutarse como root

INTERFACE="eth0"
if [ "$EUID" -ne 0 ]
then
  echo "No eres root"
  exit 1
fi
if [ $# -eq 0 ]
then
   echo "Uso: $0"
   exit 1
fi
mac=$(grep -i "^$1=" inventario.txt | cut -d"=" -f2)
if [ -z $mac ]
then
   mac=$1
else
   echo "MAC: $mac"
fi
ip=$(arp-scan --interface=$INTERFACE --localnet | grep -i $mac)
if [ -z "$ip" ]
then
   echo "$1 no se ha encontrado"
else
   echo "La IP es $ip"
fi
exit 0

Para probar simplemente haremos (no olvidemos instalar previamente el paquete arp-scan):

# apt-get install arp-scan
# ./busca-ip.sh PC1
MAC: 84:c9:b2:66:fa:c0
La IP es 172.19.231.174 84:c9:b2:66:fa:c0       (Unknown)
# ./busca-ip.sh 84:c9:b2:66:fa:c0
La IP es 172.19.231.174 84:c9:b2:66:fa:c0       (Unknown)
# ./busca-ip.sh 84:c9:b2:66:fa:c1
84:c9:b2:66:fa:c1 no se ha encontrado

Y eso es todo por hoy.

lunes, 23 de marzo de 2015

Opinión: Administración Electrónica, así no.

Se supone que el futuro es hacer multitud de trámites con la Administración usando certificados digitales. Del DNIe nos vamos a olvidar ya que usarlo es una tortura incluso en Windows: instalación manual tocando en determinados sitios del navegador, versiones de java incompatibles y petición del pin a traición.

Hoy voy a hablar de tres trámites con la Administración usando el certificado digital de la FNMT.

  • Acceso a notificaciones de la AEAT: usando el certificado digital instalado en el navegador y teniendo potra con el plugin de Java puede acceder uno a las notificaciones del ministro Montoro. Nada que objetar, excepto que te salta algún applet de Java para manejar el certificado o lo que quiera que haga.
  • Acceso a las notificaciones 060, que se supone que es la punta de lanza de la Administración Electrónica: terrible. No les basta con tener el certificado digital instalado en el navegador, hay que instalarlo en la máquina virtual de Java. ¿Cómo?: a traves del Panel de Control de Java (/usr/bin/ControlPanel). Resulta que la versión del Oracle Java que tenía instalada no tenía la pestaña para añadir un certificado digital. Tuve que probar varias versiones hasta dar con una. Una vez logré entrar, resulta que dicho sistema de notificaciones para entidades públicas lo usan cuatro y el del tambor, como diría Fedegggico.
  • Solicitud a la AEAT del modelo 143: limpio, sin Java. Usando solamente el certificado del navegador incluso para firmar la solicitud.

Y aquí está la gracia: la misma administración (la Administración General del Estado) requiere tres métodos distintos de acceso y firma para tres procedimientos, dos de los cuales se realizan ante la AEAT. Así no se puede: no puedes obligar al ciudadano a que tenga que devanarse los sesos según el trámite que vaya a hacer.

La raíz del problema no la sé, pero me la huelo: cada procedimiento se ha subcontratado a una empresa distinta, que lo ha implementado como buenamente ha podido con sus sub-sub-asalariados. El resultado final es como si se hubiese encomendado al ejército de Pancho Villa. No se puede construir un front-end heterogéneo para el ciudadano así, señores gobernantes: menos comilonas y mas sentido común.

Fin de la cita.

Listar el valor real de los parámetros de un módulo cargado por el kernel.

Normalmente, los drivers de Linux tienen diversos parámetros con los que podemos jugar al cargarlos en memoria, logrando así que funcionen mejor o, simplemente, funcionen correctamente. Cuando trabajamos con hardware diverso siempre que tenemos problemas de estabilidad o rendimiento tenemos que andar husmeando y afinando dichos parámetros. La forma de saber que parámetros tiene un driver es:

root@A99-PRO:~# modinfo radeon
filename: /lib/modules/3.16-0.bpo.2-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko
license: GPL and additional rights
description: ATI Radeon
author: Gareth Hughes, Keith Whitwell, others.
firmware: radeon/R520_cp.bin
.......
firmware: radeon/BONAIRE_vce.bin
alias: pci:v00001002d000099A4sv*sd*bc*sc*i*
........
alias: pci:v00001002d00001304sv*sd*bc*sc*i*
depends: drm,drm_kms_helper,ttm,i2c-core,i2c-algo-bit
intree: Y
vermagic: 3.16-0.bpo.2-amd64 SMP mod_unload modversions
parm: no_wb:Disable AGP writeback for scratch registers (int)
parm: modeset:Disable/Enable modesetting (int)
parm: dynclks:Disable/Enable dynamic clocks (int)
parm: r4xx_atom:Enable ATOMBIOS modesetting for R4xx (int)
parm: vramlimit:Restrict VRAM for testing, in megabytes (int)
parm: agpmode:AGP Mode (-1 == PCI) (int)
parm: gartsize:Size of PCIE/IGP gart to setup in megabytes (32, 64, etc., -1 = auto) (int)
parm: benchmark:Run benchmark (int)
parm: test:Run tests (int)
parm: connector_table:Force connector table (int)
parm: tv:TV enable (0 = disable) (int)
parm: audio:Audio enable (-1 = auto, 0 = disable, 1 = enable) (int)
parm: disp_priority:Display Priority (0 = auto, 1 = normal, 2 = high) (int)
parm: hw_i2c:hw i2c engine enable (0 = disable) (int)
parm: pcie_gen2:PCIE Gen2 mode (-1 = auto, 0 = disable, 1 = enable) (int)
parm: msi:MSI support (1 = enable, 0 = disable, -1 = auto) (int)
parm: lockup_timeout:GPU lockup timeout in ms (defaul 10000 = 10 seconds, 0 = disable) (int)
parm: fastfb:Direct FB access for IGP chips (0 = disable, 1 = enable) (int)
parm: dpm:DPM support (1 = enable, 0 = disable, -1 = auto) (int)
parm: aspm:ASPM support (1 = enable, 0 = disable, -1 = auto) (int)
parm: runpm:PX runtime pm (1 = force enable, 0 = disable, -1 = PX only default) (int)
parm: hard_reset:PCI config reset (1 = force enable, 0 = disable (default)) (int)
parm: vm_size:VM address space size in gigabytes (default 4GB) (int)
parm: vm_block_size:VM page table size in bits (default 9) (int)
parm: deep_color:Deep Color support (1 = enable, 0 = disable (default)) (int)

La forma en que se da valor a esos parámetros es en /etc/modprobe.d. Por ejemplo si queremos dar un valor al parámetro mode del driver radeon haríamos (el nombre del fichero radeon-kms.conf es arbitrario):

root@A99-PRO:~# cat /etc/modprobe.d/radeon-kms.conf 
options radeon modeset=1
root@A99-PRO:~#

Otra opción es añadirlo en /boot/grub.cfg, en la línea que carga el núcleo:

....
linux /boot/vmlinuz-3.10.12-100.fc18.x86_64 root=UUID=e39b2bba-0709-4e67-89b6-c8ebcf89592f ro radeon.modeset=0
....

Hay varios sitios más desde donde dar esos valores,pero estos son los mas usuales.

Mi problema era que quería saber, con el sistema ya arrancado, que valor tenían realmente los parámetros. Lo encontré en http://stackexchange.com, pero por desgracia perdí la referencia al mensaje concreto. El script es este:

root@A99-PRO:~# cat parametros-modulo.sh 
#!/bin/bash

cat /proc/modules | grep $1 | cut -f 1 -d " " | while read module; do \
echo "Module: $module"; \
if [ -d "/sys/module/$module/parameters" ]; then \
ls /sys/module/$module/parameters/ | while read parameter; do \
echo -n " $parameter="; \
cat /sys/module/$module/parameters/$parameter; \
done; \
fi; \
echo; \
done

Ahora, si queremos saber el valor que tienen todos los parámetros de, por ejemplo, el módulo radeon y sus módulos dependientes haríamos:

root@A99-PRO:~# ./parametros-modulo.sh radeon
Module: radeon
agpmode=0
aspm=-1
audio=-1
benchmark=0
connector_table=0
deep_color=0
disp_priority=0
dpm=-1
dynclks=-1
fastfb=0
gartsize=512
hard_reset=0
hw_i2c=0
lockup_timeout=10000
modeset=1
msi=-1
no_wb=0
pcie_gen2=-1
r4xx_atom=0
runpm=-1
test=0
tv=1
vm_block_size=9
vm_size=4
vramlimit=0

Module: ttm

Module: drm_kms_helper
edid_firmware= poll=Y

Module: drm
debug=0
edid_fixup=6
rnodes=0
timestamp_monotonic=1
timestamp_precision_usec=20
universal_planes=0
vblankoffdelay=5000

Module: i2c_algo_bit
bit_test=0

Module: i2c_core

Y eso esto todo, amigos.

lunes, 16 de marzo de 2015

Montemos una webcam IP barata (y III)

Bueno, recapitulemos:

  • En la primera parte vimos como instalar el sabor OpenWrt de Linux en un router ADSL Huawei de Vodafone que estaba desahuciado. Esa entrada nos la podemos saltar en gran parte si queremos montar nuestro sistema usando una Raspberry Pi o cualquier miniordenador.
  • En la segunda parte vimos como configurar la cámara, el almacenamiento de las imágenes en una ubicación remota y, usando el software motion, hacer las primeras capturas.

Pues vamos ahora a sacar jugo a lo que tenemos montado.

1. Configurar la detección de movimiento.

Ahora vamos a detectar el movimiento, jugando con los parámetros de /etc/motion.conf. Hay muchas guías en la red explicando los distintos parámetro. A mi me han dado buenos resultados estos:

daemon on
width 352
height 288
framerate 20
snapshot_interval 60
locate_motion_mode on
locate_motion_style redbox
snapshot_filename %Y-%m-%d-%H:%M:%S-snapshot
picture_filename %Y-%m-%d-%H:%M:%S-%q
pre_capture 3
post_capture 3
output_normal on
minimum_motion_frames 1
lightswitch 20
threshold 2000

El resto de parámetros de motion.conf los dejamos igual. Básicamente decimos a motion que se ejecute de fondo, capture a resolución 352x288 y a 20 fps por segundo cuando detecte movimiento. Independientemente, cada 60 segundos toma una captura, haya movimiento o no. Cuando detecta movimiento remarca la zona con una caja roja. Los ficheros donde guarda las capturas tienen en su nombre la fecha y la hora. Defino un valor para los cambios de luz (ligthswitch) y número de pixeles cambiados (treshold) que me han funcionado bien ante falsos positivos.

El parámetro "output_normal on" indica que cuando hay movimiento capture todos los fotogramas que quiera. Otros valores que podemos dar harán que se capture el mejor fotograma, o que se grabe un vídeo en lugar de fotogramas sueltos.

Adicionalmente podemos asociar comandos o scripts a determinados eventos, por ejemplo añadiendo a motion.conf:

on_event_start echo "Detectado inicio de movimiento %H:%M:%S" >> /mnt/snapshot/log.txt
on_picture_save echo "Guardando imagen en %f %H:%M:%S" >> /mnt/snapshot/log.txt
on_event_end echo "Fin de movimiento %H:%M:%S" >> /mnt/snapshot/log.txt
on_movie_start echo "Empezando video %f %H:%M:%S" >> /mnt/snapshot/log.txt
on_movie_end echo "Finalizando video %f %H:%M:%S" >> /mnt/snapshot/log.txt

El fichero /mnt/snapshot/log.txt guardará un log de los eventos detectados. Nótese el uso de variables de sustitución, aquí estan todos. Algunos sólo pueden usarse en determinado eventos, como %f (nombre de fichero de captura) que solo aparece on_picture_save, on_movie_start y on_movie_end.

2. Aviso remoto de eventos

Para avisar remotamente de los eventos lo mas sencillo es usar correo (aunque otras opciones son usar SMS o twitter, ya que hay APIs para ello). Me he decantado por lo mas sencillo y he usado una cuenta de gmail por smpt. He probado ssmtp y mailsend, pero el primero no permite enviar adjuntos y el segundo no funciona con gmail en Barrier Breaker (no tiene activo el SSL), así que los descarté.

La opción que mejor me ha funciona es la combinación de msmtp y mutt, ya que ambos combinados permiten enviar mensajes por gmail y adjuntar ficheros (por ejemplo imágenes). Mutt compone el correo y msmtp lo envía. Los instalamos:

root@OpenWrt:~# opkg install msmtp mutt

Y configuramos msmtp:

root@OpenWrt:~# cat /etc/msmtprc
account default
host smtp.gmail.com
port 587
auth on
user mi.usuario@gmail.com
password mipassword
auto_from off
from mi.usuario@gmail.com
tls on
tls_starttls on
tls_certcheck off
logfile
syslog LOG_MAIL

Una pruebecita:

root@OpenWrt:~# echo -e "Subject: Correo de prueba\r\n\r\nEsto es un email de prueba" | sendmail destinatario@gmail.com

Ahora configuramos mutt:

root@OpenWrt:~# cat .muttrc
set sendmail="/usr/bin/msmtp"
set from="mi.usuario@gmail.com"
set realname="2Tazasdelinux"

La prueba, enviando /mnt/snapshot/lastsnap.jpg como adjunto:

root@OpenWrt:~# echo "Hola" > mensaje.txt
root@OpenWrt:~# mutt -s "Test mail" destinatario@gmail.com -a /mnt/snapshot/lastsnap.jpg < mensaje.txt

3. Juntando lo anterior.

Voy a definir un script que hará el envío de correos ante los eventos de motion. El script se disparará con 3 posibles eventos:

  • on_event_start: guarda información en el log, crea el fichero /tmp/motion.txt que hará de testigo y envia un correo de deteccion de movimiento.
  • on_picture_save:  guarda información en log y almacena el nombre del fichero con la captura en /tmp/motion.txt, siempre que dicho fichero exista.
  • on_event_end:  guarda información en el log, si existe /tmp/motion.txt coge todas las imágenes, las comprime con el comando zip y envia un correo con el fichero comprimido conteniendo todas las capturas. Finalmente, borra /tmp/motion.txt. No olvidar hacer un "opkg install zip". La idea está sacada de aquí.

Modificamos /etc/motion.conf para que tenga este contenido:

on_event_start /root/controlador.sh start "%H:%M:%S-%Y/%m/%d"
on_event_end /root/controlador.sh end "%H:%M:%S-%Y/%m/%d"
on_picture_save /root/controlador.sh picture "%H:%M:%S-%Y/%m/%d" "%f"

Y este es el script controlador.sh (no olvidar hacerlo ejecutable con "chmod +x /root/controlador.sh"):

!/bin/ash

#Parametro 1: start, picture, end
#Parametro 2: fecha
#Parametro 3: nombre fichero (opcional)

#Obtenemos fecha y hora por si queremos poner algun filtro sobre ella y solo avisar en determinados
#momentos
time=$(date +%s)
anio=$(date +%Y @$time)
mes=$(date +%m @$time)
dia=$(date +%d @$time)
hora=$(date +%H @$time)
minuto=$(date +%M @$time)
diasemana=$(date +%u @$time) #El 1 es lunes

email=0
if [ $diasemana -ge 6 -o $hora -le 7 -o $hora -ge 17 ]  # sabado/domingo o cualquier dia antes de las 8:00 o despues de las 17:00
then
   email=1
fi

case $1 in

   "start")
    echo "Detectado inicio de movimiento $2" >> /mnt/snapshot/log.txt
     test $email -eq 1 && echo -e "Subject: Evento camara\r\n\r\nDetectado inicio de movimiento $2" | sendmail destinatario@gmail.com
        touch /tmp/motion.txt
        ;;
   "picture")
    echo "Guardando imagen $2 : $3" >> /mnt/snapshot/log.txt
        test -e /tmp/motion.txt && echo $3 >> /tmp/motion.txt
    ;;
   "end")
    echo "Detectado fin de movimiento $2" >> /mnt/snapshot/log.txt
        ficheros=$(cat /tmp/motion.txt | tr '\n' ' ')
        rm /tmp/motion.txt
        echo "Historia de capturas $ficheros" >> /mnt/snapshot/log.txt
        zip -9 /mnt/escena.zip $ficheros

        echo "Detectado fin de movimiento $2" > /mnt/mensaje.txt
        test $email -eq 1 && mutt -s "Evento camara" destinatario@gmail.com -a /mnt/escena.zip < /mnt/mensaje.txt
        rm /mnt/escena.zip
    ;;
esac
#Borra fichero "sent" creado por sendmail si existe, para liberar espacio
rm -rf /root/sent

Como se puede ver, filtro las capturas para que solo avisen mediante correos los fines de semana y los días de diario entre las 17:00 y las 7:59. El resto del tiempo, no. Que cada cual adapte esto a sus circunstancias.

4. Arranque automático de motion.

Ante cualquier reinicio del router nos interesa que motion se ejecute automáticamente en el arranque. Lo mejor es ponerlo como un initscript.

root@OpenWrt:~# cat /etc/init.d/motion
#!/bin/sh /etc/rc.common

START=99
start() {
    motion -c /etc/motion.conf
}

stop() {
    killall motion
}

Lo hacemos ejecutable:

root@OpenWrt:~# chmod 755 /etc/init.d/motion

Y lo ponemos para que se ejecute en el arranque:

root@OpenWrt:~# cd /etc/rc.d
root@OpenWrt:~# ln -s ../init.d/motion S99motion

También podremos pararlo y arrancarlo a voluntad con:

root@OpenWrt:~# /etc/init.d/motion stop
root@OpenWrt:~# /etc/init.d/motion start

5. Rotación de ficheros.

Los ficheros de imágenes se acumulan en el directorio /mnt/snapshot. Lo lógico es borrar los mas antiguos con una tarea en el cron del Linux:

root@OpenWrt:~# cat /root/limpieza.sh
#!/bin/ash
find /mnt/snapshot/ -name '*.jpg' -mtime +30 -exec rm {} \;

Este script anterior (no olvidar hacerlo ejecutable) borra los ficheros jpg con mas de 30 días de antigüedad. Lo añadimos al crontab:

root@OpenWrt:~# crontab -e
00 17 * * * /root/limpieza.sh
00 16 * * * /etc/init.d/sysntpd restart

Cada día a las 17:00 hacemos limpia. Nótese que a las 16:00 reiniciamos también el demonio sysntpd para sincronizar de nuevo el reloj de nuestro Linux. El fichero donde se guarda esto en OpenWrt es /etc/crontabs/root.

6. Mejoras.

Algunas mejoras que no he implementado, pero pueden ser interesantes en el futuro:

  • Grabar vídeos en lugar de capturas de fotos. Esto se hace jugando con el parámetro output_normal de motion.conf.
  • Conectarse a Internet con un dongle 3g, aqui en español, en lugar de red cableada.
  • Conectarse a Internet con conexión wifi, en lugar de red cableada.
  • Guardar las imágenes en un servidor ftp remoto.

7. Referencias.

Para montar este tinglado he tirado de muchas referencias por todo Internet, aquí van las mas útiles que no he incluido a lo largo de estas tres entradas:

Bueno, pues me ha gustado esto del OpenWrt. Ya tengo otro proyectito en mente en usarlo para solucionar un problemón de las pizarras digitales. Si me funciona, lo contaré aquí.

------------Fin de impresión------------

Addenda 13-mayo-2015: bueno, pues esto funciona como un reloj del glorioso ejército soviético y tengo vigilada una estancia con aviso de correos sin mayor problema, pero hoy me he encontrado un contratiempo. En /mnt/snapshot/ tenía mas de 100.000 ficheros .jpg, de tal manera que se hacía totalmente inmanejable el directorio. He reescrito el script controlador.sh para que guarde cada día de captura en un directorio distinto dentro /mnt/snapshot, de manera que luego sea más sencillo buscar un día concreto y analizar las capturas. Queda así la cosa:

root@OpenWrt:~# cat controlador.sh 
#!/bin/ash

#Parametro 1: start, picture, end
#Parametro 2: fecha
#Parametro 3: nombre fichero (opcional)

#Obtenemos fecha y hora por si queremos poner algun filtro sobre ella y solo avisar en determinados
#momentos
time=$(date +%s)
anio=$(date +%Y @$time)
mes=$(date +%m @$time)
dia=$(date +%d @$time)
hora=$(date +%H @$time)
minuto=$(date +%M @$time)
diasemana=$(date +%u @$time) #El 1 es lunes
destino="/mnt/snapshot/$anio-$mes-$dia"

email=0
if [ $diasemana -ge 6 -o $hora -le 7 -o $hora -ge 17 ]  # sabado/domingo o cualquier dia antes de las 8:00 o despues de las 17:00
then
   email=1
fi

test -d $destino || mkdir -p $destino

case $1 in

   "start")
 echo "Detectado inicio de movimiento $2" >> /mnt/snapshot/log.txt
  test $email -eq 1 && echo -e "Subject: Evento camara\r\n\r\nDetectado inicio de movimiento $2" | sendmail alfonso.pastor@gmail.com
        touch /tmp/motion.txt
        ;;
   "picture")
        fichero=$(basename $3)
 echo "Guardando imagen $2 : $destino/$fichero" >> /mnt/snapshot/log.txt
        test -e /tmp/motion.txt && echo "$destino/$fichero" >> /tmp/motion.txt
        #Movemos la imagen al directorio correspondiente a la fecha de hoy.
        mv "$3" "$destino/$fichero"
 ;;
   "end") 
 echo "Detectado fin de movimiento $2" >> /mnt/snapshot/log.txt
        ficheros=$(cat /tmp/motion.txt | tr '\n' ' ')
        rm /tmp/motion.txt
        echo "Historia de capturas $ficheros" >> /mnt/snapshot/log.txt
        zip -9 /mnt/escena.zip $ficheros

        echo "Detectado fin de movimiento $2" > /mnt/mensaje.txt
        test $email -eq 1 && mutt -s "Evento camara" alfonso.pastor@gmail.com -a /mnt/escena.zip < /mnt/mensaje.txt
        rm /mnt/escena.zip
 ;;
esac
#Borra fichero "sent" creado por sendmail si existe, para liberar espacio
rm -rf /root/sent
rm -rf /sent

Ahora no tendremos problema de directorios saturados.

Addenda 29-marzo-2016: Aunque en general todo va bien, con el tiempo he ido descubriendo que no está de más hacer ciertos reinicios dentro del dispositivo OpenWrt usando el servicio cron. Eso ayuda a que todo sea mas estable y se pueda recuperar de posibles errores/cuelgues. Sería así:

root@OpenWrt:~# cat /etc/crontabs/root 
#A las 4 de la tarde reinicia demonio ntp, para forzar un sincronizado de la hora.
00 16 * * * /etc/init.d/sysntpd restart
#A las 00 de cada hora reinicia el motion, por si se ha quedado colgado.
00 *  * * * /etc/init.d/motion restart
#A las 23:55 cada dia se reinicia el dispositivo
55 23 * * * /sbin/reboot
El servicio cron de OpenWrt debe estar funcionando y activo, he aquí una pequeña guía del mismo.

Esta vez si que es:

------------Fin de impreX·!#!€@------------

Addenda 22-mayo-2016: Pues no, esto no acaba. Mas cosas metidas en este post. Y esta vez no me despido.

lunes, 9 de marzo de 2015

Montemos una webcam IP barata (II)

En el anterior post instalamos OpenWrt en nuestro router ADSL Huawei desahuciado. Vamos a ver en esta segunda parte como instalar todo el sistema de manejo de la webcam y grabado de las imágenes.

1. Conectando la webcam

El firmware Barrier Breaker no trae drivers USB ni de la cámara, así que lo primero es instalarlos:

root@OpenWrt:~# opkg update
root@OpenWrt:~# opkg install usbutils kmod-usb2 kmod-usb-core kmod-usb-ohci kmod-usb-uhci kmod-video-uvc

El driver que instalamos para nuestra cámara es kmod-video-uvc, que es el usado por un buen número de webcams en Linux. Para otras cámaras habría que encontrar el driver que funciona, por ejemplo para la EyeToy de la PS2 sería kmod-video-gspca-ov51.

Puede que la postinstalación nos de errores al intentar cargar los drives en memoria. No importa, tras el reinicio cargarán bien.

root@OpenWrt:~# reboot

Conectamos la cámara a un puerto usb y hacemos:

root@OpenWrt:~# lsusb
Bus 001 Device 003: ID 0c45:62f1 Microdia
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0424:2502 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ahí esta: 0c45:62f1 Microdia. Veamos si ha cargado el módulo:

root@OpenWrt:~# lsmod | grep uvc
input_core             24617  6 uvcvideo
usbcore               115555  6 uvcvideo
uvcvideo               61219  0
videobuf2_core         24202  1 uvcvideo
videobuf2_vmalloc       2881  1 uvcvideo
videodev               89620  3 uvcvideo

Perfecto, ¿existirá el dispositivo de vídeo?:

root@OpenWrt:~# ls /dev/video0
/dev/video0

Genial. Vamos a hacer una fotico, sonríe please:

root@OpenWrt:~# opkg update; opkg install fswebcam
root@OpenWrt:~# fswebcam --scale "320x240" "snapshot-1.jpg"

Bueno, pues en "snapshot-1.jpg" tenemos la captura tomada. Como nuestro router no tiene entorno gráfico no podemos verla, pero podemos sacarla de allí con:

root@OpenWrt:~# scp snapshot-1.jpg usuario@mipc:/home/usuario/ruta/a/mi/escritorio

Sustituir usuario, mipc y ruta según sea tu caso. Se copiará al escritorio de nuestro PC de trabajo y podremos ver alli que tal la captura.

2. Almacenando las imágenes.

Las imágenes que capturemos no podemos guardarlas en la memoria flash del router, que solamente tiene 16Mb de capacidad. Hay varias alternativas:

-Una unidad de almacenamiento conectada a un puerto USB

-Almacenamiento remoto. Se me ocurren tres opciones:

2.1. Carpeta compartida por Samba/CIFS.

Tomado de aquí:

root@OpenWrt:~# opkg update; opkg install kmod-fs-cifs samba36-client

Suponiendo que la unidad compartida se accede con \\ip-servidor-samba\recurso, hariamos:

root@OpenWrt:~# mount -t cifs //ip-servidor-samba/recurso /mnt -o user=usuario,password=contrasena,file_mode=0777,dir_mode=0777,nounix,noserverino

Y ya tenemos en /mnt montado el recurso compartido. Si queremos un automontaje en el arranque del sistema:

root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

sleep 30 # Esperamos un rato a que haya red...
mount -t cifs //ip-servidor-samba/recurso /mnt -o user=usuario,password=contrasena,file_mode=0777,dir_mode=0777,nounix,noserverino

exit 0

Reiniciando veremos que se monta automáticamente la carpeta compartida sobre la ruta /mnt.  En general funciona muy bien, pero por desgracia tuve que abandonarla porque el software que uso para hacer las capturas de la webcam (motion) necesita crear enlaces (symbolic link) y CIFS no soporta tal funcionalidad.

2.2. Montaje de directorio remoto por NFS.

Contado aquí. No lo llegué a probar.

2.3. Montaje de directorio remoto por sshfs.

Aunque un poco mas complicado que los anteriores, es el elegido por ser sencillo de configurar en el servidor de ficheros y permitir la creación de enlaces.

El cliente/servidor ssh que viene por defecto con OpenWrt es drobpear, pero es muy limitado para lo que queremos hacer ya que no permite fácilmente conexiones mediante relaciones de confianza, ni automatización del fichero knownhosts.

root@OpenWrt:~# /usr/bin/ssh -?
WARNING: Ignoring unknown argument '-?'
Dropbear SSH client v2014.63 https://matt.ucc.asn.au/dropbear/dropbear.html

AVISO: bajo ningún concepto desinstalar dropbear, aunque no usemos su cliente ssh, el servidor ssh es el que nos permite conectarnos al router. Si lo desinstalas puedes quedarlo aislado y tener que entrar en modo rescate y tener que cargar el firmware de nuevo.

En lugar de usar dropbear usaremos el cliente openssh, instalándolo:

root@OpenWrt:~# opkg install openssh-client sshfs openssh-keygen
root@OpenWrt:~# /usr/bin/ssh -h
unknown option -- h
usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]

Prueba de montaje en carpeta:

root@OpenWrt:~# sshfs openwrt@servidor-ficheros:/home/openwrt /mnt

Previamente debemos haber creado el usuario openwrt y su home en el PC que será nuestro servidor de ficheros, donde guardaremos las fotos de la webcam.

El montaje por ssh nos pregunta la contraseña y las típicas preguntas sobre el servidor nuevo y knownhosts, si queremos evitar esto último (útil para automatizar el montaje) pondremos estos parámetros:

root@OpenWrt:~# sshfs -o ssh_command="ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" openwrt@servidor-ficheros:/home/openwrt /mnt

Para evitar la pregunta de la clave y establecer relación de confianza al montar el directorio remoto por ssh sigo parte de este ejemplo:

root@OpenWrt:~# ssh-keygen
root@OpenWrt:~# cd /root/.ssh/
root@OpenWrt:~# scp id_rsa.pub root@servidor-ficheros:/tmp

Y metemos la clave pública en el home de openwrt en .ssh/authorized_keys:

root@servidor-ficheros:~# cat /tmp/id_rsa.pub >> .ssh/authorized_keys

Probamos que entramos sin contraseña y sin preguntitas pesadas:

root@OpenWrt:~# ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no openwrt@servidor-ficheros

Y ahora probamos el montaje:

root@OpenWrt:~# sshfs -o ssh_command="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" openwrt@servidor-ficheros:/home/openwrt /mnt
root@OpenWrt:~# ls /mnt

Por último, lo metemos en rc.local para que lo monte en el arranque:

root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

sleep 40
sshfs -o ssh_command="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" openwrt@servidor-ficheros:/home/openwrt /mnt

exit 0
Actualización 25/1/2016: después de varios meses funcionando bastante bien, había un pequeño problema recurrente. Cuando el servidor remoto donde se guardan los archivos se caía, la conexión se perdía y se empezaban a guardar las capturas en el /mnt/ local del router que como disco local se llenaba pronto y colapsaba el OpenWrt. Adicionalmente, /mnt se negaba a montarse de nuevo al no estar vacío. Con este retoque en /etc/rc.local lo limpio antes de volver a montarlo y así me evito el problema:
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.
sleep 40
umount /mnt
rm -rf /mnt/*
sshfs -o ssh_command="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" -o nonempty openwrt@servidor-ficheros:/home/openwrt /mnt

exit 0

3. Capturando el vídeo.

La primera opción que probé es mjpg_streamer:

root@OpenWrt:~# opkg update; opkg install mjpg-streamer
root@OpenWrt:~# mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -w /www/webcam -port 8080"

Si abrimos un navegador con http://ip-router:8080 veremos el flujo de vídeo de la cámara. Por desgracia, si queremos grabar:

root@OpenWrt:~# mkdir /mnt/snapshot
root@OpenWrt:~# root@OpenWrt:~# mjpg_streamer -i "input_uvc.so -d /dev/video0" -o "output_http.so -w /www/webcam -port 8080" -o "output_file.so -f /mnt/snapshot/ -d 5000"

Vemos que da error ya que el módulo output_file.so no está en el paquete mjpg_streamer de OpenWrt.

El siguiente candidato es motion, que además luego me doy cuenta de que tiene muchas más funcionalidades que mjpg_streamer.

root@OpenWrt:~# opkg update;  opkg install motion
root@OpenWrt:~# mkdir -p /mnt/snapshot

Configuramos el programa:

root@OpenWrt:~# nano /etc/motion/motion.conf
#Solo toco estos parámetros, el resto los quedo igual de momento:
daemon on
width 352
height 288
framerate 5
snapshot_interval 10
target_dir /mnt/snapshot
snapshot_filename %Y-%m-%d-%H:%M:%S-snapshot-%v
picture_filename %d%m%Y-%H%M%S-%q
stream_port 8081
stream_maxrate 5
stream_localhost off

Lo ejecutamos con:

root@OpenWrt:~# motion -c /etc/motion.conf

Si abrimos un navegador con http://ip-router:8081 veremos el flujo de vídeo de la cámara. Simultáneamente se graban 5 frames por segundo en /mnt/snapshot cuando la cámara detecte movimiento. Si no hay movimiento se grabará una imagen cada 10 segundos (llamada *snapshot.jpg). Esto tiene mejor pinta. Si queremos matar el proceso, que se está ejecutando como demonio, haremos:

root@OpenWrt:~# killall motion

Con esto acaba la segunda parte. Para la tercera queda:

  • Ejecución de motion como servicio.
  • Afinar la detección de movimientos.
  • Detectar eventos y conectarlos al envío de correos electrónicos de aviso.
  • Y varias sugerencias mas para ampliar esto.

Hasta la próxima......

lunes, 2 de marzo de 2015

Montemos una webcam IP barata (I)


Nota 22/febrero/2018:Este post tiene muchas continuaciones, tantas que necesito un índice que pondré aquí por ser el principio de todo:


A continuación el mensaje original:


El reto que tengo ahora es montar un sistema de videovigilancia con una cámara IP con elementos baratos o de desecho. El objetivo es:

  • Un sistema de vigilancia conectado a internet por wifi, cable o incluso 3G.
  • Que tenga posibilidad de grabar imágenes en un almacenamiento remoto (por ejemplo, un servidor).
  • Que tenga detección de movimientos.
  • Que tenga la posibilidad de mandar avisos por correo electrónico (o SMS, twitter, ...).

El hardware del que dispongo es mínimo:

  • Un router ADSL que permita instalar OpenWrt una distribución de Linux embebido para routers. En mi caso es un Huawei HG556a ofrecido por el ADSL de Vodafone que me dieron porque estaba muerto de risa en un trastero. Elegí este router por la facilidad con la que se instala OpenWrt en él (era mi primera vez con OpenWrt) y porque tiene muchas posibilidades de conectividad: 2 puertos USB, interfaz ethernet e interfaz wifi.

 

  • Una webcam USB barata de DealExtreme. En mi caso salió gratis ya que cuando me la enviaron no funcionaba (mostraba la imagen negra), asi que reclamé y me enviaron otra gratis. Al poco tiempo un usuario de DX me dijo que probase a desmontar la carcasa, lo hice y empezó a funcionar: se había desencajado por dentro y la lente del objetivo no apuntaba hacía donde debía.

Vamos a ver los pasos a seguir:

1. Instalación de OpenWrt.

Lo primero es confirmar que el router es compatible con OpenWrt, confirmándolo en la página correspondiente http://wiki.openwrt.org/toh/huawei/hg556a.

Lo segundo es saber que versión del router tenemos para descargar la imagen adecuada. En este caso se hace mirando el número de serie, en mi caso es: N/S: 30692100.... Cotejando este número en el enlace exterior veo que el modelo exacto del router es:

HG55VDFA VER.C
HG556BVDFA - HG556(B)VDFA
Wifi: Atheros AR9223
OpenWrt file (≥CC) Ver. B.

Mirando en http://wiki.openwrt.org/toh/huawei/hg556a, vemos que hay 2 opciones para instalar:

  • La versión estable, llamada Barrier Breaker.
  • La versión de testing correspondiente al la versión B de nuestro router, del snapshot diario.

Nos decantamos por la versión estable, que descargamos del enlace anterior. Para instalar seguimos estos pasos:

    • Poner en nuestro PC una direccion IP fija, la 192.168.1.35 y conectarlo por cable ethernet al router.
    • Desconectar el router de la corriente.
    • Pulsar el botón RESTART del router. Mantenerlo apretado.
    • Conectar el router a la corriente.
    • Esperar 12 segundos o más.
    • Soltar el botón del router.
    • En el navegador de nuestro PC, ir a http://192.168.1.1. Esa es la página para cargar un nuevo firmware.
    • Seleccionar el archivo .bin bajado anteriormente.
    • Seleccionar "Update Software" para iniciar el proceso de cambio del firmware.
    • Esperar a que reinicie.
    • Hacer
                # telnet 192.168.1.1

     para entrar en el router. La primera tarea es cambiar la contraseña de root con:

                root@OpenWrt:/# passwd
    • Despues de esto, podremos entrar con
                # ssh root@191.168.1.1

Con esto ya tenemos un Linux funcional con un conjunto de paquetes básicos para trabajar. Existe un interface web de configuración llamado Luci, al que podremos acceder desde el navegador en http://192.168.1.1 o la IP que posteriormente pongamos a nuestro router.

En otros router el proceso de instalación es bastante mas costoso, necesitando abrir el router y conectar un adaptador USB-TTL-serie  al puerto serie de la placa  y dar ordenes por terminal desde el programa minicom, o incluso usando soldaduras de pines y cables para acceder al puerto serie o JTAG  y escribir esotéricas ordenes de actualización del CFE (la BIOS del router) para permitir cambiar el bootloader e instalar nuevos firmwares. Por dicho motivo este router concreto es ideal para iniciarse en OpenWrt: simplemente actualizar el firmware por su página de configuración web.

Conector serie del router:

Conector JTAG del router:

2. Configuración inicial.

Bueno, ya estamos en Linux y nos sentimos como en casa, vamos a ir configurando lo básico del sistema. Podríamos usar la interfaz web Luci para la mayoría de las opciones, pero vamos a hacerlo por línea de comandos para saber mejor que pasos damos, así que hacemos un ssh a root@192.168.1.1. Lo primero es actualizar los repositorios de paquetes (esto hay que hacerlo cada vez que reiniciemos el router, ya que se guardan en memoria RAM).

Vemos los repositorios:

root@OpenWrt:/# cat /etc/opkg.conf

dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/base
src/gz barrier_breaker_luci http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/luci
src/gz barrier_breaker_packages http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/packages
src/gz barrier_breaker_routing http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/routing
src/gz barrier_breaker_telephony http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/telephony
src/gz barrier_breaker_management http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/management
src/gz barrier_breaker_oldpackages http://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/packages/oldpackages

Si tenemos la versión testing, deberá ser:

root@OpenWrt:/# cat /etc/opkg.conf

dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz barrier_breaker_base http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/base/
src/gz barrier_breaker_luci http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/luci
src/gz barrier_breaker_packages http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/packages
src/gz barrier_breaker_routing http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/routing
src/gz barrier_breaker_telephony http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/telephony
src/gz barrier_breaker_management http://downloads.openwrt.org/snapshots/trunk/brcm63xx/generic/packages/management

Actualizamos la lista de paquetes e instalamos nano para tener un editor de textos posterior a la Constitución en vigor.

root@OpenWrt:/# opkg update
root@OpenWrt:/# opkg install nano

Ahora configuramos una IP fija en la tarjeta eth0, para integrarlo en nuestra red:

root@OpenWrt:/etc/config# nano /etc/config/network 

    config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

    config globals 'globals'
        option ula_prefix 'fd58:01a4:b44f::/48'

    config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr 'IP-FIJA-DEL-ROUTER'
        option gateway 'GATEWAY-DE-LA-RED'
        option broadcast 'BROADCAST-DE-LA-RED'
        option dns 'IP-DNS-DE-LA-RED 8.8.8.8'

    config switch
        option name 'eth0'
        option reset '1'
        option enable_vlan '1'

    config switch_vlan
        option device 'eth0'
        option vlan '1'
        option ports '0 1 2 3 4 5t'

Configuramos las DNS en resolv.conf:

root@OpenWrt:/# rm /etc/resolv.conf
root@OpenWrt:/# echo "search midominio
> nameserver IP-DNS-DE-LA-RED
> nameserver 8.8.8.8" > /etc/resolv.conf
root@OpenWrt:/# cat /etc/resolv.conf
search minominio
nameserver IP-DNS-DE-LA-RED
nameserver 8.8.8.8
root@OpenWrt:/#

Definimos bien la TimeZone para poner la hora correcta con el cliente ntp instalado:

root@OpenWrt:~# nano /etc/config/system 

config system
    option hostname 'OpenWrt'
    option zonename 'Europe/Madrid'
    option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'

config timeserver 'ntp'
    list server '0.openwrt.pool.ntp.org'
    list server '1.openwrt.pool.ntp.org'
    list server '2.openwrt.pool.ntp.org'
    list server '3.openwrt.pool.ntp.org'
    option enabled '1'
    option enable_server '0'
............
............
............

Tras esto, reiniciamos el router con reboot y cuando esté de nuevo operativo entramos por ssh root@IP-DEL-ROUTER.

3. Por si metemos la pata: actualizaciones posteriores del firmware.

Una vez instalado OpenWrt, la recuperación/actualización del firmware si rompemos algo es ya mucho mas sencilla.

Primero editamos /etc/sysupgrade.conf y añadimos los ficheros que queremos preservar en caso de instalar de nuevo el firmware, para evitar tener que configurar todo posteriormente otra vez:

root@OpenWrt:~# nano /etc/sysupgrade.conf
## This file contains files and directories that should
## be preserved during an upgrade.

# /etc/example.conf
# /etc/openvpn/

/etc/sysupgrade.conf
/etc/resolv.conf
/etc/sysctl.conf
/etc/rc.local
/etc/profile
/etc/passwd
/etc/firewall.user
/etc/dropbear/dropbear_rsa_host_key
/etc/dropbear/dropbear_dss_host_key
/etc/config/wireless
/etc/config/system
/etc/config/network
/etc/config/firewall
/etc/config/dropbear
/etc/config/dhcp

A continuación descargamos el firmware y lanzamos su instalación:

root@OpenWrt:~# cd /tmp
root@OpenWrt:/tmp# wget https://downloads.openwrt.org/barrier_breaker/14.07/brcm63xx/generic/openwrt-HW556-squashfs-cfe.bin
root@OpenWrt:~# sysupgrade -v /tmp/openwrt-HW556-squashfs-cfe.bin

Tras un rato el router reinicia y ya tenemos el sistema como nuevo pero conservando los ficheros indicados.

NOTA: si sucede algo catastrófico y el router no arranca bien y no responde a nuestros ping, siempre se puede recurrir al modo de rescate (parecido al modo rescate de un Linux normal, con un montón de funciones capadas pero al que podemos acceder por la IP 192.168.1.1 y dar algunas órdenes)

  • Poner en nuestro PC una direccion IP fija, la 192.168.1.35 y conectarlo por cable ethernet al router.
  • Desconectar el router de la corriente.
  • Conectarlo de nuevo y pulsar el botón RESTART compulsivamente mientras se enciende.
  • El sistema arranca en modo rescate, lo sabemos porque el led de encendido parpadea furiosamente.
  • Poner el .bin de la imagen en el directorio /tmp de nuestro PC
  • Hacer
        root@(none):~# ssh root@192.168.1.1

  • Traernos el .bin de la imagen a /tmp
       root@(none):~# cd /tmp
       root@(none):/tmp# scp root@192.168.1.35:/tmp/openwrt-HW556-squashfs-cfe.bin .

  • Reinstalar:
       root@(none):/tmp# sysupgrade -v openwrt-HW556-squashfs-cfe.bin

con estos pasos he podido retomar el control de la situación cuando la he liado parda mientras enredaba probando cosas.

Bueno, pues en este punto tenemos un sistema OpenWrt actualizado, integrado dentro de nuestra red local y listo para conectar nuestra cámara USB y empezar a capturar imágenes, cosa que haremos en la siguiente entrada.....