viernes, 13 de agosto de 2021

OpenWRT dist-upgrade, or how to update your OpenWRT automatically

I've been thinking in writing this post for a long time and with OpenWRT 21.02 hopefully coming I thought it was the perfect time so that you could benefit from it.

Those of us who run Debian love the way you can go from one version to the new one (Bullseye is coming this weekend, btw) without needing to reinstall the machine each time you update, a simple apt dist-upgrade will take care of everything.

I love Debian, but for the really small things I enjoy OpenWRT a lot and I've always missed the Debian dist-upgrade way of things on OpenWRT.

At work we have a lot of OpenWRT routers, so we had a quite automated way of managing things, so that when we had to update, we did the sysupgrade and then logged on the machine and executed something that installed back all the extra things we needed. It was then that I though... hey, what if we use the sysupgrade.conf thing to protect a service that would be run on the first boot of the device with the new version of OpenWRT and then this service would install all the packages we need?

And that's how the reinstall script (calling it a service would be too much) was born. This script will take care of reinstalling all the things that you tell him to install after a sysupgrade, so, all you need to do is to identify what extra packages you have installed and write the names on your /etc/reinstall.conf file, one package per line, also, if you want a service disabled, you would write its name prepending it with a "-", and that's it.

The only limitation that I've found that would annoy me is that reinstall needs network connection to work, so... if you need some of the extra packages to stablish the network connection (like a 4G connected router wich needs its drivers, a full wpa client to connect with WPA-EAP, ...), reinstall will fail, I suppose I could give an option to predownload the packages but that would need the target version of OpenWRT, so maybe that would mean that maybe reinstall should download the sysupgrade image itself along with the packages and launch the sysupgrade, ... well, who knows, maybe I end up writing a beast, but right now... it needs to be able to have network connection with OpenWRT out of the box to be able to reinstall

This is a /etc/reinstall.conf of one of my machines which runs as an AP, so I don't want dhcp or other stuff, but I want some extra packages to be able to access external storage and things like that:

-dnsmasq -uhttpd -odhcpd nmap diffutils usbutils kmod-usb-storage

BTW: this AP of mine is an ASL26555 with 16MB of RAM which has just been updated from the 19.07 series to 21.02.0-rc4 using reinstall without any problem.

So... you need the reinstall.conf file and we need the script itself, which is at the end of the post, you must save it as /etc/init.d/reinstall and then do a "chmod 755 /etc/init.d/reinstall", but as I told before... we must setup sysupgrade so that reinstall survives after it, so you must add to /etc/sysupgrade.conf at least the three reinstall lines that I have here on this example so that it ends looking something like this:

## This file contains files and directories that should ## be preserved during an upgrade. /etc/firewall.user /etc/crontabs/root /root /etc/init.d/reinstall /etc/rc.d/S99reinstall /etc/reinstall.conf

So... now you have it all setup... when you are going to do a sysupgrade... you must first do a "/etc/init.d/reinstall enable" in order to enable the service, so that it runs when sysupgrade reboots the device, that's when reinstall installs the wanted packages.

The service will log its actions on /root/reinstall.log by default, then disable itself so that it is not run anymore, and then reboot the machine so that it ends up right how you wanted it to be. After that you can log on the machine to see how everything went, and hopefully your log will look something like this:

