viernes, 28 de febrero de 2014

PBX: Music On Hold en extensiones virtuales

Como los asiduos a este blog ya sabréis, estoy embarcado en temas de VoIP. Y, resulta, que había algo que quería hacer y me estaba costando un rato conseguirlo. No está del todo terminado, pero puedo adelantar las bases de lo que he tenido que hacer por si alguien lo necesitaba. Además, he tenido que hacer unos cambios con respecto a las fuentes, dado que cuando éstas se escribieron se hacía de otra manera.

Lo primero de todo: quiero que al llamar desde una extensión de mi centralita a otra extensión, ésta se comporte de una manera determinada. En mi caso, quería que sonase una música en espera y si después se desea, que suene alguna locución.

Lo primero que vamos a necesitar es crear una nueva extensión. En mi caso he querido que fuese virtual, porque no quiero que ningún terminal la utilice. Seguro que hay otras maneras de hacerlo. A lo mejor una de estas no es la más idónea. La monté en su momento pensando que podría hacerlo en 3 minutos y no fue así. Por lo tanto: crear una nueva extensión. En este caso tendrá que ser virtual. A la hora de rellenar los datos, pondremos:

  • El número de extensión
  • Display name: Será la descripción o nombre. 
  • Aunque posiblemente no haga falta, también le he rellenado el outbound cid con el mismo dato que el display name.
  • En recording options, las inboud [internal|external] calls también las vamos a activar siempre. Sin embargo, tengo que jugar con esto. José Luis (Verdeguer, aka Pepeluxx [@pepeluxx]), me pasó un script y tengo que jugar con él. 
  • El voicemail lo activas y se pone una contraseña. 

Ahora sí: tal y como lo tengo, creo que sólo va a servir el número de extensión asignado. Todo se andará.

Muy bien. Ahora quiero que haga ciertas cosas. Y si intentas configurar la música en espera (music on hold, o también conocido como MOH), y llamas directamente, te saldrá alguno de los contestadores diciéndote que no está disponible en esos instantes. Pues, dio la casualidad que atiné en una de las búsquedas que hice y encontré una solución:

[from-internal-custom]
exten=>383,1,Answer
exten=>383,2,Wait(1)
exten=>383,3,Background(tt-allbusy)
exten=>383,4,SetMusicOnHold,default
exten=>383,5,WaitMusicOnHold,30
exten=>383,6,Background(thank-you-for-calling)
exten=>383,7,Background(goodbye)
exten=>383,8,Congestion
exten=>383,9,Hangup


Fundamentalmente: abres el fichero que se encuentra en /etc/asterisk/extensions_custom.conf y, si no existe la primera línea se añade, si exite, se ponen el resto de líneas debajo de ésta.


Estupendo. Ahora que ya lo he guardado, cojo y ejecuto:


#asterisk -r
#core restart now


Por lo que he reiniciado el servicio de la centralita. Al menos, como es mía y sólo estoy yo, me puedo permitir hacerlo. Además, podría caber la posibilidad de que hubiese otra forma, pero a mí, ahora mismo, me vale. ¡Ojo! Que si tienes gente conectada a la tuya, podrías finalizar sus llamadas. 

Ahora, haces una prueba y... Sólo oyes la primera locución. Las demás... Nada. Si vas a los logs de las llamadas, podrás ver algo como esto:

No application 'SetMusicOnHold,default' for extension (from-internal, 383, 4)

Esto viene a decir: No entiendo qué significa "SetMusicOnHold,default" para la extensión que se encuentra en "from-internal, número_de_extensión, comando_número_4".


Si se busca esto, no lo va a ser capaz de ejecutarlo. De hecho, la llamada terminará abruptamente. ¿Cómo lo solucionamos? Pues  buscando un poco nos encontramos con que está deprecado (deprecated). 

Tendremos que ejecutarlo así:

[from-internal-custom]
exten=>50000,1,Answer
exten=>50000,2,Wait(1)
exten=>50000,3,Background(tt-allbusy)
exten=>50000,4,MusicOnHold(default,30)
exten=>50000,5,Background(thank-you-for-calling)
exten=>50000,6,Background(goodbye)
exten=>50000,7,Congestion
exten=>50000,8,Hangup

