Pico Proyector Acer C112 DLP en Ubuntu 14.04 y 16.04

Estos días estoy jugando con un mini proyector Acer C112 DLP para hacerlo funcionar. Es un aparato curioso, que no tiene entrada VGA sino que se conecta por USB y con un programa cliente (EZ Display) se envía en tiempo real la pantalla desde el PC al proyector. No tiene mucha resolución ni luminosidad, pero está dentro de los márgenes que se esperan en este tipo de proyectores.

En principio el aparato solo trae el driver/programa cliente para Windows XP (aunque si insistes y pruebas al final puedes hacerlo funcionar en Windows 7) y punto pelota. Que maravilla, un aparato comprado hace pocos años que no funciona ni con Linux ni con Windows 8 y 10, vamos, que estos de Acer se han lucido con el soporte.

En esta páginaofrecen unos drivers/software para hacerlo funcionar en Windows 8 y 10. Parece un desarrollo propio de un programador al margen de Acer y al parecer hay que pagar algo, aunque el precio es bastante reducido (15$ es poco por poder seguir utilizando el aparato).

Para Linux, en cambio, tenemos a un héroe llamado Antonio Ospite (muy majo y atento que responde a cualquier consulta rápidamente) que estuvo sniffeando junto a Reto Schneider el tráfico USB windows-proyector y desensamblando el driver hasta poder hacer una librería y una aplicación en Linux que funciona perfectamente tal como funciona su equivalente Windows: el proyecto libam-7xxx, que soporta varios picoproyectores tales como:

• Acer Series C pico projectors (C20 C110 C112 C120)
• Philips/SagemCom PicoPix projectors (PPX 1020, PPX 1230, PPX 1430, PPX 1630)
• CEL-TEC MP-01
• Otros chinos

Para Ubuntu 16.04 es sencillo, instalamos estos paquetes desde repositorios:

ii  libam7xxx0.1                                 0.1.6-2                                    amd64        library for accessing am7xxx based devices
ii  libam7xxx0.1-bin                             0.1.6-2                                    amd64        library for accessing am7xxx devices - utilities
ii  usb-modeswitch                               2.2.5+repack0-1ubuntu1                     amd64        mode switching tool for controlling "flip flop" USB devices
ii  usb-modeswitch-data                          20151101-1                                 all          mode switching data for usb-modeswitch

Aquí tuve un pequeño problema un par de días: pinchaba el dispositivo y tras cierta una actividad de disco se quedaba todo quieto. Mirando con lsusb los dispositivos conectados no aparecía nada. Mirando el syslog se ve como se detecta algo, se prueban unos driver y al final todo acaba diciendo:

Jul 25 11:37:48 pc kernel: [ 5603.550891] option 1-8:2.0: device disconnected

Tras consultar con Antonio y sugerirme varias pruebas (desinstalar usb-modeswitch, quitar el módulo option de memoria, desinstalar libmtp-runtime) al final ha empezado a funcionar solo. Pienso que coincide con que he actualizado el kernel a 4.4.0-21-generic #37-Ubuntu, pero no estoy seguro.

Bueno, ahora pinchamos el dispositivo y haciendo lsusb debe aparecer primero como 1de1:1101 (dispositivo de almacenamiento, conteniendo los drivers de Windows XP) y en unos instantes usb-modeswich lo cambia a 1de1:5501, que es el proyector en si. Como no hay driver para él, no aparece ningún dispositivo que lo maneje. No importa, la aplicacion am7xxx-play envía directamente lo que le digamos por el puerto USB sin intermediarios, usando:

# am7xxx-play -f x11grab -i :0

Enviamos en tiempo real el contenido de la pantalla tal como lo hace EzDisplay. Si se mira la ayuda de am7xxx-play se verán opciones para modificar resolución, calidad, conexiones en tiempo real a otras fuentes de vídeo (cámaras, páginas web, etc). Vamos, una pequeña maravilla....¡gracias!.

Después de esto me he visto en la necesidad de usarlo en Ubuntu 14.04 con el problema de que no hay paquetes para ellos en repositorios. En https://ao2.it/debian/ hay varios paquetes compilados para Debian, pero ninguno acababa de encajar en el Ubuntu 14.04, siempre daban problemas con libavcodec5X y satélites (esos paquetes están relacionados con ffmpeg y continuamente dan problemas de compatibilidad con otras aplicaciones, parece ser que tienen un desarrollo fuertemente acoplado y cada versión es incompatible con el resto) ya que necesitaban unas versiones que no son las que trae Ubuntu 14.04 (libavcodec54 concretamente).

¿Solución?. Pues cómo en los viejos tiempos: vamos a compilar (y cumplimos la sentencia windowchista de que siempre estamos compilando los hijos de Linux). Antonio lo pone bastante sencillo: tenemos un repositorio git de donde solo hay que descargar y compilar. La última versión es la 0.1.6-2, pero es incompatible con Ubuntu 14.04. Para ahorrarme rollo ya digo que la última versión compatible es la 0.1.4-3, liberada hace 2 años.

Sin usar comandos git podemos descargarla directamente desde https://git.ao2.it/libam7xxx.git/commit/a49ffce85139aaf1fc2e2e79dd6c65ad7e7f523c en el enlace "snapshot".

Una vez descargado, descomprimimos el .tar.gz y seguimos los pasos del documento HACKING.asciidoc contenido en él:

 #cd libam7xxx-a49ffce
# aptitude install cmake libusb-1.0-0-dev libavformat-dev libavcodec-dev libavdevice-dev libswscale-dev
# mkdir build
# cd build
# cmake ../
# make 

Una vez hecha la compilación, en libam7xxx-a49ffce/build están los ejecutables y librerías. Podría hacer un paquete Debian para ellos, pero no, voy a instalar como en los viejos tiempos de Slackware:

 # make install

Con esto se copia todo a su sitio y si pinchamos el cañon en el USB ya podremos hacer:

# am7xxx-play -f x11grab -i :0

Una última nota: el fichero HACKING.asciidoc cuenta que es posible hacer funcionar am7xxx-play en Windows para que nos funcione allí aunque Acer no haya sacado drivers... ¿saben cómo? ¡Compilando!.

DRBL no live.

Carajo....¿dónde está el artículo original.....?. Pues ha crecido y lo he trasplantado aquí.