_______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M ----------------------------------------------------- OpenWrt 21.02.0-rc4, r16256-2d5ee43dc6 ----------------------------------------------------- Downloading '' Connecting to Writing to '/dev/null' Download completed (14036 bytes) Thu Aug 12 17:29:39 CEST 2021 Downloading Updated list of available packages in /var/opkg-lists/openwrt_core Downloading Signature check passed. Downloading Updated list of available packages in /var/opkg-lists/openwrt_base Downloading Signature check passed. Downloading Updated list of available packages in /var/opkg-lists/openwrt_luci Downloading Signature check passed. Downloading Updated list of available packages in /var/opkg-lists/openwrt_packages Downloading Signature check passed. Downloading Updated list of available packages in /var/opkg-lists/openwrt_routing Downloading Signature check passed. Downloading Updated list of available packages in /var/opkg-lists/openwrt_telephony Downloading Signature check passed. Disabling -dnsmasq Disabling -uhttpd Disabling -odhcpd Installing nmap Installing nmap (7.80-3) to root... Downloading Installing libpcap1 (1.9.1-3) to root... Downloading Installing libstdcpp6 (8.4.0-3) to root... Downloading Installing zlib (1.2.11-3) to root... Downloading Installing libpcre (8.44-3) to root... Downloading Configuring libpcre. Configuring libpcap1. Configuring libstdcpp6. Configuring zlib. Configuring nmap. Installing diffutils Installing diffutils (3.7-3) to root... Downloading Configuring diffutils. Installing usbutils Installing usbutils (013-2) to root... Downloading Installing librt (1.1.24-3) to root... Downloading Installing libusb-1.0-0 (1.0.24-4) to root... Downloading Installing libevdev (1.10.1-1) to root... Downloading Installing libudev-zero (0.4.5-2) to root... Downloading Installing usbids (0.347-1) to root... Downloading Configuring libevdev. Configuring librt. Configuring libusb-1.0-0. Configuring libudev-zero. Configuring usbids. Configuring usbutils. Installing kmod-usb-storage Installing kmod-usb-storage (5.4.137-1) to root... Downloading Installing kmod-scsi-core (5.4.137-1) to root... Downloading Configuring kmod-scsi-core. Configuring kmod-usb-storage. Everything went Ok, reinstall has finished without errors.

I guess, that's all I have to say, hope you enjoy it, keep in mind that embedded devices are always tricky and that if your machine is not stable... you should probably not do automatic things like this on it, as always I take no resposability on anything, use it at your own risk, as for me, I trust OpenWRT so much that I have just reinstalled my ASL26555 from outside using it and everything went Ok ;-)

So... here is reinstall

Edit: Originally I had pasted the code in the page, but that was an error due to how bad blogger works, so... now I have published it on github and added the link to it

domingo, 9 de mayo de 2021

Flashing a Samsung stock ROM using heimdall from the command line.

I've read many times how to flash a Samsung official rom from Windows using Samsung's official tools and some other times I've read complex ways to do it using the Heimdall's grafical interface, ... but I never felt any of this ways was for me.

Fortunately I always flash custom ROMs instead, so I never had the need to flash a stock one, till recently, when I wanted to test andOTP on old Android versions, that's when I wanted to install the ancient stock versions of a couple of Samsung phones, and luckily I came to a quick commandline script that did it all for me.

WARNING: this procedure will wipe out all your data on the device in a way that you won't be able to recover it, I'm not resposable for any data loss or any damage to the device that any of the things I describe here may cause to the devices.

First of all you must unpack the stock rom (typically a zip file that inside has a whatever.tar.md5 file which is really a tar file, not a md5 one, so, you untar the tar.md5 file and you get the images of the phone's partitions (recovery.img, modem.bin, boot.img, ...) you can now remove that .tar.md5 file.

So... if you have clear that you are going to delete all your data on the phone and want to continue, I assume you have made a good backup of your data and you have verified that the backup is ok, or that you don't mind loosing it all. In any way...

You must start by wiping your data partition from your recovery or from the system itself by doing a factory reset and then going directly do the bootloader. The easiest way is by selecting reset to bootloader on the recovery after wiping data, or rebooting pressing the bootloader key convination for your device, but making sure that you didn't boot into the system after doing the wiping.

If you are sure you have formated data and booted directly to bootloader, you may need to confirm on bootloader that you want to "Continue" to flash your rom, that way you'll get to the "Downloading..." droid.

Now that we are on the bootloader on download mode we do:

heimdall print-pit --no-reboot > pit

and after we have downloaded the pit file:

heimdall flash --resume $(for i in *.*;do grep -B 1 $i pit|tr '\n' ' ';echo;done|sed "s/.*ame: \([^ ]*\) .*ame: \(.*\)/--\1 \2/"|tr '\n' ' ')

And you are done. The script will flash all the partitions that are included on the stock rom and after that it will reboot for the system to do its job after flashing, so... it will be a first time boot that will take a while, but that's it.

Just some side notes, using --no-reboot and then --resume has never really worked for me, maybe it was a problem with heimdall's version or my devices or whatever, in those cases the second heimdall command will fail, you must reboot to booloader again (without going to system, otherwise you'll have to format data again) and execute the flash command again without the --resume.