Ahora sí que conseguiremos que funcione todo el proceso. Pero sigue habiendo algunos puntos que tenemos que corregir. Por ejemplo: El comando (internamente me ha parecido ver que lo llaman aplicación), background. Éste se va a encargar de mostrar una locución y, a la vez, será capaz de entender los códigos que se introduzcan por teclado. Pero a mí no me interesa eso. Yo quiero que suene el audio que toque (por ejemplo, una voz pidiendo que esperes) y ya. Para eso está la opción de playback. Por eso, vamos a cambiar el primero por este segundo. Aquí dejo un enlace sobre las diferencias. Aunque, a decir la verdad, me gustaba más el anterior que encontré (y no sé dónde está).

Cuidado con no poner alguno de los pasos, o repetir el número en alguno de ellos. El comportamiento será algo curioso (tendría que haberlo apuntado!!). 

Podemos ver que ahora la opción de la música en espera es un sólo comando, al cual, se le pasará el nombre de la sección de la música en espera que deseas que suene y qué tiempo quieres que dure. Está en segundos. Si no lo he entendido mal, si no se pone el tiempo, esto sonará hasta que se termine el audio (una canción, por ejemplo). Lo que he llamado sección se encuentra en la interfaz web, en el menú de Settings, Music On Hold. Como puedes ver tenemos uno que se llama default. Este es el que nos sonará. Pero si quieres subir otra, mi recomendación a día de hoy, que no se cómo elegir alguna de las que están agrupadas, es crearse una por cada canción. El día que sepa cómo se puede escoger, aviso. 

Por lo tanto, y para resumir:
- El sistema descuelga la llamada
- Espera un segundo (no se si habrá algo más entre medias)
- Suena un audio solicitando que esperes, que todos están atendiendo otras llamadas de telemárketing.
- Música en espera para que te acomodes (o cuelgues si te cansas).
- Dos locuciones más.
- Unos pitidos como que la línea está ocupada
- Te cuelgan.

Poco a poco intentaré ir afinando el sistema. Además, como habéis podido observar, parte de la configuración la he hecho tirando de interfaz gráfica y otra parte ya me he animado a hacerlo editando ficheros (que no se verán modificados automáticamente en cuanto menos me lo espere).

miércoles, 26 de febrero de 2014

Mostrando código fuente en Blogger I

Algunas veces me ha tocado mostrar código fuente aquí en el blog. Y me he encontrado con el problema de formatearlo bien. Estuve buscando algo y me encontré con este pequeño manual para conseguirlo.

Si se siguen los pasos tan sencillos que muestran, se conseguirá que al menos el código no quede un poco chapucero. Al menos para mostrarlo al público. Porque lo que es incrustarlo aquí sigue siendo un poco infierno. Ya me está costando copypastear y dejarlo bien...

Pero, una pequeña prueba de concepto (para que la veáis, que ya la usé hace poco), no se vería igual que pusiese:

printf("Hola mundo!!! Dime algo");
scanf("%s",&a);
printf("Gracias por decirme: ", a);

Que poner:
printf("Hola mundo!!! Dime algo");
scanf("%s",&a);
printf("Gracias por decirme: ", a);

Por lo tanto, recodermos:

[pre class="prettyprint"]
[/pre]

Es lo que tendremos que poner cuando toque introducir algún tipo de código, como por ejemplo, scripts. O, incluso, a lo mejor me planteo también ponerlo para el contenido de ficheros de configuración. ¡Ah! No os olvidéis de cambiar los corchetes por los signos de "menor que" y de "mayor que". Que aún no he visto cómo evitar que me los interprete. 

lunes, 24 de febrero de 2014

USB bootable

Este va a ser corto. Además, seguro que unos cuantos ya lo conoceréis. Se trata de montar un pincho USB para que sea bootable. Dicho de otro modo: para poder hacer que un USB pueda arrancar el sistema.

Este pasado fin de semana he necesitado montar uno. El consejo de la herramienta que necesitaba utilizar era tirar de un programa que se llama Rufus. La cosa es muy sencilla. Cogeremos un pincho que no necesitemos, puesto que perderás toda la información que contenga.

