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

viernes, 29 de mayo de 2015

2 cambios recientes en posts anteriores.

En los últimos días he añadido cosas a artículos anteriores, después de encontrar bugs y mejorar alguna cosa. Lo modificado es:

  • Tarea puppet para instalación de paquetes: arreglado un bug que provoca un error de puppet cuando coincide la ejecución de la tarea con alguna operación desde otro proceso sobre el sistema de paquetes. Ahora se comprueba si no hay nadie mas manipulando el sistema de paquetes antes de instalarlo.
  • Montar una camara web IP mediante OpenWRT y una cámara USB barata: después de varias semanas capturando fotos con gran éxito resultó que al guardar todas las imágenes en un solo directorio superaba algún límite de Linux y era imposible hacer muchas cosas sobre dicho directorio. Modifico el script de captura para que coloque los snapshots en directorios separados por días.
 Y para que se sepa ahí queda.

Utilidades gráficas para convertir vídeos en Linux.

Hay un grupo de herramientas por las que muchas veces me preguntan los usuarios para poder convertir vídeos entre distintos formatos. Evidentemente, no es de recibo aconsejar herramientas de línea de comando, así que me he hecho una lista de varias utilidades que se pueden usar desde entorno gráfico (realmente suelen ser wrappers de utilidades de línea de comando) y son sencillas.

Esta es la lista en cuestión:

  • winff: ya comentada por mi compañero Esteban en esta entrada de su blog. La utilizo normalmente para convertir entre distintos formatos, por ejemplo de mpeg-2 a divx o para convertir un vídeo descargado de Internet en formato .flv o .wmv a formato .mp4.
  • ogmrip: una maravilla para convertir un DVD a formato mas manejable. Lo que mas me gusta es que puede convertir el DVD completo a un archivo en formato matroska, conteniendo dentro de un solo fichero .mkv varias pistas de audio y subtítulos. Muy útiles para clases de idiomas o bilingües. Los ficheros .mkv son perfectamente manejables por vlc.
Captura de OGMRip con la seleccion de pistas y capítulos

  • handbrake: es como el ogmrip, pero mas complicado y completo. Aconsejable para usuarios avanzados. Tiene versiones para Linux, OSX y Windows.
Pantalla de Handbrake. A la derecha los formatos destino.
  • makemkv: no he podido probarlo, pero lo tengo apuntado en la cola de cosas por hacer. Parece también bastante sencillo y es multiplataforma, funcionando en Linux, Windows y OSX.

Bueno, pues aqui está la lista para que no se olvide.

Post de prueba desde stackedit.io

Post de prueba

Esto es una prueba de escritura con markdown desde el editor online stackedit.io, ya que ScribeFire ha dejado de funcionar.

# wget http://stackedit.io
# ls -l
# exit
  • Esto es un punto
  • Segundo punto
Ahora otra prueba:
Cita: esto seria una cita con formato distinto, debería verse embebida en algun tipo de marco.
Lorem ipsum es el texto que se usa habitualmente en diseño gráfico en demostraciones de tipografías o de borradores de diseño para probar el diseño visual antes de insertar el texto final.
Aunque no posee actualmente fuentes para justificar sus hipótesis, el profesor de filología clásica Richard McClintock asegura que su uso se remonta a los impresores de comienzos del siglo XVI.1 Su uso en algunos editores de texto muy conocidos en la actualidad ha dado al texto lorem ipsum nueva popularidad.

viernes, 22 de mayo de 2015

Averiguar numero de serie y marca de los monitores.

Cuando estamos inventariando monitores una manera simple de saber su número de serie sin tener que mirar el código de barras por detrás es usar este comando que me descrubrió mi compañero Oscar:

# hwinfo --monitor

Entre otros datos, saldrá el número de serie, la marca, el modelo, etc . Por desgracia, esto no funciona para cualquier monitor ya que no todos tienen el número de serie "grabado a fuego" en su interior, pero al menos para los monitores que tengo en casi todo el centro funciona. También es necesario que al ejecutarse el monitor esté encendido, por motivos obvios: si no está encendido el PC no puede preguntarle nada.

Para automatizar esto podemos hacer un script que se ejecute en el arranque, coja los datos que queramos y lo escriba en algún fichero en alguna ubicación de red. De esta manera podemos inventariar de forma masiva.

