Twilight world

He estado comprobando que la capacidad que tiene un AP para interferir la señal de otro AP es TOTAL.

El experimento:

Dos redes con el mismo ssid y en el mismo canal (son del mismo ISP) en condiciones normales soy capaz de asociarme a una de ellas y tengo velocidades de transmision de datos mas o menos normales, aun con intensidades de señal bajas (4/92). Salvo en momentos puntuales en los que se pierde totalmente el enlace wireless sin que se pierda la señal, ni siquiera el router responde a los pings… Hoy he descubierto que la causa de que esto suceda es la interferencia de la segunda red… Esta segunda red normalmente tiene intensidades de señal muy bajas, sin embargo hoy tenia una intensidad de señal alta, tan alta que me he asociado a ella en vez de a la que me asocio habitualmente (me asocio por ssid, no por mac)… cuando he conseguido desasociarme de ella y asociarme a red habitual era incapaz de conectar, ni hacer pings, y estamos hablando de una intensidad de señal de 35/92. Tan solo en el momento en el que he encontrado una zona de “sombra” he consegido transmitir datos a la red a una velocidad aceptable y eso que tenia intensidades de señal de 2 y 3/92.

Conclusiónes:

Una red wireless es capaz de interferir totalmente un enlace cuando estan en el mismo canal, por lo tanto lo de las interferencias para nada es un mito (como a veces nos pensamos) es algo real y muy real

Como esta estructurado el checksum

El problema era encontrar la relacion entre estos dos numeros

Checksum d0dd 1c00
Tamaño 001c ddd0

Asi a priori parece bastante dificil… y lo unico que he encontrado ha sido una relacion de imagenes especulares pero intercambiando los dos ultimos numeros ;) como veis un método de lo mas informático

Primero voy a asegurarme de que las cosas son exactamente como dicen en seattlewireless

hexdump F5D7130_4.03.03.bin | less

0000000 4f4c 4441 dcc3 0014 8728 6367 8000 0000
(…)

Tamaño 0014 dcc3
Cheksum dcc3 0014

mmm… esto tiene mucha mejor pinta, vamos a ver como esta el cheksum en otro firmware, por ejemplo el 7330…

hexdump BELKIN_EB_USA_1.00.09 | less

0000000 4f4c 4441 ed47 0014
(…)

Tamaño 0014 ed47
Cheksum ed47 0014

Se confirma la estructura…

Por lo tanto es un error en la pagina de seattlewireless… cuando compruebas el tamaño con hexdump solo tienes que añadirle ceros, separar los bytes en 4 y cambiar los cuatro primeros por los cuatro segundos.

veamos ahora como estan las cosas en mi nuevo firmware

hexdump 7130_LOAD.dump | less

0000000 4f4c 4441 dcc3 0014
(…)

Tamaño 001e 2cc3

La cabecera deberia comenzar del siguiente modo

0000000 4f4c 4441 2cc3 001e
(…)

Pero tenemos un problema y es que no conozco ningun editor hexadecimal adecuado… tratare de buscar algo y mañana cuando cambie el checksum tendre el firmware preparado para ser introducido en el AP

No se si habra alguna manera alternativa de hacerlo, pero la unica que yo conozco es la de añadir el archivo trx+nvar sobre el dump del LOAD:

dd if=Desktop/belkin\ firmware\ project/7130.trx of=Desktop/belkin\ firmware\ project/7130_LOAD.dump bs=1 seek=28

Cuando comprobamos con hexdump todo esta como deberia.

Como comentario adicional debo indicar que al final el archivo no ha quedado tan grande como me temi en un principio, “sólo” ha crecido 600Kb desde el archivo original, eso posiblemente se deba a que aunque el archivo busybox que le he añadido es un binario debe tener algun tipo de compresion al meterlo en el sistema de archivos del cramfs. Me alegra bastante comprobar que el firmware mas grande de los que tengo que acepta el AP (F5D7230-4_4.03.03.bin) es solo 100Kb mas pequeño que el mio.