Ahora, ejecutamos este programa, el cual nos ofrecerá las distintas opciones:

Rufus: usb arrancable
Rufus: usb arrancable
No tiene mucho misterio.
  • Dispositivo: Es la unidad USB a la que le vamos a aplicar la opción para que sea bootable
  • Etiqueta nueva: Será la que le asigne, tal y como se puede ver en la lista del nombre de dispositivo.
  • Tipo de partición: Tengo que ponerme al día con esto: La opción seleccionada, MBR con sólo UEFI ó GPT con UEFI.
  • Sistema de archivos: FAT, FAT32, exFAT, NTFS o UDF. A elección del consumidor. Yo dejaría, como mínimo, alguna de las opciones relacionadas con FAT.
  • Tamaño del cluster (o bloque): Yo lo dejaría tal cual.
 Aunque yo lo dejé tal cual, te permite analizar la unidad para ver si tiene errores. 

Ya sabemos que el formateo rápido lo único que hace es cargarse la tabla de índices de los ficheros. Si no lo marcamos, tirará por toda la unidad. 

Yo lo utilicé para que arrancase con FreeDOS. Pero lo que me parece muy interesante es que se puedan cargar imágenes ISO. Ya jugaré con esto cuando pueda. La otra opción se ha quedado cortada: "añadir etiquetas extendidas e iconos". Ni idea, la verdad. 

Y... Ya está. Porque las demás cosas que salen al selccionar "opciones de formateo", bajo el título de "opciones avanzadas" no las he tocado (y acabo de ver que existían). Es más, al mostrarlas, el combo del sistema de arranque (DOS, FreeDOS, etc), se extiende. 

Como digo, ya jugaré un poco más con todo esto. 


miércoles, 12 de febrero de 2014

Perl: Averiguar si FreePBX está actualizado

Hacía tiempo que no volvía con los temas de FreePBX. Como habréis podrido observar, le he dado un descanso.

Si recodáis, uno de los posts que escribí fue sobre el script que montó Pepelux (Jose Luís Verdeguer), en el que analizaba la configuración de la instalación que se tenía. Así, se podía saber si había algunos valores por defecto o alguna cosa que era recomendable cambiar.

Una de las cosas que se me quedó a medias fue el averiguar si teníamos instalada la última versión. Se me quedó en el tintero porque no fui capaz de dar con la clave adecuada para sacar el dato utilizando perl. Pues bien, hace poco lo conseguí. Y este es el resultado. ¡Ojo! Que en mi caso lo tengo montado en el script original. Recordemos que tocó ajustarlo porque esta instalación es una RasPBX (el cual se sustenta de FreePBX) y en vez de tirar del gestor de paquetes Yum tira de APT.

#!/usr/bin/perl
# -=-=-=-=-=-=-=-=-=-=-=
# FreePBX Security check
# -=-=-=-=-=-=-=-=-=-=-=
# Original author:
# Jose Luis Verdeguer (aka Pepelux)
#
# 
#
# Author:
# Agustín Campos (aka Agux)

sub init() {
    die("You must be root to run this script!\n\n") if (getpwuid($<) ne "root");

    my $ver = version();
    my $last_ver = '2.11';
    print "Warning! Your FreePBX version is too old ($ver). Consider upgrading your system\n" if ($ver < $last_ver);
    print "Your FreePBX instalation is up to date" if ($ver = $last_ver);

    print "\n";
    unlink "/tmp/fpbx.version";
}

sub version {
        system("dpkg -s freepbx | grep 'Version' > ./fpbx.version");
        my $version_file = "./fpbx.version";

        open (FILE_VER, $version_file);

        while () {
                #'chomp' clears the newlines characters
                chomp;
                my $aux = $_;
                $aux =~ /Version\:\ \s+\t+([\-|0-9|\.]*)\s+\t+/;
                $aux =~ s/Version\:\ //;
                close (FILE_VER);
                return $aux;
        }
        return "";
}

init();

Se que debería de buscar algún tipo de else para el caso en el que la versión sí que esté actualizada, pero como ya he comentado, realmente el cambio que habría que hacerle al script original es:


  1. El método version ponerlo tal cual está está aquí.
  2. Si no recuerdo mal, en el original se hacía la comparación de la llamada al método directamente con la cadena de la versión que tenemos instalada. En mi caso, he asignado a dos variables los valores correspondientes y he comparado dichas variables.