Problemas con la tarjeta wifi de un Notebook Inves Helio 1106L en Ubuntu

Esto me ha pasado varias veces y siempre tengo que buscar la solución porque no me acuerdo de una vez para otra, así que lo voy a dejar aquí para tenerlo a mano.

Uno de los modelos de portátiles que tenemos es un Inves Helio 1106L, que en realidad es un remarcado de un modelo genérico llamado "W310CZ/CZ-T". Cada vez que cargo un nuevo sistema, ya sea Debian, Ubuntu o Arch, me encuentro con que la conexión wifi es muy inestable y se cae cada poco tiempo.

La tarjeta wifi que trae es:

02:00.0 10ec:b723 Network controller: Realtek Semiconductor Co., Ltd. RTL8723BE PCIe Wireless Network Adapter 

Y la solución siempre ha sido la misma:

# cat /etc/modprobe.d/rtl8723be.conf 
options rtl8723be fwlps=0 swlps=0

Es decir, creamos o modificamos el fichero /etc/modprobe.d/rtl8723be.conf para que el módulo rtl8723be se cargue con el parámetro fwlps (linked fw control power save) desactivado.

Es curioso, peroeEste es un problema que nos está pasando con muchos modelos de portátiles en las aulas: el power save provoca desconexiones y contratiempos similares.

Grabación de video continuo en OpenWRT. Montemos una IP-Webcam barata - Reloaded II.

Seguimos con nuestro supertema de Webcams y Openwrt. Tratamos ahora un tema sugerido por Daniel, un lector del blog: ¿podemos grabar un vídeo continuo?.

Bueno, en principio si se puede siempre que tengamos en cuenta 2 limitaciones:

1) El vídeo debe guardarse fuera del dispositivo OpenWRT. En los 32 o 64MB que tienen estos aparatejos no hay sitio para vídeos. Se guardaría en una memoria USB o bien en un disco montado por red, tal como vimos en pasadas entregas de este tema.

2) Seguramente no tendremos muchas opciones de códecs disponibles para la grabación: ni OpenWRT implementa muchos ni el procesador MIPS que suele venir en los router domésticos tiene potencia para codificar en tiempo real.

Aclarados estos puntos vamos al lío:

# opkg update
# opkg install v4l-utils ffmpeg

Instalado el software, vamos a ver si nuestra webcam (conectada por usb, con los drivers adecuados y con /dev/video0 creado, tal como vimos en artículos anteriores) es compatible:

# v4l2-ctl --list-formats-ext
.....
.....

Debe salirnos una lista con los modos y resoluciones soportados con la cámara usando v4l2.

Ahora vamos grabar 300 segundos de vídeo en /mnt/videos/mivideo.avi (siendo /mnt/videos un espacio de almacenamiento externo):

# ffmpeg -y -f video4linux2 -c:v rawvideo -s 640x480 -i /dev/video0 -t 300 /mnt/videos/mivideo.avi

Ojo: si tenemos motion debemos pararlo, ya que este servicio bloquea /dev/video0 y no deja a ffmpeg funcionar. Una vez grabado el corte podemos verlo en el PC mediante VLC o similar. Será un vídeo con calidad y/o fluidez variable en función de las capacidades del router y la configuración que le hayamos puesto a ffmpeg.

Con esto podemos llamar a ffmpeg con un script, con un servicio como hicimos con motion, con un crontab, etc. Si es conveniente no grabar un vídeo continuo, sino hacer tracks de X minutos.

Bueno nos vamos, pero mantengan la calma ya que nosotros volveremos.

Poner lista blanca de MAC permitidas en un router con DD-WRT

Nos han llegado unos router-puntos de acceso con DD-WRT, el "hermano rico" de OpenWRT. Tenía que meter una lista de 24 MACs de portátiles para el filtro desde el interface web cuando enseguida me di cuenta de que era una lata. Cuando tengo que hacer la misma cosa mas de 4 o 5 veces salta un trigger que me dice al oído: "esto se tiene que automatizar de alguna manera".

Y claro que si se puede. Primero hay que recolectar la lista de MACs, que en mi caso ya estaban en el fichero hostapd.accept del demonio /etc/hostapd, y ponerlos como una serie de direcciones MAC separadadas por espacios en blanco:

# cat /etc/hostapd/hostapd.accept | tr '\n' ' '
AA:BB:CC:DD:EE:FF 00:11:22:33:44:55:66 .....

Segundo, conectamos por ssh con nuestro router Dlink-860L y tecleamos (la parte de las MACs se corta y pega, por supuesto):

# nvram set wl0_maclist=”AA:BB:CC:DD:EE:FF 00:11:22:33:44:55:66 .....”
# nvram set wl0_macmode1=other
# nvram set wl0_macmode=allow
# nvram commit
# reboot

Y ya está, luego podemos verificarlo con:

# nvram show | grep wl0_maclist

En general, con nvram show vemos las opciones de configuración y con nvram set/commit las cambiamos. De esta manera podemos hacer por comandos (incluso remotamente usando ssh+sshpass o ssh+relación de confianza) muchas tareas sobre el router. A fin de cuentas recordemos que los xxx-WRT son una versión más de Linux.

Addenda: un compañero me comenta que la linea de shell de DD-WRT tiene un límite y pasado dicho límite no se pueden poner mas MACs (el ĺímite son 55 direcciones). Buscando he encontrado esta forma alternativa de hacerlo:

# nvram set wl0_maclist="`cat wl0_maclist.list`"

Siendo wl0_maclist.list un fichero donde hemos puesto las MACs. Teóricamente se aceptan hasta 256. El compañero Luis Delgado me ha confirmado que funciona y ha añadido las dobles comillas...¡gracias!.

Re-Addenda: avisa el compañero Miguel Núñez de que faltaba el "nvram set wl0_macmode=allow" para indicar que la lista de MACs es lista blanca (allow), es decir, la lista contiene las MACs que tienen permitida la conexión. Los posibles valores son disabled/allow/deny. ¡Gracias!.

2x1: multiseat en las aulas (Parte II)

Bueno, seguimos con nuestro multiseat, para evitar que los ciclos de reloj de un PC sobredimensionado para un único usuario se pierdan como lágrimas en la lluvia, ahí es nada. Continuamos usando diferentes fuentes, como ésta para Ubuntu 14.10, ésta de los dobleplusútiles wikis de Arch y ésta para Ubuntu 14.04.