lunes, 3 de mayo de 2021

Windows and Linux software Raid dual boot BIOS machine

One could think that nowadays having a machine with software raid doing dual boot should be easy, but... my experience showed that it is not that easy.

Having a Windows machine do software raid is easy (I still don't understand why it doesn't really work like it should, but that is because I'm used to Linux software raid), and having software raid on Linux is also really easy. But doing so on a BIOS booted machine, on mbr disks (as Windows doesn't allow GPT on BIOS) is quite a pain.

The problem is how Windows does all this, with it's dynamic disks. What happens with this is that you get from a partitioning like this:

/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT /dev/sda2 206848 312580095 312373248 149G 7 HPFS/NTFS/exFAT /dev/sda3 312580096 313165823 585728 286M 83 Linux /dev/sda4 313165824 957698047 644532224 307,3G fd Linux raid autodetect

To something like this:

/dev/sda1 63 2047 1985 992,5K 42 SFS /dev/sda2 * 2048 206847 204800 100M 42 SFS /dev/sda3 206848 312580095 312373248 149G 42 SFS /dev/sda4 312580096 976769006 664188911 316,7G 42 SFS

These are the physical partitions as seen by fdisk, logical partitions are still like before, of course, so there is no problem in accesing them under Linux or windows, but what happens here is that Windows is using the first sectors for its dynamic disks stuff, so... you cannot use those to write grub info there :-(

So... the solution I found here was to install Debian's mbr and make it boot grub, but then... where do I store grub's info?, well, to do this I'm using a btrfs /boot which is on partition 3, as btrfs has room for embedding grub's info, and I setup the software raid with ext4 on partition 4, like you can see on my first partition dump. Of course, you can have just btrfs with its own software raid, then you don't need the fourth partition or anything.

There are however some caveats on doing all this, what I found was that I had to install grub manually using grub-install --no-floppy on /dev/sda3 and /dev/sdb3, as Debian's grub refused to give me the option to install there, also... several warnings came as a result, but things work ok anyway.

One more warning, I did all this on Buster, but it looks like for Grub 2.04 which is included on Bullseye, things have gotten a bit bigger, so at least on my partitions there was no room for it, so I had to leave the old Buster's grub around for now, if anybody has any ideas on how to solve this... they are welcome.

miércoles, 20 de mayo de 2020

Trabajando en remoto sobre Debian

La situación actual nos ha llevado a muchos a trabajar en remoto, algo para lo que hay muchas opciones, hablemos de alguna de ellas.


Es el sistema de acceso remoto por excelencia, lo usamos todos desde siempre, o al menos desde que la seguridad en la red importa, aunque no siempre fuera así, los ancianos del lugar usábamos el telnet, pero mejor no hablar de temeridades, no? ;-)

El secure shell como su propio nombre indica está diseñado para acceder a un shell, es decir, para acceso remoto a un entorno modo texto, pero como ya sabréis permite hacer túneles de todo tipo, desde puertos hasta forwarding de clientes X.

Si bien el SSH nos permite acceder a nuestros clientes X y traerlos hasta el servidor local de nuestro ordenador en casa, resulta que las X no están diseñadas para que el cliente y el servidor estén separados por las latencias de una wan por medio, por lo que aunque tengamos 1 giga de ancho de banda, nuestras aplicaciones X en remoto irán muy lentas, por eso... veamos que podemos utilizar para la parte gráfica...


Seguro que es el sistema más currado y más complejo para acceso remoto, soporta no sólo Linux, pero... si lo probáis veréis que hace muchas cosas por su cuenta sin contárnoslas, así que uno no deja de preguntarse... ¿para qué es todo esto? Lo tenemos soportado en Debian con paquetes tanto para hacer de servidor como para cliente, aunque ya os digo que a mi me pareció demasiado complejo y poco transparente.