Otra opción, si tenemos puppet, es crear un facter que obtenga esos datos y los guarde en los .yaml que crea puppet en el servidor, junto con los otros facter de la máquina. El facter se guardaría en cada PC, en /usr/lib/ruby/vendor_ruby/facter/monitor.rb y su contenido sería (toma Ruby pal cuerpo):

if File.exists?("/usr/sbin/hwinfo")

serial = Facter::Util::Resolution.exec('hwinfo --monitor 2>/dev/null | grep "Serial ID:" | head -1 | cut -d":" -f2')
if not serial.nil?
Facter.add("monitor-serial") do
serial=serial.delete('"').strip
setcode {serial}
end
end

model = Facter::Util::Resolution.exec('hwinfo --monitor 2>/dev/null | grep "Model:" | head -1 | cut -d":" -f2' )
if not model.nil?
Facter.add("monitor-model") do
model=model.delete('"').strip
setcode {model}
end
end

vendor = Facter::Util::Resolution.exec('hwinfo --monitor 2>/dev/null | grep "Vendor:" | head -1 | cut -d":" -f2')
if not vendor.nil?
Facter.add("monitor-vendor") do
vendor=vendor.delete('"').strip
setcode {vendor}
end
end
end

Evidentemente, habría que instalar el paquete hwinfo en las máquinas e incluirlo en el mayhave que tuvieramos en el pkgsync. Si lo probamos en una de las máquinas:

# facter | grep monitor
monitor-model => 151E
monitor-serial => YEPF619484
monitor-vendor => FUS

Eso sería lo que se guardaría en el fichero .yaml de la máquina, en la ruta /var/lib/puppet/yaml/fact del servidor puppet .

Una vez hecho esto, sería sencillo procesar todos los ficheros .yaml con un script que haga el inventario de todas las máquinas conectadas a puppet.

 

Acceso por VNC a una sesión remota iniciada por un usuario.

Esta receta es de mi compañero Julio, la dejo aquí por su interés y porque seguro que tendré que recurrir a ella en el futuro.

Si queremos conectarnos a una sesión de usuario ya iniciada en una maquina remota y ver su escritorio o incluso tomar el control del mismo, estos son los pasos.
1) Instalar en la máquina remota los paquetes siguientes:
# apt-get install x11vnc xvnc4viewer

No olvidar ponerlos en el fichero de mayhave si la máquina está sujeta a pkgsync.
2) Conectamos a la máquina y cambiamos al usuario que ha iniciado sesión:
# ssh root@maquina
# who
tylerdurden    tty8         2015-05-21 13:37 (:0)
# su tylerdurden

3) Arrancamos servidor VNC en dicha sesión, (suponiendo que está en :0, como en el ejemplo):
$ x11vnc -display :0

4) Y ya, desde otro terminal en nuestra máquina:
$ vncviewer -ViewOnly maquina

Nos unimos a la sesión y ya podemos ver que hace "tylerdurden" en "maquina", ¡gracias, Julio!.

lunes, 18 de mayo de 2015

De Mint a Manjaro, pasando por Elementary.

El PC que uso en el trabajo, con Mint 12 Lisa-Mate ya olía a PPSOE, un olor rancio y anticuado: muchas aplicaciones estaban obsoletas. Como en los otros PC que tengo había instalado recientemente Mint 17 Quiana-XFCE me apetecía probar otras cosas.

Tenía mucho interés en probar Elementary OS, y aprovechando la reciente aparición de su última versión, Freya, con base Ubuntu 14.04 me decidí a encasquetarla en el PC. La instalación fue trivial y tras el arranque me encontré con un entorno muy cool y limpito, como muy para votantes de Ciudadanos, pero con pocas aplicaciones, también como para votantes de Ciudadanos. Lancé la instalación de las aplicaciones que uso normalmente con un apt-get install tocho y cuando acabó me puse a enredar un poco con el entorno. Entonces me di cuenta que la cosa no iba fluída. Intenté reproducir un vídeo muy relajante que tengo para pruebas, descargado con youtube-dl y vi que iba a saltos. Carajo, seguro que es la tarjeta de vídeo, ¿que pasa ahora contigo, Ubuntu?. Bueno, pues abreviando: probé múltiples configuraciones con 3 tarjetas de vídeo distintas (ATI, Nvidia y UniChrome), bastante antiguas, todo hay que decirlo, perdiendo varias horas y no hubo manera: el vídeo y el entorno gráfico tenían un lag considerable. Podía dedicarme a averiguar donde estaba el problema pero no me apetecía.