1. Asignación de dispositivos a otro seat.

Como dijimos, en principio todo está asociado a seat0. Lo que tenemos que hacer para cambiar esto es asignar al menos un teclado, ratón y VGA a otro seat. Para ello usamos el comando "loginctl attach" como vemos a continuación:

# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1c.0/0000:05:00.0/drm/card1"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1c.0/0000:05:00.0/graphics/fb1"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.0/0003:046D:C316.0008/input/input22"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/0003:0458:003A.000A/input/input24"
# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1d.0/usb6/6-2/6-2:1.1/0003:046D:C316.0009/input/input23"

Creamos un nuevo seat, el seat-1 (se denominan asi: seat0, seat-1, seat-2,...., el primero no lleva el guión) al que le signamos durante su creación la siguiente tarjeta VGA (ver entrada anterior):

05:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 LE] (rev a1)

Y el teclado y ratón:

Bus 006 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard
Bus 006 Device 002: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120

Lo importante es tener claro la denominación "/sys/devices...." de cada elemento de hardware, tal como contamos en la entrada anterior.

Al teclear estos comandos conseguimos 2 interesantes efectos:

1) Esos dispositivos se desvinculan de seat0 y se asocian al naciente seat-1.
2) En /etc/udev/rules.d/.... se crean automáticamente los ficheros .rules para realizar esta asociación en cada reinicio del sistema. Si miras dentro verás que son ficheros bastante crípticos, afortunadamente "loginctl attach" ha hecho el trabajo por nosotros.

Una vez hecho esto, si reiniciamos con un segundo monitor conectado a la la salida VGA de la nvidia GeForce nos aparecerán dos pantallas de login independientes (recordemos que en lightdm.conf habíamos habilitado el soporte multiseat, de tal forma que es capaz de iniciar 2 sesiones a la vez, una asociada a seat0 y otra a seat-1), una en cada monitor y cada una controlada por su teclado y ratón. Podremos iniciar dos sesiones autónomas y ejecutar cualquier programa con fluidez. Ya tenemos 2 PC dónde solo había uno, misión cumplida.

Una fotino para ver como queda:

Más cerca:

Si queremos desasociar los dispositivos y vaporizar el multiseat hacemos:

# loginctl flush-devices

O bien borramos a mano todos los ficheros creados antes en /etc/udev/rules.d/....

2. Tarjetas de sonido.

Una vez tenemos funcionando nuestro multiseat y vemos que todo se mueve con alegría y ligereza, incluída la reproducción de vídeo, la siguiente inquietud que nos entra en el cuerpo es el tema del sonido. ¿Como va eso? ¿Podemos lograr que ambos seat interpreten un dueto?

En los Linux de nuestro tiempo el sonido se controla con pulseaudio, que es un servicio que se ejecuta normalmente en modo per-user, al iniciar sesión el usuario y accede al hardware de sonido. En un sistema multiseat hay dos ejecutables de pulseaudio campando en el sistema y compitiendo por el acceso al hardware. ¿Que significa esto?, pues que el comportamiento es errático: unas veces se reproduce el sonido del seat0, otras la del seat-1 y otras se interbloquean y no suena nada.

Para evitar esto hay dos soluciones: la primera (ver aquí el apartado "the sound challenge"), que no he probado pero no debería dar problemas es pinchar una segunda tarjeta de sonido al PC y asociarla a seat-1 con "loginctl attach". A esta tarjeta se asociará el pulseaudio del seat-1 y por su salida saldrá el sonido propio. Ojo al dato: en el artículo anterior vimos que había 2 tarjetas de sonido en nuestro PC, pero solo una de ellas es una tarjeta analógica normal a la que puedes conectar unos altavoces, la otra es la tarjeta de sonido HDMI vinculada a la VGA. Para oir eso necesitamos un monitor con sonido digital (o una TV) o algún tipo de altavoz con entrada HDMI. Si no tenemos eso, habría que pinchar otra tarjeta analógica sin remisión.

La segunda solución, que me ha funcionado de forma parcial, es ejecutar pulseaudio como daemon en modo system-wide. De esta manera hay una sola instancia de pulseaudio y las sesiones se conectan a ella, reproduciendo el sonido sin problema ya que pulseaudio hace la mezcla y así conseguimos tener duetos con la unión de ambas fuentes de sonido, una desde cada seat.

Para arrancar pulseaudio en modo system-wide no hay mucha información ya que esta desaconsejado, pero en este enlace está documentado. Básicamente, hay que editar estos ficheros:

• /etc/pulse/daemon.conf: poner 'deamonize = yes' y 'system-instance= yes'
• /etc/pulse/client.conf: descomentar 'autospawn = yes' y 'daemon-binary = /usr/bin/pulseaudio'
• /etc/default/pulseaudio: en mi Ubuntu me manda al siguiente fichero, dice que está obsoleto
• /etc/init/pulseaudio.conf: descomentar la linea del 'start ...'
• /etc/security/groups.conf: añadir el grupo 'pulse-access' a la lista de grupos por defecto de todo usuario que inicia sesión en la máquina (la famosa línea *; *; *; Al0000-2400;audio,cdrom,floppy,plugdev,video,fuse.... ).

Reiniciamos y si todo va bien veremos una sola instancia de pulseaudio ejecutada con propietario "pulse" desde antes de comenzar cualquier sesión de usuario. Esa instancia maneja y mezcla el sonido de ambos seat con una gracia que ni el Dueto de las Flores de Lakme.... o no. En mi caso solo ha funcionado cuando ambos usuarios eran usuarios con su home local en la máquina. Cuando es un usuario cuyo home está en un servidor nfs, el sonido de su sesión no puede llegar hasta demonio pulseaudio y no se oye nada. Es un problema recurrente si buscamos en Internet (pulseaudio+nfs home) al que no he encontrado solución. Sospecho que el usuario "pulse" intenta hacer algo en el home y al ser un usuario local sin permisos sobre ese recurso de red, no llega a poder hacer lo que carajos tenga que hacer allí.

Hay varias propuestas de soluciones en Internet, mas o menos enfocadas a hacer que se guarden datos de pulseaudio en local en lugar de en la carpeta remota, pero ninguna me ha funcionado, por ejemplo, poner:

PULSE_DIR="/tmp/$USER-pulse"
mkdir -p $PULSE_DIR && chmod 700 $PULSE_DIR
export PULSE_CONFIG_PATH=$PULSE_DIR
export PULSE_STATE_PATH=$PULSE_DIR
export PULSE_RUNTIME_PATH=$PULSE_DIR

tanto en /etc/X11/Xsession.d/.. como en /etc/profile y .bash_profile, pero no he tenido éxito. Por tanto, en tanto en cuanto no encontremos una solución, si queremos hacer funcionar el sonido de forma independiente hay 2 opciones: o usamos 2 tarjetas de sonido o compartimos la misma pero estamos restringidos a usuarios con el home local.

3. Almacenamiento externo.

Siguiente cuestión: al pinchar un pendrive se monta en seat0, ya que los puertos USB están asociados todos a dicho seat. Lo que se aconseja es poner un hub usb sobre un puerto determinado.

y hacer un attach del mismo a seat-1. De esta forma todo lo que se pinche sobre dicho hub se asociará a ese seat. En mi caso el hub era:

Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub

Tras mirar en el listado del "loginctl seat-status" vemos que hay que asociarlo así:

# loginctl attach seat-1 "/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3"

Esto nos creará, como los otros attach, la regla udev que asocia al seat-1 el hub usb. Cualquier cosa pinchada en dicho hub saltará en seat-1, por ejemplo: un pendrive se montará en dicho escritorio. Lo único que tenemos que quedar claro al usuario de cada seat es como va asociado cada puerto usb con su puesto fisico, para que puedan pinchar en el agujero correcto.

4. Cosas pendientes.

Lo único que creo que me queda pendiente (aparte del sonido en los home nfs, que no me quita especialmente el sueño) es conseguir todo lo anterior con una sola tarjeta de vídeo con 2 salidas (las típicas VGA y DVI), de tal manera que cada seat use una de ellas y nos ahorremos tener que adquirir una tarjeta independiente.

Es lo que se conoce como "multiseat single-gpu". Aunque se ha conseguido en el pasado, usando Xephyr y/o Xnest, lo cierto es que parece complicado, ya que se basa en arrancar una sola instancia de las X, dentro dos X anidadas (con Xephyr/Xnest) y abrir una sesión independiente en cada una de ellas. La teoría es fácil, pero hay que hacerlo. Dejo aquí enlaces con las vías de investigación abiertas, como diría el ex-ministro Acebes:

• En general, los mensajes de Laércio de Sousa en https://www.mail-archive.com/ubuntu-multiseat@lists.launchpad.net/index.html. Él parece tener la clave, lo que pasa es que no acaba de ponerse a documentarlo.
• Su ppa: https://launchpad.net/~lbssousa/+ppa-packages
• https://www.phoronix.com/scan.php?page=news_item&px=Xephyr-7-GPU-Multi-Seat
• En ruso, nada complicado para los acostumbrados a estupendos foros de 4pda.ru: http://www.linux.org.ru/forum/general/12245315. Recuerda llevar una botella de vodka.
• https://www.mail-archive.com/ubuntu-multiseat@lists.launchpad.net/msg00200.html
• https://bbs.archlinux.org/viewtopic.php?id=209727
• http://beforeafterx.blogspot.com.es/2011/02/multiseat-setup.html
• http://unix.stackexchange.com/questions/183960/multiseat-with-one-card-and-two-xorg-instance

Otra fuente de información e incluso scripts que hacen mas sencillo el proceso de los "attach" es el proyecto multiseat-wizard-bicéfalo. Es una pena que parase en Ubuntu 12.04, pero seguro que es un código a estudiar y tener en cuenta.

Espero que haya tercera parte con la solución de este último tema antes de que tengamos nuevo gobierno....allá por 2018.

2x1: multiseat en las aulas (Parte I)

Tengo algunos equipos con tanta potencia y memoria de sobra que da vergüenza ponerlos como PC para un único usuario. Podría utilizarlos como hasta ahora, con servidores LTSP o bien servidores x2go, pero eso ya está hecho y había que rizar el rizo.

Mi compañero del IES Bembézar me había hablado de multiseat, gracias al cual podemos convertir 1 PC en dos (o cuatro, o n) puestos de usuario conectando 2 monitores, 2 teclados y 2 ratones = 2 "seat". 2x1. ¿Sería fácil de montar con Xubuntu 14.04?, pues me puse manos a la obra para comprobarlo.

Me he guiado principalmente por esta página de Ubuntu, aunque la mayoría de información viene de posts de foros y preguntas en stackoverflow y sitios similares....

1. Hardware que necesitamos.

Nos hacen falta 1 PC, 2 teclados, 2 ratones y 2 monitores. Para esta implementación, que es la mas sencilla y rápida, también necesitamos que en el PC haya 2 tarjetas VGA, una para cada "seat".

Si queremos que haya sonido independiente en cada seat debemos tener también 2 tarjetas de sonido. Por supuesto los periféricos deben ser compatibles con los conectores que tenga nuestro PC: no podemos poner 2 teclados PS2 si solo hay una salida PS2, claro está. Ídem para los monitores: usaremos cables y conectores VGA, DVI, HDMI, etc en función de lo que haya.

2. Preparando el entorno.

Bueno, pues para preparar esto tenemos que empezar añadiendo un repositorio ppa:

# sudo add-apt-repository ppa:ubuntu-multiseat/ppa

Que nos añadirá:

# cat /etc/apt/sources.listd.d/ubuntu-multiseat-ppa-trusty.list 
deb http://ppa.launchpad.net/ubuntu-multiseat/ppa/ubuntu trusty main
# deb-src http://ppa.launchpad.net/ubuntu-multiseat/ppa/ubuntu trusty main

Y actualizamos los paquetes, especialmente los relaciones con las X para soporte multiseat :

# sudo apt-get update
# sudo apt-get upgrade

Tambien hay que editar

# cat /etc/lightdm/lightdm.conf
[LightDM]
logind-load-seats=true

Para que lightdm reconozca la configuración de los seat y abra una sesión en cada monitor, con todo el hardware asociado.

Tampoco viene mal quitar el paquete light-locker. Hemos observado que produce pantallas en negro y bloqueos especialmente en el seat secundario. Si tenemos pkgsync lo mejor es ponerlo en maynothave.

3. Comandos básicos.