Sin embargo si miramos debajo del capó vemos que utiliza la tecnología de NX que me parece más sencilla y entendible.


Se trata de una tecnología que nos permitirá la utilización de aplicaciones nativas X tal cual, se basa en la proxificación de los clientes X de modo que los eventos no tengan tanta latencia y por lo tanto todo vaya mucho más fluido. Además añadiremos un servidor X en el lado remoto que nos permitirá tener una mejor respuesta y sesiones permanentes.

Su uso es sencillo, veamos un ejemplo, la idea es que accedemos al sistema remoto via ssh -L 4008:localhost:4008 host.remoto (forwardeamos el puerto 4008 que usaremos para el proxy de NX que correremos con :8 o sea usando el puerto 4008) y allí ejecutamos un proxy al que nos conectamos desde localhost a través de este puerto que hemos forwardeado. Esa es la parte de proxificado, pero vamos a añadir el agente que lo que hace es añadir un servidor X local sobre que lanzaremos las aplicaciones X y que nos dará también una sesión permanente que nos permite desconectarnos y conectarnos cuando queramos, veamos esto:

Remoto: nxproxy -C :8 & Local: nxproxy -S localhost:8 & Remoto: nxagent -display nx/:8 -geometry 1276x976 :9 & DISPLAY=:9 startlxqt

En el ejemplo arrancamos el lxqt, pero se puede arrancar lo que sea. Esta sesión sera permanente, ya que como dijimos estamos arrancando un servidor X en el equipo remoto, en este caso el DISPLAY será :9, contra el que irán las aplicaciones X. Aunque apaguemos el equipo local, se corten las comunicaciones o lo que sea, podremos reconectar. Para esto sólo hay que rearrancar las partes del proxy remoto y local y luego avisar al nxagent de que queremos que nos vuelva a mandar el display utilizando por ejemplo:

killall nxagent -HUP


Que decir de VNC, ha estado ahí desde hace muchos años.

Tenemos el servidor al estilo windows, en el paquete x11vnc que podemos arrancar así:

x11vnc -rfbport 5900 -bg -o %HOME/.vnc/x11vnc.log.%VNCDISPLAY -rfbauth ~/.vnc/passwd -display :0 o el tigervnc-scraping-server que al igual que el anterior nos permitirá acceder vía cliente VNC a unas X que estén corriendo, aunque ahora tenemos también la extensión de X tigervnc-xorg-extension que nos dará la misma funcionalidad pero de una manera mucho más eficiente. Estos están bien para ver lo que hay en ejecución en la pantalla de un equipo y por ejemplo ofrecer ayuda remota.

Además tenemos el tigervnc-standalone-server y el tightvncserver que lo que nos permiten es tener todas las sesiones X que queramos (ya que no van atadas a nuestra gráfica ni nada) y accederlas en remoto vía VNC, y por supuesto varios clientes específicos de vnc como tigervnc-viewer y xtightvncviewer además de otros que soportan VNC y otros protocolos.

El handicap de siempre del VNC es que todo va en claro, nada va cifrado, así que necesita sí o sí de SSH o similar para cifrar los datos.


Este protocolo diseñado por Microsoft tiene ahora tanto servidores como clientes para Linux, requiere mucho menos ancho de banda que VNC y soporta diversos tipos de cifrado, tanto cifrado propio como incluso una capa de TLS.

Al igual que en el caso de VNC tenemos también servidores para acceso a un servidor X ya existente, como el freerdp-shadow-cli en el paquete freerdp2-shadow-x11. Lo podemos lanzar con esta orden para acceder a las X corriendo en :0:

DISPLAY=:0 freerdp-shadow-cli /port:12345

Ya sabéis, como en el caso del VNC, es muy útil para ayuda remota. Si bien es conveniente tener en cuenta este bug ya que hace que nofuncione la autenticación mientras que no lo arreglemos, así que o bien recompilamos o bien añadimos el parámetro -auth, pero entonces cualquiera que tenga acceso al puerto podrá tomar control de la sesión X.