Esos serían los cambios que habría que hacer con el original para esta distribución.

lunes, 10 de febrero de 2014

Fabrica tu propio router con Gentoo y Debian

Hace tiempo... Mucho, mucho tiempo... Tenía un equipo, como dicen en inglés, headless.  Es decir, sin monitor. Típico ordenador que se deja en un rincón. Y, lo convertí en un router. La verdad, ahora mismo no lo tengo ni montado. Algún backup seguro que tengo. Pero tendría que buscarlo. Y muchas cosas de las aquí contadas están escritas de memoria, con alguna mirada al manual, pero tendré que montar una máquina para probarlo.

A lo que iba. Me monté un router con un PC. ¿Cómo lo hice? Pues, tendré que hacer memoria. Pero, como en esa época utilizaba Gentoo, es el sistema operativo que uilicé. Por lo tanto, me hacía una búsqueda parecida a

howto router gentoo

teniendo dos posibilidades, la inglesa o la española (ojo! es una traducción de la inglesa: el contacto que han puesto en la versión española no habla español [o no lo hablaba]).

Pero, hay que tener en cuenta una cosa: el router que proponían era para dar acceso a internet.  Como si quisíeramos sustituir el de Telefónica por el nuestro. Nosotros lo vamos a poner entre medias de ese router y nuestros equipos. Por lo tanto, hay que realizar unos pocos cambios a las propuestas que nos hacen en ese HowTo.

Este post lo estoy reescribiendo. Tenía pensado poner más o menos lo que hice en su momento, y lo tenía paralizado. Hasta que este fin de semana he tenido que montarme uno, y he decidido terminarlo poniendo lo que he utilizado, que tiene alguna que otra diferencia de lo que hice en su momento. Pero, lo que hecho ha sido utilizar los manuales de Gentoo en una Debian.

Vamos a ponernos en situación: te pasan un ordenador de sobremesa y tienes que enchufarlo a los perifericos. Pero, el lugar donde los tienes es otro PC Por lo tanto, lo que vas a hacer es conectar un switch KVM (Keyboard Video Mouse), de tal forma que podrás utilizar los mimos perféricos para dos ordenadores y así ir alternando entre ambos. Después, utilizarás un cable de red cruzado para que ambos ordenadores estén conectados por red.

Ahora, configuraremos el ordenador principal, que tienes una Debian instalada.  Lo primero es ponerse en situación: un ordenador que tiene su tarjeta de red inalámbrica (wlan0), que es la que le da conexión a internet como cualquier otro equipo. Por lo tanto, estará configurada tal y como lo hicimos en reyes.

La segunda tarjeta de red sólo la configuraremos en el mismo instante en el que vamos a utlizarla. Por lo que vamos a lanzar ifconfig:

ifconfig eth0 192.168.2.1 netmask 255.255.255.0 up

Esta tarjeta de red será la que haga de gateway.

Después, lancé una serie de parámetros para iptables. Al final, después de varios chascos metiéndolos a mano y que no me funcionase, acabé montándome el script:

# Limpieza total de todas las reglas: se pierde toda configuración existente
iptables -F 
iptables -t nat -F

# Reglas por defecto cuando las reglas explicitas no se cumplen
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT 
iptables -P FORWARD DROP

#Variables de entorno:
export LAN=eth0
export WAN=wlan0

# Para que los servicios sólo funcionen desde la LAN
iptables -I INPUT 1 -i ${LAN} -j ACCEPT
iptables -I INPUT 1 -i lo -j ACCEPT 

#Serivicios del los puertos 67 y 53 (entre otros, los utilizados por los boot-pe)
iptables -A INPUT -p UDP --dport bootps ! -i ${LAN} -j REJECT 
iptables -A INPUT -p UDP --dport domain ! -i ${LAN} -j REJECT

#Ejemplo para aceptar servicios desde la WAN: apertura de puertos
iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

#Tira los paquetes TCP y UDP para los puertos entre 0 y 1023:
iptables -A INPUT -p TCP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP
iptables -A INPUT -p UDP ! -i ${LAN} -d 0/0 --dport 0:1023 -j DROP