Antiguamente la configuración era mas pedestre, editando a mano fichero en /etc/udev/rules.d para asignar el hardware a los distintos dispositivos. Ahora es mas sencillo, primero veremos cómo listar los seat configurados:

 # loginctl list-seats
SEAT            
seat0           

1 seats listed.

Como se ve, por defecto solo hay un seat, el seat0. Todos los dispositivos están asociados a él, vamos a listarlos. El comando para listar los dispositivos asociados a un seat determinado es (los colores son aportación mía para identificar los componentes mejor, ojo: esto es mi máquina, en la tuya saldrán otras cosas):

 # loginctl seat-status seat0
seat0
Sessions: *c2 c1
 Devices:
   ├─/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1
   │ input:input1 "Power Button"
   ├─/sys/device...XSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0
   │ input:input0 "Power Button"
   ├─/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
   │ drm:card0
   ├─/sys/device...0:00/0000:00:01.0/0000:01:00.0/drm/renderD128
   │ drm:renderD128
   ├─/sys/device...000:00/0000:00:01.0/0000:01:00.0/graphics/fb0
   │ [MASTER] graphics:fb0 "radeondrmfb"
   ├─/sys/device...0000:00/0000:00:01.0/0000:01:00.1/sound/card1
   │ sound:card1 "HDMI"
   │ └─/sys/device...000:00:01.0/0000:01:00.1/sound/card1/input7
   │   input:input7 "HDA ATI HDMI HDMI/DP,pcm=3"
   ├─/sys/devices/pci0000:00/0000:00:1a.0/usb3
   │ usb:usb3
   ├─/sys/devices/pci0000:00/0000:00:1a.1/usb4
   │ usb:usb4
   ├─/sys/devices/pci0000:00/0000:00:1a.2/usb5
   │ usb:usb5
   ├─/sys/devices/pci0000:00/0000:00:1a.7/usb1
   │ usb:usb1
   │ └─/sys/devices/pci0000:00/0000:00:1a.7/usb1/1-3
   │   usb:1-3
   ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0
   │ sound:card0 "Intel"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input10
   │ │ input:input10 "HDA Intel Line"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input11
   │ │ input:input11 "HDA Intel Line Out Front"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input12
   │ │ input:input12 "HDA Intel Line Out Surround"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input13
   │ │ input:input13 "HDA Intel Line Out CLFE"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/soundosdosd/card0/input14
   │ │ input:input14 "HDA Intel Line Out Side"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input15
   │ │ input:input15 "HDA Intel Front Headphone"
   │ ├─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input8
   │ │ input:input8 "HDA Intel Front Mic"
   │ └─/sys/devices/pci0000:00/0000:00:1b.0/sound/card0/input9
   │   input:input9 "HDA Intel Rear Mic"
   ├─/sys/devices/pci0000:00/0000:00:1c.0/0000:05:00.0/drm/card1
   │ drm:card1
   ├─/sys/device...0:00/0000:00:1c.0/0000:05:00.0/drm/renderD129
   │ drm:renderD129
   ├─/sys/device...000:00/0000:00:1c.0/0000:05:00.0/graphics/fb1
   │ [MASTER] graphics:fb1 "nouveaufb"
   ├─/sys/devices/pci0000:00/0000:00:1d.0/usb6
   │ usb:usb6
   │ ├─/sys/device...-1/6-1:1.0/0003:0458:003A.0001/input/input3
   │ │ input:input3 "Genius Optical Mouse"
   │ ├─/sys/device...-2/6-2:1.0/0003:046D:C316.0003/input/input5
   │ │ input:input5 "Logitech Logitech USB Keyboard"
   │ └─/sys/device...-2/6-2:1.1/0003:046D:C316.0004/input/input6
   │   input:input6 "Logitech Lde configuraciónogitech USB Keyboard"
   ├─/sys/devices/pci0000:00/0000:00:1d.1/usb7
   │ usb:usb7
   ├─/sys/devices/pci0000:00/0000:00:1d.2/usb8
   │ usb:usb8
   │ └─/sys/device...-1/8-1:1.0/0003:0458:003A.0002/input/input4
   │   input:input4 "Genius Optical Mouse"
   ├─/sys/devices/pci0000:00/0000:00:1d.7/usb2
   │ usb:usb2
   ├─/sys/device...1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sr0
   │ block:sr0
   ├─/sys/device...a2/host1/target1:0:0/1:0:0:0/scsi_generic/sg1
   │ scsi_generic:sg1
   ├─/sys/devices/platform/i8042/serio0/input/input2
   │ input:input2 "AT Translated Set 2 keyboard"
   └─/sys/devices/virtual/misc/kvm
     misc:kvm

Los colores (recordemos: puestos por mi a mano para que quede clarito) tienen el siguiente significado:

• Rojo: ratones. 
• Verde: teclados. 
• Azul: hub usb externo.
• Naranja: tarjetas VGA.
• Morado: tarjetas sonido.

Bueno, pues ahi estan las tarjetas gráficas, teclados, ratones, botones de todo tipo (el de apagado, reset, etc), puertos usb y tarjetas de sonido asociados al seat.

Veamos el hardware con el que estoy trabajando en mi caso (nótese que el teclado PS2 no sale ya que ni lsusb ni lspci lo muestran):

# lsusb
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 008 Device 002: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 003: ID 046d:c316 Logitech, Inc. HID-Compliant Keyboard
Bus 006 Device 002: ID 0458:003a KYE Systems Corp. (Mouse Systems) NetScroll+ Mini Traveler / Genius NetScroll 120
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 003: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 002: ID 05e3:0716 Genesys Logic, Inc. USB 2.0 Multislot Card Reader/Writer
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
# lspci | grep -i vga
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620 LE [Radeon HD 3450]
05:00.0 VGA compatible controller: NVIDIA Corporation G72 [GeForce 7300 LE] (rev a1)
# lspci | grep -i audiodos
00:1b.0 Audio device: Intel Corporation 82801JI (ICH10 Family) HD Audio Controller
01:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] RV620 HDMI Audio [Radeon HD 3400 Series]

Como se puede apreciar, para mi PC yo tengo 2 teclados (1 USB y 1 PS2), 2 ratones (ambos USB), 2 tarjetas VGA y HUB externo USB conectados al puesto donde voy a configurar el multiseat.