También tenemos clientes como el clásico rdesktop o el xfreerdp del paquete freerdp2-x11 y otros clientes que soportan VNC, RDP y más, como vinagre, de GNOME o remmina.

Pero si lo que queremos es un acceso remoto a un entorno de trabajo Linux persistente tendremos que fijarnos en xrdp, todo un servidor rdp para dar acceso a tantas sesiones de escritorios Linux como queramos, estas sesiones serán permanentes y podremos conectarnos y desconectarnos de las mismas cuando queramos, además soporta sonido, aunque eso requerirá que compilemos los módulos siguiendo estas instrucciones, la reproducción de sonido es estándar, por lo que funcionará en cualquier cliente, pero si queremos mandar nuestro micro al server deberemos utilizar por ejemplo el paquete de rdesktop de buster (lo he probado y funciona) o algún otro compatible, ya que han hecho una implementación no estándar :-(

No voy a hablar de más protocolos (que los hay) pero si quería hablar de algo que me parece muy interesante, un potente cliente web de todos estos protocolos y más...


Esto si que no lo tenemos en Debian, aunque hubo algún intento de paquetización antiguo y probablemente os podáis encontrar todavía por ahí los paquetes viejos, no os los aconsejo porque tienen varios bugs de seguridad. Este cliente es bastante complejo, con diversas partes, basado en java, requiere al menos un tomcat para mover el servidor, ... pero a cambio tendremos acceso a servidores RDP, VNC, ssh, ... con seguridad de dos factores en varios estilos y colores y el cliente no necesitará nada más que un navegador web, algo que nos puede aligerar los requisitos para los trabajadores que tengan que acceder en remoto.

Bueno, eso es todo lo que se ocurre ahora mismo, podéis sugerir otras ideas en los comentarios.


sábado, 23 de noviembre de 2019


ING parece que quiere que todos los clientes tengan su app instalada y que operen a través de ella. La verdad, es mucha la gente que no trata su móvil como un elemento confiable, no le gusta tener nada que tenga que ver con los bancos en el móvil, tengo que reconocer que yo soy una de esas personas, por eso me he quedado de piedra cuando me he enterado de que ING ha mandado correos este día 20 a sus usuarios diciendo que o bien se instalan su app o no podrán operar a partir del día 25.

O Sea, resumiendo, que ING ha dado 5 días a sus clientes para que se instalen la app :-O Por lo que he podido leer luego parece ser que la cosa ya viene de antes, así que entiendo que este correo será la última advertencia antes de cortarles el acceso.

Me he puesto a analizar un poco el tema este de la app de ING y me pregunto hasta que punto cumple con la PSD2, es decir, la PSD2 se supone que es para hacer más seguro el acceso, todo el mundo habla de un segundo factor de autenticación, lo que está muy bien, entiendo que tenga que tener una APP porque no quieren pagar por los SMS, pero lo que no entiendo es que para entrar en dicha APP tenga que meter todos los factores de autenticación que tengo con el banco, que en el caso de ING vienen siendo el DNI y la fecha de nacimiento (dos datos que si bien no siempre son públicos son muy fáciles de obtener) además de una clave de 6 caracteres numéricos.

Hace años que me pregunto que tipo de gente lleva la seguridad de los bancos, con ING ya he tenido mis problemas, dado que el correo que uso sólo con ellos acabó en manos de spammers, como le ocurrió a alguna otra persona que también contactó con ING y que obtuvo la misma respuesta que yo, o sea, que no era culpa de ING, que ellos no habían sufrido ningún tipo de fuga de información.

Todo esto es un despropósito monumental, tanto es así que no sé que más añadir, así que expondré yo como haría que la APP fuera un segundo factor de autenticación válido y seguro para que la gente que como yo no nos fiamos de la seguridad de nuestros juguetes, no huyéramos del banco por este tipo de acciones temerarias.

La app no es el problema, el problema es que te pide los mismos datos que la web, por lo que no sirve para mejorar la seguridad, al contrario, la debilita. Pero si en lugar de pedirte la clave y todo esto, hacemos que nos pida sólo el DNI, y que luego tengas que introducir en ella un código que se nos de en la web o similar, dejando esta instalación de la APP unida a ese usuario (con criptografía fuerte y tal y tal), tendremos un canal seguro para que el banco pueda mandar a este usuario su segundo factor sin gastar un duro y sin que este usuario tenga que poner en jaque la seguridad de su cuenta por la instalación de la app en un sistema que al menos en mi caso considero menos seguro que los ordenadores donde accedo a los bancos.

En fin, señores de ING, parece mentira que lleven tanto tiempo en esto y sepan tan poco de sus clientes o de la gente en general, mezclar los juguetes con la seguridad electrónica... no parece una buena idea, y mucha gente considera que sus móviles están bien para jugar, divertirse, ... pero ya tienen demasiados datos nuestros como para aún encima poner los del banco, mala idea, denle otra pensada al tema y luego hablamos.


martes, 10 de septiembre de 2019

mdadm: how to add a disk to do a replacement

When playing with two disks raid 1 devices it is typical that when one drive fails you just remove it and replace it with a new one and that's it.
But... what if the drive that is left finds an error when you are reconstructing the array? Then... you have a problem.
So when replacing a disk that is starting to fail... it would be better to use the two disks instead of just discarding one.
Luckily the Linux software raid system allows you to add a third disk and sync the array to this disk from the other two, this way, you have two disks to feed the new one and if you are lucky enough you get a good copy of each of the sectors of the raid 1 array to finish the job.
The commands to do this would be... first to add the new disk:
mdadm --add /dev/md1 /dev/sdc1 which just adds it as an spare, but then you tell Linux you want it to use the three disks as active disks like this: mdadm --grow /dev/md1 -f -n 3 When this finishes you should have all the three disks on the array being active, or maybe you get failed drives in the way, but hopefully you get the new drive with a full copy of the data, so... all you have to do is get back to the two disks setup, for this if you don't have the failed drive marked as such... you fail it: mdadm --fail /dev/md1 /dev/sda1 and then you remove it from the array like this: mdadm --remove /dev/md1 /dev/sda1 and put the array in the two disks mode like it was before: mdadm --grow /dev/md1 -f -n 2 And that's it :-)
All this commands were tested on a Debian 10 (Buster) setup, hope they help you.

