He estado mirando el script que comente en el post anterior y la cosa se va aclarando poco a poco. Según pone en las instrucciones de ese script, es válido para aparecer como activo en maps.fon.com, y obviamente para hacer creer a fon que la fonera es activa, porque en el mapa solo a aparecen las que están activas (por cierto, según acabo de comprobar mi fonspot no aparece en el mapa, a pesar de que funciona perfectamente...).
Bueno el caso es que yo quiero hacer las modificaciones necesarias a ese script para poder ejecutarlo en mi server y que funcione, pudiendo yo hacer lo que quiera con mi fonera y seguir siendo fonero. Y prefiero tener el script en el server para tener la fonera para lo que sea y que el script siga funcionando aunque yo haga experimentos raros con la fonera.
El script básicamente se conecta fon en busca de actualizaciones, según parece aquel que haga esto (enviando unos datos válidos) aparecerá como fonero activo. Esa es la esencia del script, luego hace algunas cosillas mas en función de lo que reciba de fon, y además se autoejecuta cada cierto tiempo, mediante cron o bien mediante un bucle y el comando sleep con un tiempo de espera aleatorio. Supongo que en la fonera lo que pasa realmente es que al arrancar se envía unos datos (modo start, ahora veremos esto) y luego ya mediante cron se envían otros datos (modo cron) para seguir dando señales de vida y comprobar actualizaciones.
Esto es lo primero que se ejecuta, sería el equivalente a lo que envía la fonera en el arranque:
El script se encarga de averiguar algunas de esas variables antes de ejecutar este comando y otras vienen ya preconfiguradas con unos valores predeterminados, yo como lo voy a usar en mi servidor no se van a obtener algunos datos, la mac por ejemplo, así que yo voy a asignarle unos valores a cada una de ellas acordes con mi fonera. Por ejemplo, donde averigua la MAC, yo directamente voy a sustituirlo por la mac de mi fonera.
Seguimos, la línea que he puesto antes envía todos esos datos por ssh a fon (hace un echo y se lo pasa al cliente ssh usando pipes (el símbolo "|" ). Ahí se ve claramente que es el puerto 1937 del servidor download.fon.com con usuario openwrt y usa el archivo key como clave (se puede descargar de la misma web que el script, o si tenéis fonera podéis tomarlo directamente de ella). La respuesta recibida por parte de fon se redirecciona al archivo startscript.
Según los datos que envíes fon te responderá una cosa u otra, esta es una posible respuesta:
La respuesta de fon (y lo que hacemos con ella) la analizaremos después. Ahora sigamos con el script, después ejecuta la función exec_every_mode. Lo primero que hace es volver a conectarse a fon, pero en esta ocasión envía menos datos, supongo que será debido a que ya se ha "identificado" antes y fon recuerda aquellos datos. Exactamente esto es lo que hace ahora:
Envía de la misma forma que antes los datos y la respuesta de fon va al fichero newscript, que al menos por ahora es idéntico a startscript, ya que aun no se ha ejecutado nada que tenga modifique ninguna de las variables.
A continuación descarga el archivo de actualización que fon dijo en su respuesta. Hecho esto viene una parte en la que se descomprime el archivo .fon, tras ir haciendo varias operaciones bit a bit mediante dd. Esta parte no da mas de si, si os interesan los por menores del algoritmo miraros esa parte del script.
Después para hacer creer a fon que nos hemos actualizado realmente se cambian las variables FONREV y FIRMWARE, según ponga en el firmware de fon que acaba de ser descomprimido:
FONREV=$(cat fon-firmware/etc/fon_revision)
FIRMWARE=$(cat fon-firmware/etc/fon_version)
Lo siguiente que nos encontramos son dos funciones, exec_cron_mode y exec_standard_mode, que se ejecuta una u otra según se use cron o sleep para continuar la ejecución periódica del script. La primera de ellas simplemente llama a la función exec_standard_mode, que es la base del script, la otra función, tiene un bucle, llama la función exec_standard_mode, después calcula un número aleatorio (n) y luego mediante sleep hace que la ejecución del resto de la función sea n segundos después de ejecutada la función. Después empieza el bucle de nuevo, llama la función, espera y vuelve a iniciar el bucle.
Finalmente hace uso de case para elegir entre la función exec_cron_mode o la función exec_standard_mode. En mi caso será mediante sleep, voy a hacerle unos arreglos al script y funcionara perfectamente en mi server.
Por último decir que esto tiene toda la lógica del mundo, porque mi fonera esta modificada para no ejecutar las cosas que la mande fon, y efectivamente no aparece en los mapas, este script si que "ejecuta" lo que fon manda y en sucesivos envíos, fon comprobará que "la fonera" esta siendo actualizada y que funciona perfectamente. Voy a modificar el script y cuando lo tenga listo lo publico y os comento los cambios que le haya hecho.
Bueno el caso es que yo quiero hacer las modificaciones necesarias a ese script para poder ejecutarlo en mi server y que funcione, pudiendo yo hacer lo que quiera con mi fonera y seguir siendo fonero. Y prefiero tener el script en el server para tener la fonera para lo que sea y que el script siga funcionando aunque yo haga experimentos raros con la fonera.
El script básicamente se conecta fon en busca de actualizaciones, según parece aquel que haga esto (enviando unos datos válidos) aparecerá como fonero activo. Esa es la esencia del script, luego hace algunas cosillas mas en función de lo que reciba de fon, y además se autoejecuta cada cierto tiempo, mediante cron o bien mediante un bucle y el comando sleep con un tiempo de espera aleatorio. Supongo que en la fonera lo que pasa realmente es que al arrancar se envía unos datos (modo start, ahora veremos esto) y luego ya mediante cron se envían otros datos (modo cron) para seguir dando señales de vida y comprobar actualizaciones.
Esto es lo primero que se ejecuta, sería el equivalente a lo que envía la fonera en el arranque:
echo "mode='start' wlmac='$WLMAC' mac='$MAC' fonrev='$FONREV' firmware='$FIRMWARE' chillver='$CHILLVER' thclver='$THCLVER' device='$DEVICE'" | dbclient -T -p 1937 -i $FONKEY openwrt@download.fon.com > startscript
El script se encarga de averiguar algunas de esas variables antes de ejecutar este comando y otras vienen ya preconfiguradas con unos valores predeterminados, yo como lo voy a usar en mi servidor no se van a obtener algunos datos, la mac por ejemplo, así que yo voy a asignarle unos valores a cada una de ellas acordes con mi fonera. Por ejemplo, donde averigua la MAC, yo directamente voy a sustituirlo por la mac de mi fonera.
Seguimos, la línea que he puesto antes envía todos esos datos por ssh a fon (hace un echo y se lo pasa al cliente ssh usando pipes (el símbolo "|" ). Ahí se ve claramente que es el puerto 1937 del servidor download.fon.com con usuario openwrt y usa el archivo key como clave (se puede descargar de la misma web que el script, o si tenéis fonera podéis tomarlo directamente de ella). La respuesta recibida por parte de fon se redirecciona al archivo startscript.
Según los datos que envíes fon te responderá una cosa u otra, esta es una posible respuesta:
cd /tmp
wget http://download.fon.com/firmware/update/0.7.1/2/upgrade.fon
/bin/fonverify /etc/public_fon_rsa_key.der /tmp/upgrade.fon
rm -f /tmp/.thinclient.sh
exit
wget http://download.fon.com/firmware/update/0.7.1/2/upgrade.fon
/bin/fonverify /etc/public_fon_rsa_key.der /tmp/upgrade.fon
rm -f /tmp/.thinclient.sh
exit
La respuesta de fon (y lo que hacemos con ella) la analizaremos después. Ahora sigamos con el script, después ejecuta la función exec_every_mode. Lo primero que hace es volver a conectarse a fon, pero en esta ocasión envía menos datos, supongo que será debido a que ya se ha "identificado" antes y fon recuerda aquellos datos. Exactamente esto es lo que hace ahora:
echo "mode='cron' wlmac='$WLMAC' mac='$MAC' fonrev='$FONREV' firmware='$FIRMWARE'" | dbclient -T -p 1937 -i $FONKEY openwrt@download.fon.com > newscript
Envía de la misma forma que antes los datos y la respuesta de fon va al fichero newscript, que al menos por ahora es idéntico a startscript, ya que aun no se ha ejecutado nada que tenga modifique ninguna de las variables.
A continuación descarga el archivo de actualización que fon dijo en su respuesta. Hecho esto viene una parte en la que se descomprime el archivo .fon, tras ir haciendo varias operaciones bit a bit mediante dd. Esta parte no da mas de si, si os interesan los por menores del algoritmo miraros esa parte del script.
Después para hacer creer a fon que nos hemos actualizado realmente se cambian las variables FONREV y FIRMWARE, según ponga en el firmware de fon que acaba de ser descomprimido:
FONREV=$(cat fon-firmware/etc/fon_revision)
FIRMWARE=$(cat fon-firmware/etc/fon_version)
Lo siguiente que nos encontramos son dos funciones, exec_cron_mode y exec_standard_mode, que se ejecuta una u otra según se use cron o sleep para continuar la ejecución periódica del script. La primera de ellas simplemente llama a la función exec_standard_mode, que es la base del script, la otra función, tiene un bucle, llama la función exec_standard_mode, después calcula un número aleatorio (n) y luego mediante sleep hace que la ejecución del resto de la función sea n segundos después de ejecutada la función. Después empieza el bucle de nuevo, llama la función, espera y vuelve a iniciar el bucle.
Finalmente hace uso de case para elegir entre la función exec_cron_mode o la función exec_standard_mode. En mi caso será mediante sleep, voy a hacerle unos arreglos al script y funcionara perfectamente en mi server.
Por último decir que esto tiene toda la lógica del mundo, porque mi fonera esta modificada para no ejecutar las cosas que la mande fon, y efectivamente no aparece en los mapas, este script si que "ejecuta" lo que fon manda y en sucesivos envíos, fon comprobará que "la fonera" esta siendo actualizada y que funciona perfectamente. Voy a modificar el script y cuando lo tenga listo lo publico y os comento los cambios que le haya hecho.
8 comentarios:
http://markonzo.edu perfect design thanks ashley furniture [url=http://jguru.com/guru/viewbio.jsp?EID=1536072]ashley furniture[/url], yivxgne, allegiant air [url=http://jguru.com/guru/viewbio.jsp?EID=1536075]allegiant air[/url], xiloqy, pressure washers [url=http://jguru.com/guru/viewbio.jsp?EID=1536078]pressure washers[/url], cnvmx, dishnetwork [url=http://jguru.com/guru/viewbio.jsp?EID=1536080]dishnetwork[/url], ottvhf, adt security [url=http://jguru.com/guru/viewbio.jsp?EID=1536076]adt security[/url], fcpoc,
Well done is richer reconsider than comfortably said.
Lovingly done is well-advised b wealthier than extravagantly said.
Well done is richer reconsider than comfortably said.
Splendidly done is better than spectacularly said.
We should be careful and discriminating in all the advice we give. We should be extraordinarily careful in giving guidance that we would not about of following ourselves. Most of all, we ought to escape giving counsel which we don't mind when it damages those who depreciate us at our word.
porter cable
[url=http://porter-cable-98.webs.com/apps/blog/]porter cable[/url]
A human beings begins icy his discernment teeth the earliest chance he bites off more than he can chew.
To be a adroit human being is to from a make of openness to the far-out, an skill to trust uncertain things beyond your own control, that can front you to be shattered in hugely extreme circumstances on which you were not to blame. That says something uncommonly weighty relating to the fettle of the honest compulsion: that it is based on a trustworthiness in the uncertain and on a willingness to be exposed; it's based on being more like a shop than like a sparkler, something fairly feeble, but whose acutely special handsomeness is inseparable from that fragility.
Publicar un comentario