En el caso de que no identifiquemos algun dispositivo en la aparatosa lista que muestra seat-status, podemos probar a desconectarlo y hacer un:

 # loginctl seat-status seat0 > antes.txt

Luego conectarlo y otra vez:

# loginctl seat-status seat0 > despues.txt
# diff antes.txt despues.txt

Y así en las diferencias entre ambos ficheros veremos la parte que describe dicho dispositivo.

Antes de seguir en el siguiente post debemos analizar tranquilamente la información que nos da nuestro hardware particular y tener claro qué es cada dispositivo y como vamos a repartirlo entre los ambos seat, dejando algunos en seat0 y moviendo otros a seat-1.

Seguimos en breve en otro post...

Printer Wars III: Oh, Brother!

"Oh, Brother!", divertida película de los hermanos Cohen y divertida peripecia que he tenido con el servicio técnico de esa marca de impresoras.

1) El problema.

El centro compró una impresora Brother DCP-9020-CDW hace mas de un año. Es una impresora láser color multifunción que cumplía nuestros requisitos:

• Precio ajustado de impresora y repuestos de tóner compatible (las directivas de la UE no obligan, pero si recomiendan a las administraciones públicas usar tóner y tinta compatible. A fin de cuentas jugamos con el dinero de todos).
• Características ajustadas a nuestras necesidades.
• Buen soporte para Linux.
• La confianza de la marca Brother, que viene haciendo impresoras desde tiempos inmemoriales.

Bueno, pues tras funcionar bien durante varios meses usando cartuchos de tóner compatibles de repente empezó a dejar una arruga con aspecto de "grabado" en el papel al imprimir. No era una mancha, era un "bajorelieve" que deformaba el papel con un patrón periódico cada 4 o 5 cm. Las hojas impresas quedaban poco presentables con dicho defecto.

Puestos al habla con el servicio técnico de Brother me dicen como acceder al fusor para ver si veo algo sospechoso, ya que la avería proviene de allí con toda seguridad, en la misma llamada y de forma sibilina me dan indicaciones para averiguar si tengo tóner compatible u original. Esto último podrían haberlo preguntado directamente, no tengo nada que ocultar.

Siguiendo sus instrucciones, en el fusor veo que uno de los rodillos rodeado por un film negro ( el "heat roller") tiene partes de dicho film quitadas y deformadas, siendo esa deformidad la que causa el "grabado" en el papel. Bien, es una avería y estamos en garantía, vamos a tramitarla. Empieza lo bueno:

1. Me dicen que para que el taller recepcione la impresora debe ir con tóner original de Brother. En caso contrario por sistema se achaca la avería al tóner compatible.
2. Que para darme instrucciones para la recogida debo mandar por fax una factura con la compra del tóner original adquirido ex-profeso para la ocasión. Si no la mando, no me dan ninguna información sobre como proceder.
3. Un juego de tóneres originales cuesta casi tanto como una impresora nueva.
4. No me pueden asegurar que la garantía cubra la avería, después de todo podría ser por una mala actuación de algún usuario
5. Recuerdo que el tóner que venía con la impresora, el llamado "kit de inicio", lo guardamos al poco tiempo de llegar. Estaba al 80%. Lo pongo y contacto con ellos para decir que la envío con ese tóner original. Me responden que no les vale el "kit de inicio", debo comprar tóner nuevo o no hay tutía.
6. Les planteo contactar con otro centro que tenga la misma impresora y, en el caso de tener juegos de tóner original, me los prestase para gestionar la garantía. No, debo comprar tóner nuevo y enviar la factura, no hay otra opción. Esta última llamada es bastante tensa ya que Magdalena, la persona que me atendió, me recuerda que ella hace su trabajo y yo la recuerdo que yo hago el mío, que entre otras muchas cosas es conseguir una Administración mas eficiente técnica y económicamente, ya que ese tóner que quieren obligarme comprar se va a pagar con sus impuestos y los míos. Esa afirmación debe ser bastante violenta para ella, ya que en ese punto se despide y me cuelga el teléfono.
7. En resumen: Brother solo gestiona las garantías si pasas por caja previamente y compras tóner original (les da igual el establecimiento) y les envías la factura. Otro caso más en que una empresa no parece de vivir de fabricar impresoras, sino de vender los consumibles para las mismas. Adiós, Brother.

Bueno, he desmontado el fusor y esto se ve:

Mas cerca, el "heat roller" con el recubrimiento negro todo arrugado y deformado:

Es curioso, los rodillos de goma inferiores tienen pinta de estar erosionados:

Desde luego, ni eso ni lo otro tiene pinta de ser causado por un tóner no original.

2) Buscando mas damnificados.

Investigando estos días en Internet descubro que esto no es nuevo ni soy el primero: vean este enlace, donde aparte de describir mi problema con la misma impresora en distintas partes del mundo, dicen:

Well full marks to Brother. Customer services gave usual story of being out of guarantee and gave me the number of local service engineer but did say I should contact Brothers complaints dept. Emailed complaints who responded within the hour. I the sent them photo of the mark on the Fuser roller and the usage printout. Next reply was that they would carry out a free home inspection. The Service Company came out in a couple of days with a new unit. All now working OK and most important, no charge. Just hoping that this one will last and they have upgraded the part(wishful thinking maybe).
-------------------------
Hi! Brother service here in Sweden just replaced my fuser unit (guarantee, half a year, 1100 printed pages). It seems to be a well-known problem. Mechanical marks/tracks down the page, typically on the left-hand side of the paper. I asked if I will need to replace it twice a year in the future. He answered vaguely that software updates and general product development might fix it in the future. Luckily, I have 3 years guarantee...

Es decir, el problema es conocido por Brother y lo están arreglando de forma gratuita a esa gente de USA y Suecia. Incluso dicen:

If I visit the Brother DCP-9020CDW Support and Downloads Page (English, EU page), I get a pop-up tab on the bottom stating "For optimum performance of your printer, perform an update to the latest firmware. This may help to prevent paper wrinkle or smudge printing." This sounds like some of the issues people have been having in this thread. The firmware date and version is 23/12/2015, (T/1.07/M). Does this help anyone, or been there, done that, didn't work?

3) Investigando.

¿Será cierto eso?, pues parece que si:

Es decir, que recomiendan un nuevo firmware para prevenir el "paper wrinkle" y "smudge printing", con lo cual implícitamente reconocen que es un problema suyo. En Brother España dicen:

Nótese el Lost in translation (estupenda película): en la versión inglesa, el "prevent paper wrinkle" se traduce a "mejorar la alimentación del papel". Google Translate me lo traduce por "prevenir las arrugas de papel": carajo, justo lo que me pasaba a mi. Alguien está engañando a alguien.

Recalco que no es un aviso genérico: sólo sale con este modelo de impresora. Buscando un poco más encuentro otro comentario en Amazon:

Toma ya, les han reemplazado 3 fusores gratis, uno de ellos fuera de garantía. Ya no me hace falta buscar más.

4) La conclusión.

Meanwhile, aquí en Hispanistán me han confirmado por teléfono esta misma mañana otra vez que debo gastar 280 euros en tóner original para que ellos me solucionen (o no) un problema reconocido de sus impresoras defectuosas. Spain is different.

Bueno, pues mientras que decidimos que hacer (al ser una Admnistración Pública no podemos demandar como consumidores a Brother, deberíamos ir por la via judicial, cosa que tampoco merece la pena) solo puedo quedarme con dos moralejas:

1. Nunca sabremos que pasó a la impresora, ya que Brother no llegará a examinarla, aunque siempre sospecharemos que es un fallo del firmware en el que Brother España elude su responsabilidad.
2. Nunca más Brother, ni comprar ni recomendar su uso. No me parece ético comprar a empresas que recurren al chantaje y al abuso de poder para forzarte a que adquieras sus consumibles, mientras se niegan a arreglar un defecto reconocido por ellos mismos.

Oh, Brother:



Adenda 8-Enero-2018: me llega este post del foro https://www.printerforums.net:

Atomic Shrimp:

I've had this problem on two different examples of this printer (one at home, one at work) - in the most recent case - actually I suspect both cases - the damage seemed to happen after the printer was left waiting for paper.

Someone printed a job that required more paper than was in the tray - the printer sat there saying 'add paper' with a fan running for hours; the printer is in a different room, so nobody noticed - and I think the fuser unit was being kept hot all of this time, softening or melting the plastic on the roller.

I wonder if more recent firmware might manage the power for the fuser unit more intelligently in the case that a job is interrupted midway due to supplies running out. If not, the workaround for me is to make sure that any time you print anything, you attend the printer promptly to ensure it finished and that the printer has gone back to sleep.

Según parece ser, el firmware original tiene un problema: si la impresora se queda sin papel sin que nadie se de cuenta, el fusor se queda caliente de forma indefinida, fundiéndose el plástico del roller. El firmware mas reciente apaga el calentador del fusor cuando lleva un rato parado sin que entre mas papel en la alimentación. Es una pena que haya sido un tercero y no Brother quien reconozca este fallo. Estoy casi seguro de que eso me pasó a mi: quedó algo pendiente de imprimir una tarde o un fin de semana y así continuó hasta que se fundió el plástico.

Problemas diversos con las X y GRUB_CMDLINE _LINUX_DEFAULT en Ubuntu 14.04

Estos días he tenido varios problemas con un par de tarjetas VGA y el Ubuntu 14.04 que estamos instalando. Como me ha costado un rato de Google encontrar la solución pongo las recetas para tenerlas a mano.

En primer caso es una:

00:02.0 VGA compatible controller [0300]: Intel Corporation Sky Lake Integrated Graphics [8086:1912] (rev 06)

que se encuentra en los equipos que llamamos "infolab".

Inicialmente el driver "intel" funcionaba bien, pero tras varios días de uso me encontré con que aleatoriamente se cerraba sesión (sobre todo con Flash Player), unas ventanas se superponían con otras o bien se quedaban con rectángulos negros sin refrescar. Haciendo pruebas encontré que configurando aceleración "uxa" se solucionaba el problema:

 # cat /etc/X11/xorg.conf 
Section "ServerLayout"
.....
.....

Section "Device"
        .....
        .....
 Option "AccelMethod" "uxa"
 Identifier  "Card0"
 Driver      "intel"
 BusID       "PCI:0:2:0"
        .....
        .....


EndSection

.....
.....
EndSection

¿Solucionado del todo?. Pues no: al encender el PC el cursor del ratón se volvía "invisible" y podías moverlo y hacer click sin verlo. Si iniciaba sesión y salía de la misma (a ciegas), al cargar el nuevo el lightdm ya si se hacía visible. Desde luego eso no es operativo. Buscando y buscando encontré la solucion: editar /etc/default/grub quitar 'quiet splash' de GRUB_CMDLINE_LINUX_DEFAULT, quedando:

GRUB_CMDLINE_LINUX_DEFAULT=""

No hay que olvidar luego hacer:

# update-grub2

Realmente lo que hace esto es que la carga del sistema no muestre la pantalla bonita en modo gráfico y salga el tradicional listado de texto estilo "matrix". Es decir, que la configuración gráfica no se hace hasta la carga de las X. Y con eso solucioné el primer problema.

El segundo era con unas antiguas tarjetas VGA:

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation G72 [GeForce 7300 LE] [10de:01d1] (rev a1)

En este caso los drivers nouveau y nvidia quedaban la pantalla completamente negra. El nvidia además de regalo mantenía las xorg por encima del 90% de CPU. Probé varias versiones del driver propietario (nvidia-173, nvidia-304, descarga directa de nvidia.com) y de distintos ppa sin éxito.

El driver VESA, que se carga por defecto blacklistando los módulos nouveau y nvidia, no daba problemas pero su rendimiento es escaso y la reproducción de vídeo no era nada fluída. Después de buscar y buscar (y probar sin éxito la solución anterior) encontré una referencia a poner "nomodeset" en GRUB_CMDLINE_LINUX_DEFAULT y ¡voilá!... empezó a funcionar con nouveau. El resultado es tan fluído que ni he intentado probar con nvidia.

Realmente, lo que hace nomodeset es no intentar configurar la resolución y frecuencias de pantalla durante la carga del kernel, dejando eso para cuando se carguen las X.

Y ahí queda eso, al final ha sido mas fácil que intentar formar gobierno el 27 de junio.

Montemos una IP-Webcam barata - Reloaded I.

Esto es un sinfín. Reconozco que esta entrada y sus predecesoras han tenido mucho éxito gracias a la llegada de gente desde el estupendo foro de Openwrt de SeguridadWireless y, como tengo en producción el sistema desde que escribí el primer post, sigo con ello realizando retoques y mejoras con cierta frecuencia.