miércoles, 31 de julio de 2019

Tiempos de "fontanería" (grifos termostáticos y más)

Parece que estamos en esa época del año en la que me toca lidiar con este tipo de cosas, esta vez ha tocado cambiar un grifo de cisterna, cambiar un grifo de bañera por uno monomando y por último "arreglar" un grifo termostático.

Si el finde pasado disfruté de la ducha en la bañera de la aldea luego de haber sustituido el viejo grifo por un monomando que además va a evitar que tiremos agua y hacer que cualquiera pueda cerrarlo, no os quiero contar lo que disfruté de la ducha de hoy luego de llevar una temporada casi escaldándome en la ducha de casa porque el termostático no funcionaba como debiera.

No os voy a mentir, el tema del termostático me tenía un poco acojonadillo porque nunca había desmontado ninguno, este era en una columna de ducha que uso a diario, por lo que si tardaba en conseguir repuestos me quedaba sin servicio en ese baño, en fin... que luego de ver unos videos en youtube explicando como se limpia, como se desmontan por dentro (este se parece bastante al mío) y sobre todo ver en una columna como se saca y que en aliexpress (no se me había ocurrido) hay bastantes modelos genéricos...

Ayer me dispuse a ello, saqué el cartucho, lo desmonté, metí todas las piezas en agua con vinagre al 50% (respetando lo de la media hora máximo para no estropear las juntas) y luego cepillo de dientes y tal para quitar toda la suciedad de 10 años de uso. Luego montar y dar vaselina a todo y probarlo, milagrosamente eso fue todo, ¡funcionaba!

Esta mañana por fin pude darme un ducha un poco fresquita que acompañase al veranillo y tal, no veas como se agradeció el trabajo de ayer y sobre todo lo poco que costó al final eso que me parecía tan difícil, la verdad es que pensaba que lo mínimo iba a ser cambiar el cartucho, pero al final ya véis, con una limpieza.... listo.