Hace ya unos diez meses que me compré mi primera "bombilla smart" — una de IKEA TRÅDFRI, que es de lo más asequible y bueno que hay, y hasta hoy, que he llenado mi casa de bombillas "inteligentes" de todo tipo y compatibles entre sí. En este tiempo he aprendido (duramente) un montón de cosas, y malgastado un poco de dinero en el proceso, así que aquí intento detallar lo que he aprendido.

Las lámparas Philips Hue no merecen especialmente la pena. Las bombillas Hue, las tiras LED y demás cacharros son indiscutiblemente buenos, además de caro. Pero las lámparas completas marca Hue no son más que lámparas normales con bombillas Hue o una tira LED en su interior. Puedes hacértelo tú mismo más barato. Ve a cualquier tienda de lámparas, ya verás…

Hay problemas de calidad inesperados. He tenido que devolver varias bombillas E14 de IKEA porque hacen un zumbido insoportable mientras están apagadas (por Zigbee, que aún reciben corriente). En una mesilla, con lámparas en forma de tubo, hacen que sea imposible dormir. Las bombillas Hue no tienen ese problema, pero claro: cuestan exactamente el triple. Pero ojo, no es que todo lo de Philips sea perfecto: también he tenido que devolver una tira Lightstrip Plus 2+1m porque el transformador hace un zumbido insufrible (eso sí, sólo cuando la luz está encendida). Sin embargo, otra tira Lightstrip Plus 2m no tiene ese problema, así que parece ser cuestión de suerte.

La compatibilidad es variable. Varias marcas (Hue, TRÅDFRI, innr…) son compatibles con Zigbee, sin embargo, con matices: por ejemplo, las lámparas con selección de tono de blancos pueden no ser perfectamente compatibles entre sí. Un ejemplo práctico: con el hub TRÅDFRI de IKEA, las bombillas Hue White Ambiance E14 no tienen disponibles todas las escenas de blancos, y además, no se pueden seleccionar con el mando redondo TRÅDFRI (que sí que deja seleccionar tonalidades con las bombillas de IKEA). Si se usa otro hub, como el integrado en el Echo Plus, entonces sí que se pueden seleccionar todas las tonalidades de blancos vía app, pero entonces, el mando redondo TRÅDFRI se vuelve inservible completamente.

No todos los dispositivos parecidos funcionan igual. Pese a ser Zigbee, cada implementación funciona de una forma ligeramente distinta. Por ejemplo, IKEA hace el emparejamiento en dos pasos: primero se empareja el mando con el hub (poniéndolos pegados el uno al otro y pulsando un botón en el mando), y luego se empareja el mando con la luz, quedando todo finalmente emparejado. Con Hue, la cosa es distinta: al encender una luz sin emparejar, se puede emparejar con cualquier hub, aunque esté a varios metros. Si la luz está emparejada pero el hub se ha "olvidado", entonces hay que resetearla usando el número de serie. Y si tienes por casualidad otro hub (como me pasa a mi, que uso el Echo Plus para las luces sin mando, y el hub TRÅDFRI para las luces que también tienen mandos IKEA), eso da lugar a casos divertidísimos donde lanzas el discovery del Echo Plus y termina emparejándote luces que NO querías emparejar (y dejándote los mandos físicos inservibles en el proceso).

HomeKit es un caso perdido. De verdad, es imposible. Yo lo he intentado y no hay manera. La única forma de controlar algo por HomeKit es que el hub sea certificado HomeKit, que el dispositivo que controla sea del mismo fabricante que el hub, y que esté certificado también para HomeKit. Por ejemplo, tanto IKEA TRÅDFRI como Philips Hue tienen hubs y bombillas compatibles con HomeKit, pero no se pueden mezclar (pese a ser compatibles entre sí, con Zigbee), porque no funcionarán: si tienes el hub de IKEA, sólo podrás controlar por HomeKit las luces de IKEA, y viceversa.

Hay trucos interesantes que no están detallados de forma oficial. Por ejemplo: se pueden emparejar dos mandos TRÅDFRI entre sí para que controlen el mismo grupo de luces. Esto es bastante útil, por ejemplo, para luces de mesilla en una cama doble, duplicando el control de luces y haciendo que se enciendan y apaguen a la vez. Útil si vives solo, claro…

A día de hoy, esta es mi configuración de iluminación:

1. Mesillas del dormitorio: dos bombillas Philips Hue E14 (White Ambiance), con dos mandos IKEA TRÅDFRI, enlazadas con el hub de IKEA (porque el Echo Plus no reconoce los mandos)
2. Techo del dormitorio: una bombilla IKEA TRÅDFRI E27 con selección de tonalidad de blancos, enlazada con el hub del Echo Plus
3. Salón: dos raíles, cada uno con tres bombillas IKEA TRÅDFRI GU10 (ajuste de brillo únicamente), enlazadas al hub del Echo Plus
4. Televisión: detrás de la TV, hay una tira Lightstrip Plus de 2m, enlazada con el hub del Echo Plus.
5. Comedor: un raíl de tres bombillas IKEA TRÅDFRI GU10 (ajuste de brillo únicamente), enlazadas al hub del Echo Plus
6. Estudio: una única bombilla Philips Hue E27, con ajuste de brillo, enlazada con el hub del Echo Plus
7. Cocina: dos barras LED de IKEA, modelo OMLOPP (de 60 y 80cm) bajo los muebles de la cocina, con un driver TRÅDFRI de 30W, y un mando a distancia TRÅDFRI, con el driver enlazado al hub de IKEA (para no perder la funcionalidad del mando)

A través del skill de IKEA Smart Home (antes IKEA TRÅDFRI), el Amazon Echo detecta las luces conectadas al hub-gateway de IKEA, y se pueden controlar al mismo nivel que las que están enlazadas directamente con el Echo Plus.

En el futuro, me gustaría reemplazar el hub de IKEA por el del Echo Plus, que es evidentemente superior al de IKEA en todos los aspectos excepto en el soporte de mandos a distancia de IKEA (que los detecta como un "Nuevo Dispositivo" desconocido sin funcionalidad alguna).

Hasta que los soporte (si es que algún día lo hace), tengo que decidir si aguanto con dos hubs, o si cambio los mandos de IKEA por otros que quizás sí sean compatibles (¿Cuáles lo son? ¡Quién sabe! Aunque el Echo Plus parece ser plenamente compatible con el Hue hub, y por extensión, con todas las cosas Hue)

Toca tener paciencia.

Hace unos días recibí dos routers Mikrotik hAP ac, pedidos con la esperanza de poder sustituir el nefasto Comtrend de Movistar —en modo monopuesto, por Imagenio— y mi fiel Asus RT-N66U que ya empezaba a fallar a nivel físico, además de no llevarse demasiado bien con un TP-Link WA801ND, que generaba problemas de ARP que no conseguí resolver. Y además carecía de PoE Gigabit…

Primero, tomar alguna que otra decisión ejecutiva. Por ejemplo, acabar con el deco nefasto de Movistar en favor del app de Yomvi para Smart TV. Imagenio funciona a través de su propia VLAN, con una configuración propia (que ha de exportarse del router Comtrend) y otras cosas más. Como en casa apenas usamos la tele y aún menos el deco, y el app de Yomvi funciona perfectamente en la tele (sólo faltan unos pocos canales — y ninguno importante para nosotros), parece que el beneficio es más grande que la pérdida.

Manos a la obra. Primer paso, trastear con el ONT. Traté de configurar el ONT (Huawei HG8240) como router monopuesto.