La último ha sido unos problemas derivados de la caída del servidor donde se almacenan las capturas. Como ya vimos es un servidor remoto desde el que montamos una carpeta por sshfs. He tenido diversos problemas con dicho servidor e inoportunas caídas del servicio. Los problemas detectados son:

1. Cuando se interrumpe la conexión sshfs ya no se recupera hasta que se reinicia el router. Ese reinicio lo tengo programado una vez al día a medianoche.
2. Si se interrumpe la conexión el guardado de las imágenes se hace en /mnt local, con lo cual los pocos megas de espacio de almacenamiento interno del router se llenan rápidamente y dejan el OpenWrt malfuncionando. Al reiniciar el router ese espacio se libera borrando las capturas.
3. En general, las capturas hechas durante el tiempo que está el sshfs caído se pierden como lágrimas en la lluvia, ya que muchas veces no se llegan a enviar por problemas derivados del llenado del almacenamiento interno.

Para evitar estos problemas he implementado cambios orientados a detectar que no está montado el sshfs, intentar remontarlo y, si no se puede, adaptarnos a esta situación. En líneas generales:

1. He ordenado un poco el código creando varias funciones, sacando al programita de los años 50 del siglo pasado.
2. He creado un fichero local llamado /mnt/testigo que solo será visible si el sistema remoto no está montado por sshfs.
3. Al principio pregunto si el sistema sshfs está montado y en caso negativo intento re-montarlo.
4. Si no hay manera de remontarlo y no hay movimiento detectado, el fichero con la imagen *snapshot* no se almacena en la memoria interna: se borra.
5. Si no hay manera de remontarlo y hay movimiento detectado, los ficheros con la secuencia son guardados en el espacio de almacenamiento interno de forma local y, cuando llegan a ser 10, empaquetados y enviados por correo, borrándose luego. El "10" es un número arbitrario que cada cual puede variar para ajustarlo a su espacio de almacenamiento

Y ya está, veamos el código:

# cat /root/controlador.sh 
#!/bin/ash

log() {
   test $montado -eq 1 && echo "$1" >> /mnt/snapshot/log.txt  
}

email() {
   test $email -eq 1 && echo -e "$1" | sendmail correo.aviso@gmail.com
}

monta_sshfs() {
  sshfs -o ssh_command="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" -o nonempty openwrt@192.168.0.25:/home/openwrt /mnt
}

envia_secuencia() {

   if [ -e /tmp/motion.txt ]
   then

      #Recopila todos los ficheros de /tmp/motion/txt y los envia en un correo

      ficheros=$(cat /tmp/motion.txt | tr '\n' ' ')
      rm /tmp/motion.txt

      log "Historia de capturas $ficheros"
      zip -9 /mnt/escena.zip $ficheros

      echo "Secuencia $1" > /mnt/mensaje.txt
      test $email -eq 1 && mutt -s "Evento camara" correo.aviso@gmail.com -a /mnt/escena.zip < /mnt/mensaje.txt

      rm /mnt/escena.zip
      #Si no hay acceso al almacenamiento remoto, borramos las capturas para no llenar el disco del router.

      test $montado -eq 0 && rm -rf $destino

   fi

}

#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"
montado=1
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

#Si existe el fichero /mnt/testigo no se ha montado directorio remoto por sshfs,
#Intentamos montarlo y otra vez y luego preguntamos de nuevo.
#Si no se ha montado nada es que no se puede guardar nada de forma permanente ya que estamos escribiendo en la
#memoria interna del router y eso se llena rapido

test -e /mnt/testigo || monta_sshfs

if test -e /mnt/testigo
then
   montado=0
   #No hay almacenamiento organizado por dias, no vamos a guardar tanto tiempo el fichero.
   destino="/mnt/snapshot"
fi

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

case $1 in

   "start")
        log "Detectado inicio de movimiento $2" 
        email "Subject: Evento camara\r\n\r\nDetectado inicio de movimiento $2"
        #El fichero motion.txt tiene dos finalidades: 1) testigo para indicar que estamos detectando movimiento 
        #                                             2) guarda los nombres de los ficheros de captura de las fotos
        touch /tmp/motion.txt
        ;;
   "picture")
        fichero=$(basename $3)
        log "Guardando imagen $2 : $destino/$fichero" 
     
        #Si estamos en una ráfaga de movimiento detectado, guardamos el nombre de fichero con la foto.
        test -e /tmp/motion.txt && echo "$destino/$fichero" >> /tmp/motion.txt

        #Se guarda el fichero en el almacenamiento destino
        mv "$3" "$destino/$fichero"
  
        #Si no está montado el almacenamiento remoto y vemos que llevamos mas de 10 imagenes en
        #movimiento tenemos que borrarlas y enviarlas ya mismo, para no saturar el espacio.
        if [ $montado -eq 0 ]
        then
           #Si estamos en una ráfaga de movimiento detectado....
           if [ -e /tmp/motion.txt ]
           then
              lineas=$(wc -l /tmp/motion.txt | cut -d" " -f1)
              test $lineas -gt 10 && envia_secuencia $2
           else
              #Si no lo estamos, es una captura *snapshot* regular sin interés, la borramos.
              rm -f "$destino/$fichero"
           fi  
        fi
        ;;
   "end") 
        log "Detectado fin de movimiento $2"
        envia_secuencia $2
        ;;
    *) log "Evento $1"
esac


#Borra fichero "sent" creado por sendmail si existe, para liberar espacio
rm -rf /root/sent
rm -rf /sent

exit 0

Por otro lado, el fichero /etc/rc.local se modifica para crear el fichero /mnt/testigo en el arranque.

# 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

#Desmontamos /mnt por si acaso
umount /mnt

#Borramos /mnt/snapshot local si tuviera algo
rm -rf /mnt/snapshot

#Creamos testigo para detectar que no se ha montado el almacen remoto
touch /mnt/testigo

#Montamos almacen remoto por sshfs
sshfs -o ssh_command="ssh -i /root/.ssh/id_rsa -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no" -o nonempty openwrt@172.19.231.4:/home/openwrt /mnt

exit 0

Bueno, pues esto quedá asi hasta el siguiente ciclo de mejoras.