#Reglas NAT:
iptables -I FORWARD -i ${LAN} -d 192.168.2.0/255.255.0.0 -j DROP
iptables -A FORWARD -i ${LAN} -s 192.168.2.0/255.255.0.0 -j ACCEPT 
iptables -A FORWARD -i ${WAN} -d 192.168.2.0/255.255.0.0 -j ACCEPT 
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

#Configurar el kernel para que el ip forwarding funcione:
echo 1 > /proc/sys/net/ipv4/ip_forward 
for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do echo 1 > $f ; done

#Guardar los cambios. En Debian, es mejor utilizar la que no está tachada:
/etc/init.d/iptables save  
rc-update add iptables default
iptables-save

#Abrir el fichero /etc/sysctl.conf y cambiar los valores a lo siguiente:
net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1 

Con todo esto, y teniendo configurada la tarjeta de red del equipo con el que vas a trabajar (porque, ten en cuenta que estamos trabajando con direccionamiento estático, y que [si no recuerdo mal], los paquetes DHCP están incluidos en los que estamos tirando), podrás acceder a la red principal. En mi caso, quería poder acceder a internet. Pero, algo que se podría hacer es, por ejemplo, y escrito así a bote pronto:

iptables -A OUTPUT -i ${LAN} ! --dport 80 -j DROP

Así, si hubiese alguna conexión que tuviese que salir y no fuese para http, se tumbaría.

No estoy muy seguro de si me acordaré de cómo lo hice, pero ya veré si encuentro algún sitio donde contaba cómo montar un spamassasin y pop3-scan (o algo parecido): un proxy para correo.


viernes, 7 de febrero de 2014

Modo recovery en Cyanogen 10.2.1

Como ya sabéis, el otro día tuve que reinstalar mi móvil. Le puse la Cyanogen 10.2.1 estable. Pero, me he encontrado con que a la hora de reiniciar ya no me salen las opciones de seleccionar si quiero hacerlo normalmente o en modo recovery. Bien. Me he puesto a buscar y he encontrado la solución. ¡Ojo! Que algún cambio posiblemente no se pueda echar para atrás.

Tenemos que ir al menú ajustes. Desde ahí, visitaremos la sección información del teléfono. Tendremos que seleccionar el build de la instalación, lo que en español pondrá como número de compilación. Ahora, haremos "click" 7 veces. Y esa es la cosa que no creo que se pueda deshacer. Ahora que hemos hecho esta operación, hemos activado el modo desarrollador.

Salgamos de este menú, pero sigamos en ajustes. Visitemos opciones de desarrollo. Mucho ojo con lo que se toca, que se podría liar parda. Ahora tendremos que marcar el checkbox de la sección que dice reinicio modo avanzado.

Ahora, si le damos al botón de encendido y apagado del terminal, cuando nos ofrezca reiniciar, podremos ver que ya podremos elegir si queremos reiniciar en modo normal o en recovery.

No voy a negar que ahora mismo me hace falta esto porque ya no soy capaz de lanzarlo con la combinación de botones. Pero bueno...

Por cierto: dos fuentes de donde he sacado el manual:


  1. http://code.rawlinson.us/2013/05/enable-advanced-reboot-options-on.html: dice que hay que buscar debajo de interfaz. En mi caso no hace falta, y eso que lo he buscado. Además, no hay forma de poner el modo bootloader (¿será el download?)
  2. https://plus.google.com/+CyanogenMod/posts/iWRWc4bdXJb: Razones por las que han hecho este desaguisado.

lunes, 3 de febrero de 2014

El móvil se reinicia constantemente

¡Ojo! Cualquier cosa que hagas aquí puede empeorar el estado de tu dispositivo. Atente a las consecuencias  que yo no seré el responsable. Si lo vas a seguir, te recomiendo que te lo leas entero, te hagas un croquis y después, si tienes ganas, ya hacer estos pasos.