Llegado a este punto en diversas cuestiones de la vida, siempre me hago la misma pregunta: ¿qué haría Gengis Kan en esta situación?. Efectivamente: mandar a la puñeta al Elementary y machacarlo probando otra cosa.

¿Y ahora que instalaba?. Tenía ganas de seguir probando algo nuevo y tenía otro Linux pendiente en la recámara: Manjaro. Un Linux con fama de ligero y agradable y además basado en Arch Linux, que es una familia con la que nunca he trabajado. Dicho y hecho: bajé e instalé la version XFCE en un periquete. Otra vez la instalación fué sencilla (como ha mejorado la cosa desde mi primer Slackware hace 20 años) y esta vez arranqué y lo primero que hice fue probar el vídeo en cuestión. Para mi sorpresa iba allegro molto troppo, mas fluído que nunca. Y el resto del entorno también: hacía tiempo que no me iba tan ligero el PC.

Instalé varias aplicaciones típicas viendo que el gestor gráfico de paquetes no es muy distinto de synaptic pero ante mi sorpresa... vi que algunos paquetes se descargaban y compilaban en mi máquina antes de instalarse (como un Gentoo Linux, que gracioso) y para otros se descargaba la versión .deb, se hacia algo con ella y se instalaba ya en el formato de Arch. Sorprendente. Incluso pude instalar desde repositorios los drivers de la impresora Brother nueva, cuando en Ubuntu y Debian había tenido que bajar los deb de la página de Brother e instalarlos a mano. Cuando averigüé el nombre de las utilidades de gestión de paquetes de línea de comandos vi que tenían  nombres tronchantes: Pacman y Yaourt, parecen dos personajes de Historias Corrientes.

Bueno, pues me gustó tanto que este fin de semana he mandado al averno el Mint que tengo en el Netbook y he instalado el Manjaro Netbook Edition, optimizado para Netbooks con procesador Intel Atom y con un entorno XFCE configurado de forma bastante curiosa, como un Unity de andar por casa:

muy adecuado para pantallas pequeñas. He estado afinándolo en ratos muertos y ciertamente el Netbook ha revivido.

Para acabar, en Un mundo feliz, de Aldous Huxley, dicen que el soma tiene "todas las ventajas del cristianismo y del alcohol; y ninguno de sus inconvenientes". Bueno, pues Manjaro-Arch tiene todas las ventajas de Debian y Slackware, y ninguno de sus inconvenientes. Creo que este es el comienzo de una larga amistad.


miércoles, 13 de mayo de 2015

Tarea puppet para instalación manual de paquetes

A veces tengo que instalar en un conjunto de ordenadores un paquete que no está en ninguno de los repositorios de Linux, ya que es una aplicación suelta (por ejemplo, Master PDF Editor)  o bien un paquete generado  por algún compañero o por mi mismo.
Una posible opción sería construir un repositorio privado dentro de la red del centro y meter dentro los paquetes que queramos, como cuenta aquí mi compañero Esteban Navas. Otra opción es hacer una tarea puppet que compruebe si el paquete está instalado con la versión correcta, y en caso  contrario descargue el paquete desde una ubicación fija y proceda a instalarlo. Este es el método que estoy utilizando,  definiendo un recurso puppet nuevo para realización de estas tareas:
root@servidor:/etc/puppet/modules/instala_paquete/manifests# cat init.pp 
define instala_paquete($version,$fichero) {

       exec { "descarga_$fichero":
           path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
           command => "mkdir -p /root/descargas; wget -q http://servidor/ficheros/$fichero -O /root/descargas/$fichero",
           unless => "dpkg -l |grep $title | grep $version | grep ii",
           notify => Exec["instala_$fichero"]
       }

       exec { "instala_$fichero":
              path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
              command => "dpkg -i --force-architecture /root/descargas/$fichero; apt-get -y -f install",
              refreshonly => true,
              require => Exec["descarga_$fichero"]
       }
}
El uso del recurso sería poner en la clase específica correspondiente algo como:
   ......
   instala_paquete {"master-pdf-editor":
                         version=>"2.2.15",
                         fichero=>"master-pdf-editor_2.2.15_i386.deb"
   }
   ......