Ahora solo nos queda ajustar el checksum del tamaño y eso segun la pagina del seattlewireless se encuentra en el LOAD.

Textualmente de seattlewireless:
“adjust accordingly the four bytes at offset 4 (these indicates the length of the file). Note that it is in little endian (least signifiant bit first). In the 3.00.07 firmware it is “d0dd1c00″ which corresponds to 0x001cddd0, the total size of the file.”

Esta frase me deja un poco descolocado y perdido asi que lo consultare en la lista de salamancawireless… por ahora me quedo con mi firmware sin poderlo subir via web… exactamente con el siguiente error:

Error(4) about checksum during file uploaded

colara por tftp?? comprueba el tftp el checksum? posiblemente si, pero solo hay una manera de saberlo…

La respuesta es NO, tampoco se lo ha tragado, confio en que el unico problema sea el cheksum… aunque despues de todo lo que he estado haciendo no hay manera de saberlo, espero tener respuesta pronto a la cuestion del checksum

La opcion seek del comando dd es exactamente lo que estaba buscando ya que escribe en el archivo destino of= a partir del byte indicado en la opcion seek.

En primer lugar calculo cuanto ocupa el archivo .trx, lo paso a hexadecimal y le pego el nvar asi:

dd if=Desktop/belkin\ firmware\ project/7130_nvar.dump of=Desktop/belkin\ firmware\ project/7130.trx bs=1 seek=1974272

Cuando compruebo usando hexdump me encuentro con algo que me resulta sospechoso y es lo siguiente.

un firmware original mantiene la siguiente estructura al comienzo del nvar

(…)
014cb20 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
014d010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 N V A R
(…)

Mientras que mi firmware tiene la siguiente estructura.
(…)
01e1c30 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
01e2000 N V A R 247 \f \0 \0 p 266 274 302 \0 200 \0 \0
(…)

Puede estar esto afectando al firmware de algun modo? Al final de este proyecto detallare una lista de los posibles puntos críticos y como comprobar en que punto se encuentra el error (si es que hay alguno…)

y del mismo modo añadimos la cabecera LOAD que primeramente tenemos que extraer del firmware.

dd if=Desktop/belkin\ firmware\ project/F5D7130_4.03.03.bin of=Desktop/belkin\ firmware\ project/7130_LOAD.dump bs=1 count=28

y que es la siguiente:

0000000 L O A D 303 334 024 \0 ( 207 g c \0 200 \0 \0
0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

ahora deberiamos añadir la cabecera al resto del firmware y finalmente comrpobar el checksum que esta en la cabecera para ajustarlo al tamaño final del firmware.

Aqui dejo parte de las notas que he ido tomando durante mis experimentos con el firmware del belkin y como he ido (y un sigo) construyendo un firmware, todo ello basado en las anotaciones que hacen en seattlewireless.

———–Parte2

Lo primero es extraer el cramfs del firmware, para ello buscaremos los bytes 3d45 28cd que se sabe corresponden al inico del cramfs en muchos kernels de belkin

hexdump /home/usuario/Desktop/BELKIN_EB_USA_1.00.09 | grep 3d45

(…)
0091d70 0000 0000 3d45 28cd c000 000b 0003 0000
(…)

Ahi tenemos el offset, pasamos el offset a decimal (597364) y extraemos el cramfs con el comando dd

dd if=/home/usuario/Desktop/BELKIN_EB_USA_1.00.09 of=/home/usuario/Desktop/cramfs_7330.dump bs=597364 skip=1

Comprobamos que el archivo que hemos obtenido es exactamente el cramfs

hexdump Desktop/cramfs_7330.dump | less

0000000 3d45 28cd c000 000b 0003 0000 0000 0000
(…)

y lo montamos en un directorio

mount -o loop -t cramfs Desktop/cramfs_7330.dum /mnt/cramfs/

y lo copiamos para trabajar con el y modificarlo a placer

cp -r /mnt/cramfs/* Desktop/cramfs_7330

En el caso del firmware F5D7130_4.03.03.bin el proceso es exactamente igual solo que el offset a utilizar es 605856

———-Parte3

Cuando analizamos los archivos presentes en el firmware nos encontramos con que todos los comandos tipicos de linux son enlaces simbolicos a un archivo binario llamado busybox.

¿Que es una busybox?
Una busybox es como dicen en la propia pagina de busybox (busybox.net)es una navaja suiza de linux… es un binario que tiene “integrados” muchos de los comandos para realizar operaciones normales en linux, en nuestro caso puede ser interesante añadir una segunda busybox al firmware o incluso sustituir la que trae “de serie”, con eso vamos a conseguir nuevas funcionalidades en nuestro firmware pero la que mas nos interesa por el momento es el cliente telnetd ;) asi que vamos a ponernos manos a la obra.
En principio me baje tres versiones de la busybox

busybox-1.00: una version estable
busybox-20050602: una version de pruebas
busybox-snapshot: ultima version del cvs

Y como se que soy muy perro voy a empezar con la ultima porque se que si funciona a la primera no me voy a comer la cabeza en probar mas versiones.

Nosotros queremos compilar la busybox para el belkin por lo tanto vamos a usar las utilidades gpl que nos da linksys para poder compilar la busybox para el procesador MIPS.
Nos bajamos los tools gpl de linksys, los instalamos en /opt/brcm/ y añadimos las direcciones a los paths.

/opt/brcm/hndtools-mipsel-linux/bin
/opt/brcm/hndtools-mipsel-uclibc/bin

y pasamos a la compilacion de la busybox.

make menuconfig

en la seccion build options seleccionamos la opcion de que cree un binario sin necesidad de librerias y le decimos que vamos a usar un compilador cruzado que esta en…

/opt/brcm/hndtools-mipsel-linux/bin/mipsel-linux-

Entre las opciones interesantes que he metido en esta primera prueba estan:

crond
crontab

En principio no tengo nada en mente con estas dos utilidades, pero el simple hecho de tenerlas me resulto interesante por si acaso en el futuro necesito hacer algo con ellas…

todos los comandos de manejo de módulos
lsmod
modprobe
rmmod
Teniendo en cuenta que el firmware comparte kernel con algunos firmware de linksys podria ser interesante esta opcion para no tener que recompilar todo el kernel de nuevo.

En networking options…

Pues casi todo…
IPv6
fakeidentd (aun no tengo del todo claro para que sirve pero me parecio curioso)
ftpget
httpd
telnet
telnetd
ifupdown
inetd
iproute
iptunnel
netstat
traceroute

En otras linux system utils

soporte para NFS

system loging

todo desactivado

Y alguna cosa mas que ahora mismo no recuerdo, pero los cambios importantes fueron los que he señalado…

Ya solo queda compilarla y probarla, pero eso sera mañana que hoy es muy tarde…

————————–

Primer error en las compilaciones, choque entre algunas funciones de algunos applets… me suena a fallo del cvs, mañana intentare compilar la version estable y si me da algun error buscare en el google a que puede deberse.

En principio mi idea no es sustituir absolutamente el http del firmware, una opcion aceptable podria ser activarlo desde la pagina web del firmware de tal manera que cuando cargues la pagina tengas opcion de activar el demonio telnet porque no se en que parte del firmware se especifican los demonios que se cargan al arrancar (todo sera investigar) asi que los de seattle lo que hacen es sustituir el httpd por una busybox muy sencilla que tiene el telnetd activado. Mi idea es sustituir la busybox del firmware por la mia recien compilada con mas funcionalidades.

————————–

Mis sospechas eran fundadas… la version cvs da problemas de compilación, la version 1.00 compila perfectamente, hice las pruebas pertinentes antes de ponerme a configurar nada, simplemente añadi el prefijo del compilador para mipsel y compile con las opciones basicas

make dep
make

limpié los archivos para ponerme en serio

make clean

y meti otra vez todas las opciones con

make menuconfig

y le meti todas las opciones que habia comentado anteriormente… Mañana seguire con la prueba de cargar la busybox en vez de la que traia por defecto el kernel, un par de comentarios, en primer lugar que he creado una “peazo” busybox de 1,8Mb en vez de la de 207-266Kb que traen los firmwares. Esto puede ser un problema dado que todo el firmware tiene que cargar en memoria y esta esta bastante limitada… De entrada voy a probar a construir un firmware hasta el final y a probarlo, ya que asi de paso me hago con las opciones de construccion (trx tool etc etc) y si veo que la cosa no funciona pues ire reduciendo el tamaño de la busybox…

Segundo asunto. Como solucionar lo del httpd sin hacer la chapuza de sustituir uno por otro, muy sencillo, sustituimos el httpd por un script que llame la verdadero httpd (que habremos renombrado a otra cosa) y el telnetd de este modo tenemos los dos demonios corriendo en el AP.

Pero todo esto será mañana…

—————————–
Decision… que firmware utilizar para modificarlo?? pues al final he decidido probar con el 7130 por tres motivos:

a-Esto mismo (bueno, parecido) esta hecho ya con el 7230
b-El 7330 no tiene ninguna funcionalidad interesante y habria que añadirselas todas
c-Nuestro AP segun belkin es un 7130

Hasta el momento habia olvidado un punto que en principio considere sin importancia, pero que ahora mismo si la tiene y es que necesitamos extraer el kernel del firmware, para ello usaremos dd y el offset que ya sabemos que el el de comienzo del cramfs… en el esquema ascii de la primera parte está mas o menos claro.

dd if=Desktop/F5D7130_4.03.03.bin of=Desktop/kernel.dump.gz count=605856 bs=1 skip=56

mmm…resulta tranquilizante cuando estas haciendo cosas que no sabes si estas haciendo bien encontrar detalles como este:
El archivo kernel.dump.gz tiene formato de archivo gz (y no es por la extension) ubuntu lo reconoce y le cambia el icono… me quedo mas tranquilo.

Usamos la herramienta trx de linksys para construir el HDR0 usando el cramfs modificado y el kernel del firmware original.

trx -o Desktop/7130.trx Desktop/kernel.dump.gz Desktop/cramfsmod.dump

hexdump -c Desktop/7130.trx | less

Eureka!!!
(…)
0000000 H D R 0 \0 036 \0 342 ; 001 017 \0 \0 001 \0
(…)

Ya tenemos el HDR0 construido, ahora solo quedan añadir pie y cabecera. Primero añadiremos el nvar y luego la cabecera en la que ajustaremos el tamaño total del firmware (una especie de checksum) para que el AP no proteste al meterselo.

———————————–

Para añadir el nvram lo busqué en el firmware original y encontre que estaba situado a partir del offset 14d01c que en decimal corresponde con 1363996

root@Ceres:/home/usuario # dd if=Desktop/belkin\ firmware\ project/F5D7130_4.03.03.bin of=Desktop/belkin\ firmware\ project/7130_nvar.dump bs=1363996 skip=1

(como podeis comrpobar ahora uso otra carpeta para guardar los archivos del proyecto… espero no liar mucho al personal que pueda leer esto.

y comprobamos, supongo que en algun momento podeis preguntaros a que vienen tantos pasos de comprobacion cada vez que extraigo algo con dd… pues bien, para mi el hexadecimal es algo que me queda un poco a trasmano y aunque me defiendo dignamente tengo la costumbre de ir asegurandome en cada paso de que lo que tengo es lo que quiero.

hexdump -c Desktop/belkin\ firmware\ project/7130_nvar.dump

0000000 N V A R 247 \f \0 \0 p 266 274 302 \0 200 \0 \0
(…)

Perfecto, ahora solo queda concatenar los dos archivos, para ello usare la opcion -seek del comando dd, aunque primero tengo que averiguar a grandes rasgos como funciona ;)
———————————–