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

domingo, 26 de junio de 2016

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.

viernes, 24 de junio de 2016

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.

miércoles, 8 de junio de 2016

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!.

jueves, 2 de junio de 2016

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:

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.