Como se ve el primer parámetro es el nombre del paquete una vez instalado, el segundo la versión (utilizada para comparar con la versión instalada y actualizarlo si procede) y el último es el nombre del fichero .deb descargado. Dicho fichero .deb debemos ponerlo en la ruta http://servidor/ficheros/master-pdf-editor_2.2.15_i386.deb para que se pueda bajar antes de instalarse.
Por supuesto, podemos poner tantas invocaciones a instala_paquete como queramos dentro de las distintas clases puppet que usemos:
        .....
        instala_paquete {"autolabel":
                              version=>"0.1-1",
                              fichero=>"autolabel_0.1-1_all.deb"
              }
        .....
La tarea que define el recurso estará en la ruta: /etc/puppet/modules/instala_paquete/manifests/init.pp  y tendrá el directorio /etc/puppet/modules/instala_paquete/files vacío.
Bueno, pues con esto instalaremos paquetes sueltos de una forma elegante a la par que sencilla. Nos leemos.

Addenda 29-Mayo-2015: después de tener en producción la tarea varios días, me di cuenta de que ocasionalmente fallaba en la ejecución de puppet en los clientes donde ya estaba instalado el paquete. Después de varias pruebas comprobé que era porque si la ejecución de la tarea puppet coincidía en el tiempo con una operación sobre el sistema de paquetes (pkgsync, apt-get ... desde algun crontab o script, etc) evidentemente se produce un conflicto que finaliza con el fallo de la tarea.

La solución pasa por comprobar antes de ejecutar la instalación del paquete si hay o no otra operación en marcha. Para ello uso
lsof /var/lib/dpkg/lock
Que comprueba si el fichero /var/lib/dpkg/lock está siendo usado, señal de que hay un proceso trabajando sobre el sistema de paquetes. Por supuesto, es necesario que el paquete "lsof" esté instalado con antelación si no lo estaba. En mi caso lo hice poniendo dicho paquete en el musthave del pkgsync.

La tarea quedaría
define instala_paquete($version,$fichero) {

       exec { "descarga_$fichero":
           path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
           command => "mkdir -p /root/descargas; wget -q http://servidor/ficheros/$fichero -O /root/descargas/$fichero",
           unless => "dpkg -l |grep $title | grep $version | grep ii",
           notify => Exec["instala_$fichero"]
       }

       exec { "instala_$fichero":
              path => "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
              command => "lsof /var/lib/dpkg/lock || (dpkg -i --force-architecture /root/descargas/$fichero; apt-get -y -f install)",
              refreshonly => true,
              require => Exec["descarga_$fichero"]
       }
}
El operador || usado en el command del segundo exec indica que si el comando lsof falla (es decir, no se encuentra en uso /var/log/dpkg/lock), se ejecute el dpkg y apt-get posteriores. En caso de que lsof tenga éxito no se hace nada después.

De esta manera si he conseguido eliminar los fallos ocasionales en la ejecución de la tarea.

miércoles, 6 de mayo de 2015

OpenWrt+USBIP+Smartboard 680 (Episodio II)

Recapitulemos: ya teníamos nuestra pizarra conectada al USB del router y compartida por IP a través del servicio usbipd. Ahora nos falta un cliente que se conecte a ella.

En el caso que me ocupa, el cliente era un ordenador con Windows, asi que me bajo el fichero "usbipwindowsv0.2.0.0signed.zip" desde

http://sourceforge.net/projects/usbip/files/usbipwindows/.

Descomprimiendo el fichero vemos que su contenido es:

  • USAGE
  • usbip.exe
  • usb.ids
  • usbipenum.cat
  • USBIPEnum.inf
  • USBIPEnumx64.sys
  • USBIPEnumx86.sys

USAGE es un pequeño manual de instalación del driver usbip, mientras que usbip.exe es el programa cliente que usaremos para conectarnos al servidor usbip remoto. El resto de ficheros son el driver en si, que debemos instalar en nuestro sistema operativo para que todo funcione. Hemos dicho que dentro de USAGE está el manual de instalación, copio el contenido aquí:

To install the virtual usb bus driver on Windows XP:

1. Uncompress the downloaded binary package to a directory.
2. Double-click the 'Add Hardware' wizard in Control Panel.
3. At the 'Welcome to the Add Hardware Wizard', click 'Next'.
4. Select 'Yes, I have already connected the hardware', then click Next.
5. Select 'Add a new hardware device' from the list, then click Next.
6. Select 'Install the hardware that I manually select from a list(Advanced)', and then click next.
7. Select 'System Devices', then click Next.
8. Click 'Have Disk', click 'Browse', choose the uncompressed directory, and click OK.
9. Click on the 'USB/IP Enumerator', and then click Next.
10. At 'The wizard is ready to install your hardware', click Next.
11. Click Finish at 'Completing the Add/Remove Hardware Wizard.' 

For Window 7 :
1. (Only necessary for custom builds: For x64 allow unsigned drivers: Enter "bcdedit /set testsigning on" in an administrative cmd window)
2. Uncompress the downloaded binary package to a directory.
3. Start a the Device Manager
4. Click Any hardware node
5. Choose "Add Legacy Hardware" from the "Action" menu
6. At the 'Welcome to the Add Hardware Wizard', click 'Next'.
7. Select 'Install the hardware that I manually select from the list'
8. click 'Next'
9. Click 'Have Disk', click 'Browse', choose the uncompressed directory, and click OK.
10. Click on the 'USB/IP Enumerator', and then click Next.
11. At 'The wizard is ready to install your hardware', click Next.
12. Click Finish at 'Completing the Add/Remove Hardware Wizard.'

Básicamente la instalación consiste en meter el driver a mano como si instalásemos un dispositivo que no es plug'n'play, ya que no hay proceso de autodetección que valga. Una vez instalado el driver tenemos que reiniciar el sistema. Yo ademas copio el fichero usbip.exe a la ruta c:\windows, para tener el ejecutable accesible siempre. Cuando hemos reiniciado, podemos probar a mirar el equipo remoto abriendo una ventana de comandos y tecleando:

c:\> usbip -l 192.168.1.1

Asumimos que 192.168.1.1 es la dirección del router, que cada cual ponga la que corresponde en su caso. Esto nos dará:

usbip for windows ($Id$)

- 192.168.1.1
    1-1: unknown vendor : unknown product (0b8c:0001)
    : /sys/devices/platform/ifxusb_hcd/usb1/1-1
    : (Defined at Interface level) (00/00/00)
    :  0 - unknown class / unknown subclass / unknown protocol (03/00/00)

Como vemos, ahi está la pizarra, con su identificador 0b8c:0001. Si queremos conectarnos a ella lo mejor es hacer un pequeño script .bat que pondremos en el escritorio:

rem conectar-pizarra.bat
@echo off
c:\windows\usbip -a 192.168.1.1 1-1

Al ejecutar el script veremos que el Windows y la pizarra reaccionan como si los hubiésemos conectado el uno al otro por un cable USB directamente. En la pizarra el led pasa de rojo a verde estable, indicando que ha sido detectada e inicializada por el driver.

En el Windows veremos que aparece un nuevo dispositivo HID llamdo SMART Board en el administrador de dispositivos:

Y que en el system tray, el icono correspondiente a la pizarra Smart (el círculo blanco dentro de un recuadro azul) se activa y muestra un tooltip de aviso de que se ha detectado un dispositivo. Ni que decir tiene que previo a todo esto debemos haber instalado el software Smart Notebook con sus drivers en el Windows que estamos usando.

Con esto ya podemos trabajar con la pizarra a un porrón de metros del ordenador y conectada a través del túnel usbip como si hubiese una conexión directa: todas las pulsaciones son recibidas en el PC cliente.

Antes de acabar con esta parte, comentar un pequeño problema: una vez está conectada la pizarra, si intentamos cerrar sesión o apagar el ordenador la cosa se queda como bloqueada, sin llegar a cerrarse nunca. La causa es que antes de salir hay que desconectar la pizarra con este script de desconexión:

rem desconectar-pizarra.bat
@echo off
c:\windows\usbip -d 1

Al ejecutarlo sería como si quitásemos el cable usb, quedando la pizarra con su luz roja:

Y el PC  el icono de SmartBoard en el systray con el aspa roja:

En ese momento ya se puede cerrar sesión o apagar el PC sin problema.

En cuanto a Linux como cliente.... la historia es mas escabrosa, ya que no he podido hacer funcionar un cliente usbip. El primer problema es que hay dos versiones del paquete usbip, una en Debian Wheezy y otra en Ubuntu-Mint.