Ayer jueves 30 de enero de 2013 me sucedió lo siguiente: estaba dándole al móvil en el tren de camino al trabajo, leyendo los feeds que tenía pendientes, enviando algún que otro tweet al respecto, cuando el sistema empezó a cerrarme el gReader, mi lector de feeds. Tras varios intentos de volverlo a abrir, decidí que iba a ser mejor reiniciar. ¡Mala decisión! Desde entonces no ha vuelto a ser el mismo. :(

Justo cuando estaba reiniciando, la pantalla con el hombrecito azul de CyanogenMod, el splash del sistema, se quedaba ahí, moviéndose como siempre lo hacía, pero esta vez in eternum.

Splash del CyanogenMod instalado en mi móvil
Splash del CyanogenMod instalado en mi móvil
Después de muchos intentos de intentar acceder al modo recovery, no lo conseguí. Hasta que un buen compañero de curro me advirtió de que estaba haciendo mal las combinaciones de teclas: Vol-up + home + [encendido]. Sólo conseguí acceder unas pocas veces las cuales vacié las distintas cachés que se me ocurrieron. Pero algo hice mal, o lo que sea, que ya ni siquiera me sale esta pantalla. Pero, hay otra cosa más que sí que conseguí hacer antes de llegar al modo recovery y que aún puedo hacer: es entrar en el modo download: mientras le das al botón de encendido (mejor, que este sea el último en darle), aprieta: Vol-down+home. Y me sale el modo download:

Download mode
Download mode
Según he podido averiguar, en este modo es como hay que ponerlo para que el software de actualización del sistema Odín pueda realizar sus tareas. Pero antes de machacar todo el sistema, quiero probar otra cosa. Porque según he podido averiguar, hay otro modo que se llama fastboot, que es similar al download, pero con más cosas. Y que me podría ser mejor. A ver si puedo saltarme el proceso de reinstalar.

Además, si por un casual no puedes acceder a este modo, he visto una serie de vídeos en youtube que te ofrecen montarte un micro-usb que hará que entre directamente en este modo. Busca: usb jit samsung y los verás. Según dicen es sencillo: 3 resitencias de 100 kilo-ohmios, para 0,25wa cada una de ellas y... Bueno. Mira los vídeos y a ver si te sale. 

Como podréis comprobar, estoy escribiendo esto a medida que voy probando cosas.

Una de las primeras cosas que he querido hacer ha sido mirar si utilizando el comando adb, que se encuentra en el paquete de las SDKs de android, podía acceder al sistema o forzarle a reiniciarse. Todo esto, evidentemente, estando en el único modo que se puede encontrar: modo download. Pero como no me encuentra el dispositivo, de momento no he podido tirar por aquí.

Voy a tirar por una herramienta que están recomendando ahora en el wiki de CyanogenMod: Heimdall. Sólo hay que descargarlo y descomprimirlo.

He hecho una cosa que no he me ha hecho mucha gracia, pero bueno, de perdidos al río. Después de aplicar su programa zadig.exe para actualizar o cambiar el driver (con el riesgo que ello conlleva), he querido tirar directamente de la línea de comandos del propio heindall pero no ha sacado la información esperada. Para resumir: ejecutamos el heimdall-frontend y vamos a utilities:

Heimdall-Frontend: utilities
Heimdall-Frontend: utilities
En este caso he podido encontrar distintas particiones o entradas. Algunas llaman la atención como la que hace referencia a RECOVERY o FACTORYFS. Al menos puedo ver que hay forma de sacar algo de información estando en este modo.

Voy a tirarme a la piscina: voy a poner un recovery.img obtenido de la ¿distribución? Replicant. A ver si hay suerte y así puedo acceder otra vez al modo recovery. Si no fuese así, buscaría la forma de poder poner o configurar el bootloader (o buscar a ver si hay algo que le haga referencia junto con esta herramienta). En última instancia, haría una reinstalación perdiendo todos los datos. 

Muy bien, dos noticias: la mala es que por interfaz gráfica no me ha funcionado:

Heimdall: flashing desde entorno gráfico

Fundamentalmente: se selecciona el fichero PIT de antes. Se busca la imagen que vamos a flashear. Después, seleccionamos la partición deseada en el combo y al hacer click sobre el botón add se queda seleccionada. Después puedes ir repitiendo el proceso con el resto de particiones con sus respectivas imágenes. El botón remove quita la modificación de la partición seleccionada. Al hacer click sobre el botón start comienza el proceso. Pero a mi no me ha funcionado.

Ahora, si se hace con el modo consola, ha reaccionado bien, pero tampoco he avanzado en mi problema:

heimdall flash --RECOVERY rutaImg.img
Donde --RECOVERY es el nombre de la partición deseada a la que le vamos a flashear la imagen.

Este no me ha funcionado. Lo que he hecho ha sido bajarme el fichero de semaphore al que hace referencia el manual de Cyanogen. Lo he lanzado desde la interfaz gráfica, ya que esta vez el cmd no ha funcionado. No tiene sentido, lo se. Pero estoy intentando recuperar el móvil. De todas formas, cada vez me dá la sensación de que ya lo he perdido todo y que lo más sencillo sería reinstalar (ya de paso, poner una versión superior a la que tenía). 

Por lo tanto: después de aplicar el contenido del zip de semaphore al KERNEL (repito: KERNEL), se consigue:
  • Que ya no aparezca el screen que aparecía del cyanogen anterior (lo que me ha hecho sospechar que lo he perdido).
  • Que apretando los botones VolUp+Home+Encendido (esto último lo he hecho a ver si colaba). A los pocos segundos me ha salido el recovery. Con errores, pero me ha salido (que ya es un avance).
Errores que muestra:

E:failed to open /etc/recovery.fstab
E:unkown vlolume for path [/cache/recovery/command]
E:Can't mount /cache/recovery/command
E:unkown volume for path [/cache/recovery/log]
E:Can't mount /cache/recovery/log
E:Can't open /cache/recovery/log
E:unknown vlolume for path [/cache/recovery/last_log]
E:Can't mount /cache/recovery/last_log
E:Can't open /cache/recover/last_log
E:unknown volume for path [/cache/recovery/command]

Por lo tanto, vamos a ver si hay algo que se pueda hacer para lanzar el sistema. Que no pueda hacer cosas con los logs lo arreglaré más tarde.

 Dando la recuperación total por perdida, voy a hacer la instalación de la última versión estable del sistema. Tocaré madera para que los datos de la tarjeta sd interna estén intactos, aunque lo dudo mucho. Música, fotos, vídeos... Al menos hace poco se me ocurrió cogerme bastante datos del móvil. Pero había cosas que sí que tenía interés en mantener, sobretodo las que procedían de ciertas aplicaciones.

Hay que conseguir pasar el fichero de instalación al dispositivo. Y como también está dando problemas el montaje de la sdcard interna... A ver qué encuentro para solucionarlo.

Alguna cosa he podido encontrar como que a veces se hace una especie de USB brick. Como no consigo que mi Windows reconozca el móvil para utilizar los comados adb y fastboot, voy a enchufarlo a otro ordenador con una debian y que le he instalado las herramientas android-tools-fastboot, android-tools-adb y android-tools-fsutils. Esta prueba tampoco me ha salido. 

Como tengo descomprimido el fichero de instalación que utilicé la anterior vez, he querido ver si enchufando el fichero boot.img que está dentro del zip puedo avanzar en algo, peo como se queja de que espera un fichero boot.bin voy a pasar. Eso sí, parece ser que hay quien dice que el loop en el arranque se puede solucionar cambiando el nombre de ese fichero por zImage y sustituir la parte de KERNEL tal y como he hecho antes. Si me fallase, volvería a poner el RECOVERY. Es más, voy a poner los dos a la vez para evitar tener que estar reiniciando y esas cosas. ¡Avance! Esto va en marcha: Después del proceso se ha reiniciado (como era de esperar), ha salido el logo de Samsung + Cyanogen y ha saltado directamente al recovery sin dar ningún mensaje de error. Creo que la versión del recovery es un poco anterior a la que me salía antes, pero esta vez no me muestra ningún fallo (de momento).

Bueno. A estas alturas no he conseguido recuperar el sistema tal y como lo tenía. Para que se entienda, se ha quedado como cuando tienes que tumbar el sistema del ordenador que, gracias a las particiones, tus datos quedan a salvo. Por lo tanto, y ya que parece que hay que reinstalar, subiré la última versión de Cyanogen para mi móvil. Para subirlo, y no me preguntéis por qué, ha funcionado el comando adb que se encuentra en la carpeta platform-tools del paquete de las SDKs de Android. El móvil está arrancado en el modo recovery. Si no tienes las SDKs en el PATH de tus variables de entorno, tendrás que irte directamente a la carpeta antes mencionada para ejecutarlo desde ahí:

adb push rutaFicheroROMParaInstalar/ficheroParaInstalar.zip /sdcard/

Tardará un poco. Nada unos dos o tres minutos, y ya es decir mucho. Ahora, con el fichero ya subido, podremos navegar por el menú, en el siguiente orden: 
  1. install zip from sdcard
  2. choose zip from sdcard
  3. Busca el fichero que acabas de subir, que se encontrará en la raiz (irás más rápido si pulsas el volúmen hacía arriba desde el principio, que te llevará a la parte de los ficheros que están en raíz y no tendrás que pasar por todos los directorios. 
  4. Cuando lo hayas seleccionado, confirma que vas a hacer la instalación.
Y... la primera vez que lo he lanzado ha fallado. La segunda vez que lo he lanzado no se ha quejado, pero al reiniciarse me ha vuelto a llevar al recovery, que se ve distinto al que estaba usando justo antes de reiniciarse. Volveré a probar a lanzar otra vez el instalador. Esta tercera vez está tardando bastante más. Hay que reiniciar a través del menú ya que no lo ha hecho por su cuenta. Otra vez en el recovery.

Hay distintos ejemplos para intentar solucionarlo, pero, en mi caso, aún no ha funcionado (sigo sin poder arrancar bien el teléfono):

adb reboot [bootloader|recovery]

Una de las dos opciones serviría, pero hace lo mismo. Lo que me indica que, o el bootloader está muerto y se está tirando de la siguiente opción o el bootloader es el mismo que el recovery. Y ya he intentado poner el boot.bin (renombrando el boot.img) pero nada.

La otra opción es ejecutar:

adb shell
echo boot | dd of=/dev/block/mmcblk0p3 bs=1 seek=0

Pero tampoco.

Tampoco ha funcionado intentando utilizar el Heimdall de distintas formas cambiando alguna de las particiones de antes por otras. Es más. Un detalle curioso: cuando tengo el móvil apagado y lo enchufo al USB, también se carga el recovery después de salga durante unos segundos una pila en la pantalla.

Vale. Esto es lo que he hecho: he flasheado otra vez el KERNEL de nuevo, y varias veces, en el siguiente orden:

  1. El semaphore: que, otra vez, al cargar el sistema, sale el recovery antiguo que no encontraba las carpetas y ficheros. 
  2. He cargado el boot.img de la última distribución que tenía instalada antes de instalar la última versión que me dio por cogerme (la estable), pero renombrándolo a zImage. Tampoco, la carga se paraba. Se me está ocurriendo que a lo mejor de haber hecho esto lo primero lo podría haber recuperado. Pero ya...
  3. Por último, he hecho lo mismo pero con, ahora sí, la última versión estable que me he bajado para tal efecto. Y, ahora sí que sí, ha arrancado (dado que el sistema en teoría ya estaba instalado desde hacía un buen rato).
En fin. Voy a ver si soy capaz de ponerle algunas cosas antes de irme a la cama, que empecé a escribir esto el viernes y estamos a domingo por la noche. 


Enlaces interesantes que he ido visitando (y que quiero conservar):

http://wiki.cyanogenmod.org/w/All_About_Recovery_Images
http://wiki.cyanogenmod.org/w/Fastboot
http://forum.cyanogenmod.com/topic/73505-cant-repair-bricked-i9000-with-odin-or-heimdall-or-adb/
http://forum.cyanogenmod.com/topic/58791-device-reboot-to-recovery-cm10/
http://forum.xda-developers.com/showthread.php?t=999097
http://glassechidna.com.au/heimdall/
http://android.stackexchange.com/questions/48417/cannot-boot-into-recovery-samsung-galaxy-s
http://androidforums.com/desire-all-things-root/579026-desperate-can-not-flash-rom-e-cant-mount-scard.html
http://androidforums.com/desire-all-things-root/503471-desire-all-things-root-guide.html