Al hacer eso, y porque soy un manazas, la lié muy parda y borré sin querer mi contraseña del ONT (en la configuración de comunicación con el OLT. Esta contraseña es única para cada cliente de fibra, y también se llama IdONT en jerga de Movistar. Después de intentar conseguir ayuda por parte de Movistar (y aún estoy esperando a que me llamen…) encontré, de paso, una forma de recuperar el IdONT bastante tonta.

Primero, hay que entender que el IdONT (AKA "ONT Authentication") es una cadena hexadecimal de 10 carácteres que a menudo (pero parece que no siempre) comienza por la letra f. Resulta algo confuso porque además la interfaz de configuración la muestra por defecto como una cadena ASCII, así que es un texto más corto con a veces espacios, letras y quizás tildes (no tiene mucho sentido leerlo puesto que es hexadecimal convertido a ASCII).

Pues bien, ese mismo IdONT se usa como usuario para la VoIP, y pese a haberme cargado el IdONT en la configuración, seguía en su lugar la configuración de la VoIP. Sencillamente, yendo a Status > VoIP information aparece en la tabla el campo "User Name", con el formato "IdONT_n". En mi caso, algo parecido a "f2013000919191_1". Volviendo a la configuración de contraseña del OLT, hay que seleccionar el modo hexadecimal, poner la cadena (en el ejemplo, f2013000919191), introducir el SN (número de serie — fácilmente accesible como "SN" en la caja del dispositivo) y guardar. ¡Y hay sincronía!

Para la próxima vez, más vale hacer una copia de seguridad de toda la configuración, apuntar todos los campos que se modifican, tomar capturas de todo y mirar bien qué es cada cosa. Dos veces.

Todo esto para al final descubrir que el PPPoE gestionado directamente por el ONT (lo que buscaba conseguir para convertir al Mikrotik en completamente agnóstico de todo y que únicamente recibiese asignación por DHCP en la WAN), no llega ni de lejos a aprovechar los 300/300. Así que dejo la configuración como estaba antes y busco otra vía.

Segundo intento: configurando el cliente de PPPoE directamente en el router Mikrotik. En pocas palabras, esto supone configurar la interfaz WAN (ether1) con una VLAN (en este caso, ID 6), y sobre esa VLAN, ejecutar un cliente PPPoE con la configuración estándar de Movistar FTTH. Todo esto se puede hacer a través de WebFig, sin necesidad de descargar Winbox. Sería:

1. Interfaces > VLAN (tab) > Add. Poner VLAN ID a 6, Interface a ether1 (puerto WAN que va al ONT) y guardar.
2. PPP > Add New (PPPoE client). Interfaz vlan1 (o la que acabamos de crear), usuario adslppp@telefonicanetpa y contraseña adslppp.

Y ya está.

Queda margen para optimización y mejoras. Por ejemplo, montar una red de invitados usando un bridge específico, Virtual AP en Wireless, un nuevo servidor DHCP en esa interfaz, quitando el Default Forward y configurando reglas en el firewall. También tengo pendiente explorar Fasttrack/Fastpath aunque existen limitaciones por el uso de PPPoE (maldita sea, Movistar).

Para terminar sólo queda configurar el segundo AP, conectado mediante ethernet gigabit y alimentado por PoE (power over ethernet), en modo punto de acceso / bridge completo (desactivando el servidor DHCP, configurando el AP con una IP estática en la red del router principal, e incluyendo todas las interfaces existentes en un único bridge).

La guinda en el pastel es el WiFi, 802.11ac en 5 GHz. Se puede configurar (no viene por defecto) con ancho de banda 20/40/80Mhz, y supera los 700 Mbps observados (de unos teóricos, en papel, de 867 Mbps). En la práctica, suele estar por encima de los 500 Mbps. Esto, junto con una configuración de punto de acceso idéntico en el router principal y en el AP, hace que en la práctica sea posible alcanzar bastante más de 300 Mbps inalámbricos en prácticamente cualquier parte de casa, y además con roaming entre los dos puntos de acceso sin notarlo. ¡Esto es el futuro!

Hasta el momento, mi única visita consciente y adulta a París fue una escala de un día, entre un Eurostar desde Londres y un vuelo a Madrid al día siguiente por la tarde. No fue especialmente bien: perdí el DNI durante el viaje, me olvidé de comer en París, llegué tarde al tren al aeropuerto y al poco de cogerlo se averió (y pese a todo, conseguí volver a Madrid en mi vuelo — y eso que hasta los carritos de bebé me adelantaban por la terminal de lo agotado que estaba).

Salvando todo ese drama, y unas temperaturas absolutamente insoportables, la visita estuvo bien, pero me dejó con cierto amargor del que hasta ahora no había conseguido librarme. Pero una amiga, Nani, me convenció para ir en enero de este año y … bueno, resulta que con tranquilidad, París está bastante bien. Y ahora he renovado mi fe en París, su maravillosa red de transporte (sí, es que a mi me van esas cosas…) y también su Autolib'. Ya he cumplido mi objetivo de conducir en otra —caótica— ciudad europea. Londres, ahora es tu turno.

Y bueno, aprovechando que estábamos allí no podía faltar un paseo en TGV para comprobar si Estrasburgo está donde dicen que está y cómo están quedando nuestros impuestos.

Está bien París, sí. Mira, mamá, sin miedo.

Porto tiene tres grandes virtudes. La primera es el vino dulce. La segunda es su aspecto inconfundible. Y la tercera son sus vuelos baratísimos desde Madrid. Así que, ¿por qué no ir a pasar un rato, otro enero más? ¡Daytrip!

La primera vez fue en enero del año pasado. Ya hablé de eso anteriormente, y me vine con algunas fotos que aún me traen buenos recuerdos:

Aprovechando las ofertas de año nuevo, volví, esta vez con Andrea, y a parte de ponernos finos a vino, pudimos ver cosas bonitas y disfrutar de un tiempo espectacular. Gracias, karma.

Para contrastar, os dejo con mi mejor peor foto:

Y bueno, no hay dos sin tres. ¿Nos vemos en enero?

"IP over…" da para muchas cosas. Por ejemplo, el maravilloso protocolo de IPoAC. Pero hoy voy a hablar de otra cosa. IP sobre DNS, y de IP sobre ICMP.

¿Motivo? Viajar. Y la necesidad de tener un mínimo de comunicación, aunque sea navegación web reducida a mínimos, Telegram y poco más. Porque a menudo los precios resultan inabarcables… y porque algo bueno tendrá que tener ser un tecnofriki.

Dos cosas, por lo tanto: iodine para encapsular vía DNS, y hans para hacerlo a través de ICMP. En mi caso, he escogido la configuración más sencilla: una máquina en DigitalOcean dedicada exclusivamente para la tarea (dado que interferir con DNS e ICMP puede resultar complicado si no), y un dominio propio con control sobre la zona DNS.

Instalando iodine

Lo primero es crear la zona DNS. Asumiendo que tenemos un dominio h4x0r.com, y la IP de nuestro servidor es 123.123.123.123, bastaría con crearlo de tal manera que iodine.h4x0r.com fuese una entrada A apuntando a la IP, y tunnel.h4x0r.com fuese una entrada NS apuntando a iodine.h4x0r.com. como nombre cánonico. Muy importante el punto al final para que no sea relativo.

Después, en el servidor, hay que instalar iodine. En la última Debian es muy fácil: apt-get install iodine y listo. Con ello, sólo queda configurar bien iodine editando el fichero /etc/default/iodine:

START_IODINED="true"
IODINED_ARGS="10.0.0.1 tunnel.h4x0r.com"    
IODINED_PASSWORD="h4x0r"        

La primera línea hace que el daemon se llegue a ejecutar (si no, el script init.d no se ejecutaría). Después, los argumentos: primero, la IP —privada— que tomaría el servidor una vez establecido un túnel, y después, el dominio público que apunta al túnel (ojo: la entrada NS aquí). Y por último, la contraseña en texto plano del túnel que deberán conocer tanto cliente como servidor. Cámbiala.

Llegados hasta aquí, basta con lanzar iodine como un servicio normal, haciendo /etc/init.d/iodined start y listos.

Cosas a tener en cuenta: primero, que iodined actúa en el puerto 53 así que no debe haber ninguna instancia servidor de bind o de dnsmasq corriendo. De ahí el interés de tener un servidor (virtual) y una IP dedicada únicamente para esta tarea. Después, que realmente iodine lleva dos procesos: iodine que es el cliente, y iodined que es el servidor. Ambos usan argumentos casi idénticos así que puede dar lugar a confusión.

Instalando hans

En Debian esto es un pelín más complicado, porque no viene en los repositorios. Pero no es mucho más complicado. Lo primero: tener todas las herramientas para poder compilar, y git también, por comodidad. Si no lo tienes: apt-get install build-essential git y listo. Luego, basta con compilar y moverlo al $PATH, en mi caso, por elección personal, /usr/sbin que es donde está iodine (puedes verlo usando whereis).

git clone https://github.com/friedrich/hans.git
cd hans
make
sudo mv hans /usr/sbin/

Y ya está. Si ejecutas hans en cualquier directorio debería darte la versión.

Siguiente paso: hacer que se comporte como un demonio. Del sistema. Para eso me he limitado a copiar los ficheros de default de iodine y el init.d también, ajustándolo a las necesidades de hans. Luego con insserv se configura como servicio y se lanza al arranque. Aquí están los ficheros que he usado: el primero se debe copiar a /etc/default/hans y el segundo a /etc/init.d/hans. Luego:

chmod +x /etc/init.d/hans
insserv hans

El fichero de defaults es muy similar al de iodine. En la primera línea, dejar que el script de init.d pueda correr (forma fácil de desactivarlo). Después, la IP privada en la que se situará el servidor host (he usado un rango distinto al de iodine para evitar posibles conflictos). El flag -r hace que hans responda también a los paquetes de ping normales, lo cual puede ser útil para saber fácilmente si el proceso está corriendo. Aunque al no responderse desde la capa kernel, es normal que la latencia percibida en el ping se dispare. No pasa nada. Y finalmente, la contraseña del túnel (no olvides cambiarla y recordarla).

Finalmente, un último detalle: hay que hacer que el sistema no responda a los paquetes ICMP, para que hans pueda hacerlo. Muy sencillo. Basta con editar el fichero /etc/sysctl.conf y añadir una línea al final:

net.ipv4.icmp_echo_ignore_all = 1

Aquí es recomendable reiniciar el sistema. No es necesario realmente: con sysctl -p se pueden refrescar los ajustes del kernel sobre ignorar ICMP, y se pueden levantar ambos servicios a mano, pero así veremos si los servicios se levantan a la vez sin problemas. Y para comprobarlo, ejecuta ps aux como root, y tanto hans como iodine deberían figurar en la lista.

Usando iodine y hans desde OSX

Asumo que a estas alturas cualquier persona ya conoce brew en OSX. Así es muy fácil: brew install iodine y tendremos iodine instalado. Puede que dé algún error con la instalación de tun/tap, pero basta con seguir las instrucciones que ofrece el error para instalar ese componente y listo.

Para hans, se puede compilar (muy fácil en OSX si se tienen las herramientas instaladas) o directamente usar el binario compilado oficial y copiarlo al $PATH de tu elección (en mi caso, /usr/local/sbin, porque es donde están los orígenes de los binarios instalados por brew).

Una vez terminada la instalación de ambos componentes, podremos ejecutar iodine y hans en cualquier directorio con éxito. Y como se están ejecutando en el servidor, ya basta con atacar la parte cliente.

El principio de todo esto es de establecer un túnel. Así, si ejecutamos hans en el cliente con todos los parámetros necesarios, establecerá un túnel mediante ICMP de tal manera que en la dirección 10.0.1.1 tengamos al servidor remoto (pero no acceso a internet puramente dicho). Es exactamente lo mismo con iodine, solo que con la IP 10.0.0.1. En ambos casos, son las IP especificadas en los ficheros de default donde se configuran los argumentos de ejecución de servidor.

Desde el cliente, se lanza así:

# Para iodine
sudo iodine -f -P h4x0r tunnel.h4x0r.com
# Para hans
sudo hans -f -c 123.123.123.123 -p h4x0r

Lógicamente, hay que cambiar tanto la IP, como la contraseña y la ubicación de la entrada NS para corresponderse con lo configurado. Aquí sigue los ejemplos. El parámetro -f hace que se mantengan en primer plano. Se pueden ejecutar en segundo plano quitando ese parámetro.

Si todo funciona con éxito, podremos hacer SSH a la IP remota (que varía según usemos hans o iodine, como explico arriba) y conectarnos con el servidor (y nada más). Así que todo lo que queramos hacer pasa a través del servidor.

Aquí entran en juego varias posibilidades. Por ejemplo, montar un proxy SOCKS (que viene directamente con SSH):

ssh -D 1080 root@10.0.x.1

Y así, en 127.0.0.1:1080 tendremos un proxy SOCKS con acceso a internet. Luego basta con configurarlo en las opciones de red de OSX para que lo usen la mayoría de programas, o en los ajustes avanzados de red en el caso de Firefox, especificando la IP del proxy como 127.0.0.1 (local) y el puerto 1080 (el especificado en el argumento -D de SSH). Y así tendremos internet.

Otra opción más avanzada, basada en la misma, es usar sshuttle, que es una especie de "VPN de mentira" sobre SSH que no requiere nada instalado en el servidor remoto y es mucho más liviano. Basta con instalarlo en OSX y ejecutarlo:

brew install sshuttle
sshuttle --dns -r root@10.0.x.1 0/0

Así, tendremos un túnel entre nuestro ordenador y el servidor (con una IP privada que será 10.0.0.1 o bien 10.0.1.1, según qué tipo de túnel sea), y dentro de ese túnel, todo el tráfico (es decir, el de la subred 0.0.0.0/0) estará enrutado mediante sshuttle.

Hay un montón de opciones más. Por ejemplo, si tenemos OpenVPN montado en el mismo servidor, bastará con lanzar el cliente de OpenVPN y especificar la IP privada del servidor al otro lado del túnel, y debería tener acceso completo a internet entonces. O si tenemos OpenVPN en otro servidor, el mismo cliente (por ejemplo, Viscosity) se puede configurar para emplear un proxy SOCKS.

También existen otras opciones más complicadas como configurar el servidor como router, y una vez establecido el túnel, modificar nuestra tabla de enrutado para configurar al servidor remoto al otro lado del túnel como gateway.

Pero dado el limitadísimo ancho de banda que se suele obtener con un túnel, la opción más sencilla suele ser la mejor… y en este caso, yo creo que usar SOCKS con únicamente un navegador es suficientemente satisfactorio (y además, evitas que otros procesos y programas saturen el poco ancho de banda que tienes, porque no pueden salir a internet al desconocer el proxy). Y si SOCKS se queda corto, entonces sshuttle puede ser el combo ideal. ¡Y con unas pocas líneas de terminal!