En Wheezy sería:

# apt-get install usbip
# dpkg -l | grep usbip
ii  usbip  1.1.1+3.2.17-1   i386  USB device sharing system over IP network
# usbip version
usbip (usbip-utils 1.1.1)
# usbip list -r 192.168.1.1
Exportable USB devices
======================
 - 192.168.1.1
	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)
#

Como vemos, es la versión 1.1.1, la misma que en vimos en el Openwrt:

openwrt# opkg update
openwrt# 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
openwrt# usbip version
usbip (usbip-utils 1.1.1)

Ahora si queremos enlazar desde Wheezy con el servidor usbip remoto haremos:

# usbip attach -h 192.168.1.1 -b 1-1
usbip: error: open vhci_driver
usbip: error: query

Hemos olvidado cargar el driver en memoria, lo haremos con:

# modprobe usbip_core vhci_hcd 
# usbip attach -h 192.168.1.1 -b 1-1
# lsusb
Bus 006 Device 002: ID 05e3:0716 Genesys Logic, Inc. USB 2.0 Multislot Card Reader/Writer
Bus 009 Device 002: ID 0b8c:0001 SMART Technologies Inc. 
#

Bueno, pues se supone que tenemos conectada a nuestro Debian la pizarra como dispositivo usb local a traves del túnel IP, pero lo cierto es que no funciona. El software y el driver de la pizarra dicen que no hay nada. Para despejar dudas probé con otros dispositivos USB: pendrives, webcams, impresoras usb, ratones y siempre tenía problemas de todo tipo, no llegando a funcionar ninguno. Por ejemplo, el pendrive decía en el syslog:

hub 9-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?"

Y no funcionaba. La webcam no llegaba a crear el dispositivo /dev/video0, y así sucesivamente. No se si estoy haciendo algo mal o es que la implementación del cliente usbip en Linux es peor que la de Windows, pero es lo que hay.

En cuanto a la versión cliente de Ubuntu/Mint, la cosa es peor:

# apt-get install usbip
# dpkg -l | grep usbip
ii  libusbip0   0.1.7-3  i386     USB device sharing system over IP network 		(shared library)
ii  usbip       0.1.7-3  i386     USB device sharing system over IP network
#  usbip -v 
usbip 0.1.7 ($Id: vhci_attach.c 42 2007-09-07 12:07:51Z hirofuchi $)

Como vemos, es una versión antiquísima que ni siquiera permite listar los dispositivos usb remotos:

# usbip -l 192.168.1.1
- 192.168.1.1
usbip err: usbip_network.c: 119 (usbip_recv_op_common) recv op_common, -1
usbip err: vhci_attach.c: 202 (query_exported_devices) recv op_common
usbip err: vhci_attach.c: 417 (show_exported_devices) query
# usbip -a 192.168.1.1 1-1
usbip err: usbip_network.c: 119 (usbip_recv_op_common) recv op_common, -1
usbip err: vhci_attach.c: 324 (query_import_device) recv op_common
usbip err: vhci_attach.c: 362 (attach_device) query
pc usbip # 

Nótese que la sintaxis del comando usbip es diferente de la sintaxis de la versión de Debian Wheezy, mucho mas "moderna". Después de la sorpresa inicial estuve investigando y  comprobé que la causa de esto es que el paquete usbip (0.1.7-3) que viene con ubuntu está obsoletísimo y siguen metiéndolo en repositorios. En este hilo hablan del tema y de la solución: el paquete usbip obsoleto sigue ahi hasta que alguien lo purgue. Los comandos usbip y usbipd correctos vienen ahora en otros paquetes distintos de utilidades relacionadas con el núcleo, siendo así:           

Otra opción es la descarga independiente de unos paquetes actualizados desde este repositorio PPA.

El hecho de que tengamos las versiones correctas de usbip y usbipd en Ubuntu no hace que funcionen: fallarán como fallaban en Wheezy. Me sabe mal decir que algo pensado originalmente para Linux me funciona en Windows y no en Linux, pero hay que ser honestos y dar al César lo que es del César. Si algún día encuentro el porqué de este malfuncionamiento y lo soluciono lo postearé aquí, hasta entonces ajo y agua.

Y con esto acaba mi segunda historia con OpenWrt. Si hago funcionar como repetidor wifi un OpenWrt en un router similar lo contaré en estos lares.