Aventuras y cacharreos con la Fonera
Recibiendo la fonera
He podido leer en un blog, un artículo con profusión de material fotográfico que describe La fonera tal como lo recibimos de Fon, así que permitid que me ahorre el desenpolvar mi cámara de fotos y, si teneis curiosidad, id a visitar directamente dicho artículo (¿no os parece?).
Por mi parte, sólo comentar que a mí si me llegaron las pegatinas Fon, pero llegaron arrugadas dentro del sobre del transportista... en lugar de llegar dentro de la caja de cartón de la propia fonera, lo cual indica dos cosas: Originalmente, dentro de la caja no estaban esas pegatinas, alguien se dió cuenta y las incorpora al envio, pero en vez de meterlas en la caja, las añade por fuera, de tal forma que cuando las recibes están arrugadas y, practicamente inutilizables :) (pero bueno, supongo que las pegatas son lo de menos) :)
Quick Start
Bien, sin leer nada (como es lo usual en estos casos), conecto la fonera a mi red y bien, veo que pilla IP, y acaban encenciéndose los 3 LEDs sin problemas.
Ya está... enchufada y funcionando.
Cabe mencionar que mi red está poblada por unos cuantos chismes, entre los que se encuentra un servidor Linux que hace de router al resto de internet y, que es el encargado de dar IPs mediante dhcp al resto de participantes de mi red.
El siguiente paso era... localizar que IP le habia tocado, pero como no estaba por la labor de repetir dicho paso unas cuantas veces, (abrir el los del dhcpd, rebuscar, etc), configuré mi servidor dhcp para que le tocase siempre la misma ip (prefijada por MAC), añadiendo tambien la entrada fonera en mis ficherines etc/hosts, así ya la tendría localizada.
Una vez localizada la IP de la fonera, hago las típicas pruebas chorras (e inocentes) :
root@radikal:~# ping fonera
PING fonera (192.168.0.30) 56(84) bytes of data.
64 bytes from fonera (192.168.0.30): icmp_seq=1 ttl=64 time=1.18 ms
64 bytes from fonera (192.168.0.30): icmp_seq=2 ttl=64 time=0.873 ms
64 bytes from fonera (192.168.0.30): icmp_seq=3 ttl=64 time=0.819 ms
64 bytes from fonera (192.168.0.30): icmp_seq=4 ttl=64 time=0.897 ms
64 bytes from fonera (192.168.0.30): icmp_seq=5 ttl=64 time=0.829 ms
--- fonera ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.819/0.920/1.186/0.140 ms
root@radikal:~#
Vale, el chisme responde, está vivo :)
Seguimos con las pruebas chorras:
- Intento ver si es accesible vía web en su dirección de red, sin resultado.
- Intento un telnet y un ssh y lo mismo, nada de nada.
- Hago un nmap y nada de nada. Bien, está todo cerrado... así que habrá otra dirección por la que entrar y configurar el chisme (pienso en ese momento)
Slow and Demoniacus Installation Guide...
Intento ver si encuentro la jodida dirección entre la documentación, en el típico tríptico 'Quick Installation Guide', y no, ahí no figura la dirección de red para entrar en su servidor web de configuración.
En lugar de eso, la guia rápida nos indica que, para acceder al servidor web de la propia fonera, lo haga a través de Wifi, conectándome a la SSID privada (el chisme despliega 2 redes, una pública y otra privada, encriptada).
Vaya... primera pega... ¿y que pasa si no tengo ningún chisme Wifi a mano? (¿y si no lo tengo de ninguna forma, y resulta que soy un tipo altruista que quiere enchufarse la fonera sólo para dar servicio o para vender mi conexión?).
En fin... paso del tema, así que abro el CD de documentación que acompaña a la caja y veo que se trata de una presentación hecha en Flash, pero compilada en un ejecutable de Windows (.EXE) con lo cual, tengo que arrancar un windows XP a través de VMware sólo para verlo... en fin.
Tras ejecutar la presentación, compruebo con asombro que ¡el CD incluye todo menos lo que estaba buscando!... manda cojones.
Es decir, contiene una serie de cosas, si, pero no está el manual de usuario... :(
El manual de usuario, (un PDF en INGLÉS), no está grabado en el CD... en su lugar hay un link hacia una página web de Fon.
Supongo que lo habrán hecho así para poder cambiar el documento y que éste siempre refleje la última versión, pero coño... ya podrían haber grabado en el CD la versión en curso, ¿no? y colocar un link hacia la web con la leyenda: 'Obtenga la última version pinchando aqui'... en fin...
(Y ya no voy siquiera a preguntar porqué no está también en el resto de idiomas... pffff)
Descargo el PDF del manual, busco y por fin, encuentro la jodida dirección de red del chisme... la pongo por aqui para tenerla ' a mano:' 169.254.255.1
Bien, sabiendo la dirección del chisme, coloco mi ordenata en la misma subred, y por fin, puedo ver la web de configuración del chisme:
He tachado el nombre de mis redes, espero que no os importe, que igual tengo algún vecinito cabrón, nunca se sabe :)
Primera cosa que llama mi atención... ¿cómo que el DNS Server es 213.134.45.129?, si ese no es ninguno de mis DNSs :? ¿de dónde ha salido?.
Tras revisar mi servidor dhcp, efectivamente, veo que no corresponde a ninguno de mis DNSs, así que por dhcp no lo ha obtenido... hummm que raro.
Investiguemos un poco de ese ordenador, a ver que sacamos en claro:
root@radikal:~# whois 213.134.45.129
% This is the RIPE Whois query server #2.
% The objects are in RPSL format.
%
% Note: the default output of the RIPE Whois server
% is changed. Your tools may need to be adjusted. See
% http://www.ripe.net/db/news/abuse-proposal-20050331.html
% for more details.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html
% Note: This output has been filtered.
% To receive output for a database update, use the "-B" flag
% Information related to '213.134.40.0 - 213.134.47.255'
inetnum: 213.134.40.0 - 213.134.47.255
netname: INTERHOST
descr: Servicios de Hosting en Internet S.A.
country: ES
admin-c: FDS85-RIPE
tech-c: JJF10-RIPE
tech-c: JCM13-RIPE
tech-c: JIGS2-RIPE
status: ASSIGNED PA
mnt-by: INTERHOST-MNT
source: RIPE # Filtered
¡Anda coño! , que majos, usan su propio servidor DNS en lugar de usar los que yo le digo... ¿para que?, ¿no se fian de la calidad de mis DNSs?, ¿o acaso así saben qué visitan los usuarios de mi Wifi pública?, joder, que mal rollo... hufff.
Confío en ser un ignorante y pensar en que tengan una buena razón para hacerlo (pero que quieres que te diga, confío poco) :) a ver si alguien me saca de mi error...
Bien, paso del tema de momento, e intento cacharrear un poco con mi nuevo juguetito.
Pruebo a conectarme por Wifi, primero a la red privada... sin éxito. Ya me lo avisó un colega (le llegó unos 3 dias antes que a mi) que la privada va chunga, que por lo menos él no fué capaz de conectarse por la SSID privada usando WAP como método de seguridad.
Yo lo intento y nada... que nanai de la china.
Mi amigo cree que es algún tema de los drivers de su tarjeta wifi, dado que le ocurre lo mismo con el router adsl wifi de telefónica que él tiene en casa... al que sólo puede conectarse usando WEP.
También me dice que la red privada no se comporta como un AP normalito... es decir, al conectarte por la SSID privada, la fonera actúa como router, y ella misma te da una IP de una subred que ella misma crea... (mal sunto, pensé... bueno para los novatos que no tienen ni un switch, pero para mi es algo malo... ¿que les hubiera costado ponerlo definible?... en fin...), porque así no habrá forma fácil de acceder a mi red local, a mis discos compartidos, etc...a través de la SSID privada (ni de la pública, claro)
Bueno, así que de momento, pasando de la red privada... total, aún no he recibido mi UMPC y aún el wifi para mí no deja de ser una inversión educativa, nada funcional, porque no tengo ningún gadget que la use, pero pronto será algo necesario para exprimir mi nuevo juguete, así que ya me pelearé con la red privada más tarde, y ya jugaré con mi UMPC conectándome en otras foneras de la gente, que, es para lo único que me he metido en esto de fon... (bueno, para esto y para cacharrear con un linux embedded, claro).
De momento, entro por la SSID pública, comprobando que todo marcha bien: se conecta, me da IP la propia fonera (IP de una subred propia que ella monta, en la que se coloca tanto de puerta de enlace o gateway como de servidores DNSs), supongo que a la postre, ella, la fonera, usará el DNS arriba mencionado... hufff que mal pinta eso.
Me conecto y sale mi 'portal por defecto como punto de acceso FON'.
Creí haber leido que uno puede personalizar su portal de acceso, pero, al ir a comprobarlo (dado que me parece algo un poco caótico el que sale por defecto), si, efectivamente, me permite personalizarlo, pero de mala manera... :(
Me deja colocar mi propio video de Google Video (vale, cojonudo, ahora de dónde saco yo una cámara de video para filmar algo coherente y, una capturadora para pasarlo a avi o a lo que sea... ¿y si paso de poner un video?, coño no hay opción...que de puta madre, he de dejar al guachaski haciendo el moña o bien cambiarlo por un video de tip y col sacado de youtube... brrr ), tambien me deja colocar un rollo de fotos de flicker (hufff... ¿pa que, pa poner mi careto blanco-amarillento producto de las radiaciones del monitor?), y no se que chorrada más me deja poner, pero paso ya del tema, que le den por culo a la personalización de medias tintas...
Tanto leer al Martin en su blog que quiere que los portales s epersonalicen... y resulta que no se puede :) que decepción... Martin, ¡cambia eso ya!
Por defecto, el video que aparece es uno en el que sale el Martín Varsavsky haciendo el chorra, explicando lo que es FON (pero sinceramente, para alguien que no conozca lo que es fon y se conecte a tu red pública asi, para probar... no es nada explicativo), y el link, apunta hacia su blog
Otra desilusión... a mi casi me hubiera gustado más (y de hecho, así pensé que sería) que me dejasen poner mi propio html, en el que explicase, primero dónde está mi punto de acceso, que hacer para conectarte, etc, etc y algún botón que lleve al visitante a la página para adquirir bonos para conectarse o bien para que haga login si ya es un usuario fon...
No me gustan las páginas con flash, ni con videos, me hubiera gustado poder poner mi propio portal de acceso... en fin, igual se dan cuenta y lo cambian... está bien que mantengan el que sale por defecto, pero pienso que debería haber una forma de substituirlo por otro completamente, dándote una serie de utilidades (o links) para redireccionar al usuario cuando quiera comprar un bono, o hacer login... en fin, algo más 'tocable' que lo que ofrecen.
Aqui Fon, vuelve a menospreciar a sus usuarios, pensando en que no son capaces de crear un portal decente... en fin, que poca fé :)
¿Que mejor que cada uno, que vive en su zona del planeta y sabe cómo piensan los posibles candidatos a conectarse a tu red para explicarles con TU lenguaje y tu forma de hacer las cosas?... en fin...
Si uno de mis vecinos se enchufa a mi red, y le sale el video de Martín, haciendo el gil, en un video en inglés que intenta explicar lo que es Fon... no sé lo que dudará antes de cambair de red... XD
Y si encima se le ocurre visitar su blog... entonces sí que apaga y vámonos... mi vecinito no entendería nada, creería que se está metiendo en la Nasa XD
Una vez conectado por la SSID pública de mi fonera, hago login con mi cuenta fon, y veo las diferentes opciones de configuración, tanto del portal como del router... ¿router?, ¿pero como?, habré leido mal... ¿no me jodas que desde la página de Fon puedo configurar mi Fonera?, pues sí señores... así es, jejeje desde la página de Fon, uno puede cambiar tanto los SSIDs de tus redes, como la password de acceso a tu fonera o la clave WAP de tu red privada (y más tarde puede comprobar que tambien cambia la clave de root de la fonera, para cuando por ejemplo, quieres entrar mediante SSH)
¿Cómo es esto posible?, ¿que tipo de interacción hay entre mi fonera y sus servidores?, huyyyy que mal rollo...
Luego seguiré con esto, que tiene miga el... 'mecanismo' :)
Bien, una vez agotada la diversión a través de la red pública, me enredo en una odisea de prueba-error para conseguir conectarme por la SSID privada...
Pruebo todas las combinaciones posibles que ofrece la fonera (dado que a la primera nanai, no va): WPA, WPA2, WPA+WPA2 mixed, WEP cifrado AES, TKIP y mixed y nada de nada... lo máximo que logro hacer es que mi portátil se conecte a la red, pero se queda atrapado en 'Obteniendo dirección IP' y de ahi nada que hacer.
Veo, sorprendentemente, que deja colocar la red privada sin protección, es decir, en abierto... la pruebo tambien y nada, naranjitas de la china... algún problema debe haber entre mi tarjeta (una Conceptronic C54C) y la fonera, que no me deja conectarme, ni en Windows XP ni en Linux... así que paso del tema, total, tengo por aqui un router Linksys que puedo poner de AP con el que todo funciona como debe ser, así que, cuando lo necesite, podré usarlo para conectarme a mi red privada, y cuando viaje, me conectaré con mi UMPC a algúna fonera de otro (eso espero), así que todo resuelto.
Ah, se me olvidaba, entre prueba y prueba (que me llevó un buen rato, no creais...), porque tenía que andar conectándome por cable, dandole una dirección de la subred de la fonera para poder configurarla via web, observé que las SSIDs pública y privada a veces desaparecian, a veces aparecían... es decir, si usas la opcion 'Ver Redes disponibles' (tanto en Windows, como en Linux con el KWifiManager como desde la web de configuracion de un LinkSys), las redes a veces aparecen y desaparecen... :?
Supongo que será una consecuencia de usar una radio para generar dos SSIDs diferentes, no sé... :? pero no parece tan estable como cualquiera de los otros SSIDs que veo desde mi casa...
Bien, una vez agotado el divertimento, y un poco hastiado de la SSID privada (y sin mas chismes con los que probar a ver si realmente funciona o no), la configuro como WAP, la pongo clave, y me olvido de ella.
Abriendo el SSH
Un poco de Google, acerca de la fonera (a decir verdad, un bastante de Google, dado que hay mucha información, pero casi toda hacía referencia a las viejas foneras, que debían ser un Linksys reprogramado al que le inyectan una distribución linux llamada OpenWrt), encuentro un artículo sobre cómo abrir el SSH de la fonera.
Se trata de una traducción al español, de un artículo en inglés : Inside The Fonera en el que explican que la fonera dispone de un puerto serie mediante el cual podremos acceder a una consola unix en el propio juguetito, la pega es que, internamente la fonera no usa los niveles de señales correspondientes a la norma RS-232 es decir, en RS-232 un cero lógico, es señalizado mediante -12V mientras que un 1 lódico es señalado con una tensión de +12V, pero la fonera, usa un puerto serie con niveles de tensión de 0V para el cero y 3,3V para el 1 lógico.
Así, si queremos enchufarnos desde el puerto RS-232 de nuestro ordenador, tendremos que usar un circuito que 'traduzca' esos niveles de tensión.
En el artículo proponen un montaje utilizando el viejo conocido: Max232, y, como tengo algún chisme por casa que los usa (de mi época de cacharreo con microcontroladores), no tardo ni 20 minutos en construirme mi propio cable y en seguir las instrucciones propuestas en el artículo.
Tras enchufar mi cable, enchufo la fonera y ¡voila!, sucede ante mi programa terminal todo el arranque del linux de la fonera.
Que bonito, (pienso), meter todo un señor linux en semejante mini-chisme... huff que gozada, esto hay que aprovecharlo para algo más (me digo) :)
Aqui teneis como se ve el arranque de la fonera desde la consola serie:
+PHY ID is 0022:5521
Ethernet eth0: MAC address XX:XX:XX:XX:XX:XX
IP: 0.0.0.0/255.255.255.255, Gateway: 0.0.0.0
Default server: 0.0.0.0
RedBoot(tm) bootstrap and debug environment [ROMRAM]
Non-certified release, version v1.3.0 - built 16:57:58, Aug 7 2006
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.
Board: ap51
RAM: 0x80000000-0x81000000, [0x80040450-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87f0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 1.000 seconds - enter ^C to abort
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0x80041000-0x801ba000
RedBoot> exec
Now booting linux kernel:
Base address 0x80030000 Entry 0x80041000
Cmdline :
CPU revision is: 00019064
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, linesize 16 bytes.
Linux version 2.4.32 (iurgi@ropero) (gcc version 3.4.6 (OpenWrt-2.0)) #4 Thu Aug
17 21:48:03 UTC 2006
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2
Using 92.000 MHz high precision timer.
Calibrating delay loop... 183.50 BogoMIPS
Memory: 14188k/16384k available (1327k kernel code, 2196k reserved, 92k data, 68
k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Checking for 'wait' instruction... available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
squashfs: version 3.0 (2006/03/15) Phillip Lougher
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xb1100003 (irq = 37) is a 16550A
eth0: Dropping NETIF_F_SG since no checksum feature.
eth0: Atheros AR2313: XX:XX:XX:XX:XX:XX, irq 4
MTD driver for SPI flash.
spiflash: Probing for Serial flash ...
spiflash: Found SPI serial Flash.
8388608: size
Creating 8 MTD partitions on "spiflash":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x00720000 : "rootfs"
eth0: Configuring MAC for full duplex
0x001c0000-0x00720000 : "rootfs1"
0x00720000-0x00730000 : "config"
0x00730000-0x007e0000 : "vmlinux.bin.l7"
0x007e0000-0x007ef000 : "FIS directory"
mtd: partition "FIS directory" doesn't end on an erase block -- force read-only
0x007ef000-0x007f0000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only
0x007f0000-0x00800000 : "board_config"
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
ip_conntrack version 2.1 (5953 buckets, 5953 max) - 328 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
802.1Q VLAN Support v1.8 Ben Greear
All bugs added by David S. Miller
VFS: Mounted root (squashfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 68k freed
init started: BusyBox v1.1.3 (2006.08.17-19:56+0000) multi-call binary
Algorithmics/MIPS FPU Emulator v1.5
Please press Enter to activate this console.
jffs2.bbc: SIZE compression mode activated.
wlan: 0.8.4.2 (0.9.0)
ath_hal: 0.9.17.1 (AR5212, AR5312, RF5112, RF2316, RF2317, TX_DESC_SWAP)
wlan: mac acl policy registered
ath_rate_sample: 1.2 (0.9.0)
ath_ahb: 0.9.4.5 (0.9.0)
ath_pci: switching rfkill capability off
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 11.0 phy 4.8 radio 7.0
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
device eth0 entered promiscuous mode
reboot 22/33 66%-t
The system is going down NOW !!ash --login
Sending SIGTERM to all processes.
Please stand by while rebooting the system.
Restarting system.284 S lock /var/run/network-connection
+PHY ID is 0022:55218 S hostapd -B /tmp/hostapd.conf
Ethernet eth0: MAC address XX:XX:XX:XX:XX:2csmasq.conf --dhcp-range=192.168.10.
IP: 0.0.0.0/255.255.255.255, Gateway: 0.0.0.0
Default server: 0.0.0.0 httpd -p 80 -h /www -r OpenWrt
431 root 424 S crond -c /etc/crontabs
RedBoot(tm) bootstrap and debug environment [ROMRAM]n/splash.sh -H 192.168.10.1
Non-certified release, version v1.3.0 - built 16:57:58, Aug 7 2006
451 root 328 D watchdog -t 5 /dev/misc/watchdog
Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.ction
492 root 416 S /bin/sh ./S50dropbear start
Board: ap51 364 R /usr/bin/dropbearkey -t rsa -f /etc/dropbear/dropbear
RAM: 0x80000000-0x81000000, [0x80040450-0x80fe1000] available
FLASH: 0xa8000000 - 0xa87f0000, 128 blocks of 0x00010000 bytes each.
== Executing boot script in 1.000 seconds - enter ^C to abort
RedBoot> fis load -l vmlinux.bin.l7
Image loaded from 0x80041000-0x801ba000
RedBoot> exec
Now booting linux kernel:
Base address 0x80030000 Entry 0x80041000
Cmdline :
CPU revision is: 00019064
Primary instruction cache 16kB, physically tagged, 4-way, linesize 16 bytes.
Primary data cache 16kB, 4-way, linesize 16 bytes.
Linux version 2.4.32 (iurgi@ropero) (gcc version 3.4.6 (OpenWrt-2.0)) #4 Thu Aug 17 21:48:03 UTC 2006
Determined physical RAM map:
memory: 01000000 @ 00000000 (usable)
On node 0 totalpages: 4096
zone(0): 4096 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2
Using 92.000 MHz high precision timer.
Calibrating delay loop... 183.50 BogoMIPS
Memory: 14188k/16384k available (1327k kernel code, 2196k reserved, 92k data, 68k init, 0k highmem)
Dentry cache hash table entries: 2048 (order: 2, 16384 bytes)
Inode cache hash table entries: 1024 (order: 1, 8192 bytes)
Mount cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
Page-cache hash table entries: 4096 (order: 2, 16384 bytes)
Checking for 'wait' instruction... available.
POSIX conformance testing by UNIFIX
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
Starting kswapd
devfs: v1.12c (20020818) Richard Gooch (rgooch@atnf.csiro.au)
devfs: boot_options: 0x1
JFFS2 version 2.1. (C) 2001 Red Hat, Inc., designed by Axis Communications AB.
squashfs: version 3.0 (2006/03/15) Phillip Lougher
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with no serial options enabled
ttyS00 at 0xb1100003 (irq = 37) is a 16550A
eth0: Dropping NETIF_F_SG since no checksum feature.
eth0: Atheros AR2313: XX:XX:XX:XX:XX, irq 4
MTD driver for SPI flash.
spiflash: Probing for Serial flash ...
spiflash: Found SPI serial Flash.
8388608: size
Creating 8 MTD partitions on "spiflash":
0x00000000-0x00030000 : "RedBoot"
0x00030000-0x00720000 : "rootfs"
eth0: Configuring MAC for full duplex
0x001c0000-0x00720000 : "rootfs1"
0x00720000-0x00730000 : "config"
0x00730000-0x007e0000 : "vmlinux.bin.l7"
0x007e0000-0x007ef000 : "FIS directory"
mtd: partition "FIS directory" doesn't end on an erase block -- force read-only
0x007ef000-0x007f0000 : "RedBoot config"
mtd: partition "RedBoot config" doesn't start on an erase block boundary -- force read-only
0x007f0000-0x00800000 : "board_config"
Initializing Cryptographic API
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 1024 bind 2048)
ip_conntrack version 2.1 (5953 buckets, 5953 max) - 328 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
NET4: Ethernet Bridge 008 for NET4.0
802.1Q VLAN Support v1.8 Ben Greear
All bugs added by David S. Miller
VFS: Mounted root (squashfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 68k freed
init started: BusyBox v1.1.3 (2006.08.17-19:56+0000) multi-call binary
Algorithmics/MIPS FPU Emulator v1.5
Please press Enter to activate this console. Registering mini_fo version $Id$
mini_fo: using base directory: /
mini_fo: using storage directory: /jffs
jffs2.bbc: SIZE compression mode activated.
wlan: 0.8.4.2 (0.9.0)
ath_hal: 0.9.17.1 (AR5212, AR5312, RF5112, RF2316, RF2317, TX_DESC_SWAP)
wlan: mac acl policy registered
ath_rate_sample: 1.2 (0.9.0)
ath_ahb: 0.9.4.5 (0.9.0)
ath_pci: switching rfkill capability off
wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
wifi0: H/W encryption support: WEP AES AES_CCM TKIP
wifi0: mac 11.0 phy 4.8 radio 7.0
wifi0: Use hw queue 1 for WME_AC_BE traffic
wifi0: Use hw queue 0 for WME_AC_BK traffic
wifi0: Use hw queue 2 for WME_AC_VI traffic
wifi0: Use hw queue 3 for WME_AC_VO traffic
wifi0: Use hw queue 8 for CAB traffic
wifi0: Use hw queue 9 for beacons
wifi0: Atheros 2315 WiSoC: mem=0xb0000000, irq=3
Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky
device eth0 entered promiscuous mode
BusyBox v1.1.3 (2006.08.17-19:56+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ _______ _______
| ____|| || _ |
| ____|| - || | | |
| | |_______||__| |__|
|___|
Fonera Firmware (Version 0.7.0 rev 2) -------------
*
* Based on OpenWrt - http://openwrt.org
* Powered by FON - http://www.fon.com
----------------------------------Registering mini_fo version $Id$
-----------------
root@(none):/mini_fo: using base directory: /
# ps
PID Uidmini_fo: using storage directory: /jffs
VmSize Stat Command
1 root 396 S init
2 root SW [keventd]
3 root SWN [ksoftirqd_CPU0]
4 root SW [kswapd]
5 root SW [bdflush]
6 root SW [kupdated]
8 root SW [mtdblockd]
16 root 388 S syslogd -C 16
17 root 420 S /bin/sh /etc/init.d/rcS
18 root 380 S logger -s -p 6 -t
20 root 488 S /bin/ash --login
21 root 428 S /bin/sh /etc/init.d/boot
22 root 360 S klogd
24 root 436 S /bin/sh /sbin/mount_root
48 root 328 R mount -t jffs2 /dev/mtdblock/2 /jffs
49 root 328 R mount -t jffs2 /dev/mtdblock/2 /jffs
54 root 368 R ps
root@(none):/#
Que, pinta bien ¿no?:)
Para quien quiera curiosear más, aqui teneis el sistema de ficheros completo de la Fonera
Vamos a cacharrear un poquito más:
Esto es lo que se ve al hacer un login vía SSH a la fonera:
root@radikal:~# ssh fonera
root@fonera's password:
BusyBox v1.1.3 (2006.09.11-19:54+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ _______ _______
| ____|| || _ |
| ____|| - || | | |
| | |_______||__| |__|
|___|
Fonera Firmware (Version 0.7.0 rev 4) -------------
*
* Based on OpenWrt - http://openwrt.org
* Powered by FON - http://www.fon.com
---------------------------------------------------
root@OpenWrt:~#
Así, en un vistazo rápido, vemos que su linux está basado en la distribución OpenWRT.
Visitando su web, veo que no hay nada acerca de la fonera ni de la placa base que ésta usa... así que de momento, mal para poder compilar un 'Hola Mundo' para la fonera.
Así a botepronto, se me ocurren unas cuantas aplicaciones para el juguetito:
- Un 'vigilador' de puertos... que pingee a tus servidores por varios puertos, y te avise de alguna forma cuándo uno de ellos se cuelgue o deje de responder.
- Aprovechar su puerto serie integrado de alguna forma, para poder encender/apagar chismes de forma remota, por ejemplo...
- Aprovechar su servidor HTML par acolocar alguna páginilla cuando tu servidor principal casque o esté en mantenimiento...
Bien, supongo que será cuestión de tiempo el poder disponer de un entorno de compilación cruzada para poder experimentar con el aparatito... ahora bien, me desagrada el hecho que que el aparatito venga con el SSH cerrado, y la ausencia (hasta hoy mismo, que acabo de ver un post en el blog del Martin en el que lo ofrece, ¡por fin! ) del código fuente, (obligatorio, para cumplir los requititos de la GPL).
Creo que deberían dejar de intentar ponerle puertas al campo, y, facilitar el desarrollo para la fonera, dado que es un aparatejo ampliamente distribuido, seguro que los hackers pueden sacarle mucho mas jugo al chisme.
Cusioseando el Linux de la fonera
Bien, así a vuelapluma, parece que la fonera usa una distibucion OpenWRT (de la que hasta ahora, no tenía ni idea de su existencia), jejeje.
Por lo visto, es una distibución linux en la que todo ha sido reducido a la mínima expresión...
Por ejemplo, los típicos comandos unix, ls, cp, mv, etc están implementados en base a un único ejecutable, que es el que se encarga de acometer el trabajo: el BusyBox
Curioseando en la web de dicho programa, veo que, en funcion de tus necesidades, a la hora de compilarlo, puedes añadirle o quitarle funcionalidades...
Entre otra cosas, el programilla es capaz de actuar hasta de cliente NFS... una lástima que en la fonera, hayan eliminado esta parte del programa, y asi, no nos es posible mapear una unidad NFS externa desde la propia fonera... una pena.
¿Os imaginais una fonera capaz de mapear uno de estos discos duros que se acceden por ethernet? ... podriais dejar bajando ficheros hacia ese disco duro, o si cupiera, se podria introducir un cliente de bittorrent... y dejar bajando pelis sin tener que dejar encendido el ordenador... jejej
Bien, supongo que si alguna de estas cosas se lleva a cabo, dudo que sea por los porgramadores de Fon... que andarán volcados en hacer todo esto en su nuevo cacharro que pretenden comercializar... el Fon Liberator
Más cosillas...
Aún no he podido conectarme a mi fonera por la red privada, pero veo que alguno ha estado investigando sobre el tema de convertirla en un AP normalito, en lugar de hacer que la res privada se comporte como router...
Aqui teneis un script (a ejecutar dentro de la fonera), para convertir su red privada en un 'bridge' es decir, para que al conectarte, pases a formar parte de la red ethernet a la que está conectada la fonera, no a una subred que la fonera crea.
Respecto a la interactuación entre la página de Fon y nuestra fonera:
La verdad es que tiene miga la cosa... resulta que la fonera tiene un script, que se ejecuta de dos maneras, cada vez qeu la encendemos/arrancamos y luego, una vez cada hora, mediante el cron.
Dicho script, lo que hace es conectarse con un servidor de fon, enviándole una serie de datos de nuestra fonera (hasta aqui todo bien, normal, vamos... es normal que la fonera se conecte a fon para decir que esta viva y conectada, asi puede mostrarse el mapa con el punto correspondiente a nuestra localización de nuestra fonera en verde), pero lo que no me parece tan normal es que, como respuesta a esa conexión, la fonera recibe un script que acto seguido pasa a ejecutar (con privilegios de root)...
Asi, es como funciona el cambio de claves de nuestra fonera desde la página de fon, es decir, la fonera, ya sea al arrancar o ya sea cada hora, se conecta a fon, le pasa unos datos, y recibe un script que pasa a ejecutar.
En el caso de haber cambiado nuestra clave, pues el script, ejecuta ciertos comandos y te cambia la clave.
En el caso de no haber cambiado nada, el script simplemete contiene una orden para borrarse a si mismo... y aqui no ha pasado nada.
Supongo que en base a este 'mecanismo', Fon puede actualizar automaticamente cualquier fichero de nuestra fonera... sic, ahor abien, por la misma regla de tres, tambien pueden instalar y ejecutar cualquier otra cosa, obteniendo vía libre hacia nuestra red... coño, esto es peligroso, ¿no creeis? :)
Aqui explico un poco el mecanismo, al detalle:
Via cron o en cada arranque, la fonera ejecuta este script SH:
root@radikal:~# ssh fonera
root@fonera's password:
BusyBox v1.1.3 (2006.09.11-19:54+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______ _______ _______
| ____|| || _ |
| ____|| - || | | |
| | |_______||__| |__|
|___|
Fonera Firmware (Version 0.7.0 rev 4) -------------
*
* Based on OpenWrt - http://openwrt.org
* Powered by FON - http://www.fon.com
---------------------------------------------------
root@OpenWrt:~# cd /bin/
root@OpenWrt:/bin# ls
ash dd grep ls pidof sh uname
busybox df gunzip mkdir ping sleep vi
cat dmesg gzip mktemp ping6 sync zcat
chgrp echo ipcalc more ps tar
chmod egrep kill mount pwd thinclient
chown false ln mv rm touch
cp fgrep lock netmsg rmdir true
date fonverify login netstat sed umount
root@OpenWrt:/bin# cat thinclient
#!/bin/sh
#
#version 1.0
#
THCLVER="1.0"
. /etc/functions.sh
. /tmp/network-config
# private key for fetching the info from the FON server
KEY=/etc/dropbear/key
USER=openwrt
SERVER=download.fon.com
PORT=1937
# gather information about this machine
# gather information about this machine
WLMAC=$( ifconfig $wifi_ifname|grep HWaddr|sed -e "s/^.*HWaddr //" |sed -e "s/ //g" )
WLMAC2=$( ifconfig $lan_ifname|grep HWaddr|sed -e "s/^.*HWaddr //" |sed -e "s/ //g" )
ETMAC=$( ifconfig $wan_ifname|grep HWaddr|sed -e "s/^.*HWaddr //" |sed -e "s/ //g" )
FONREV="$(cat /etc/fon_revision)"
FIRMWARE="$(cat /etc/fon_version)"
DEVICE="$(cat /etc/fon_device)"
exec_cron_mode () {
sleep "$((0x$(head -c2 /dev/urandom | hexdump | awk '$2 > 0 {print $2}') % 3600))"
echo "mode='cron' wlmac='$WLMAC' mac='$ETMAC' fonrev='$FONREV' firmware='$FIRMWARE'" | ssh -T ${PORT:+ -p $PORT}${KEY:+ -i $KEY} "${USER}@${SERVER}" > /tmp/.thinclient.sh
}
exec_start_mode () {
# gather information about this machine
CHILLVER="$(ipkg list_installed|grep chillispot| cut -d\ -f3)"
echo "mode='start' wlmac='$WLMAC' mac='$ETMAC' fonrev='$FONREV' firmware='$FIRMWARE' chillver='$CHILLVER' thclver='$THCLVER' device='$DEVICE'" | ssh -T ${PORT:+ -p $PORT}${KEY:+ -i $KEY} "${USER}@${SERVER}" > /tmp/.thinclient.sh
}
rm -f /tmp/.thinclient.sh
case "$1" in
cron)
exec_cron_mode
;;
start)
exec_start_mode
;;
*)
echo "Usage: `basename $0` {cron|start}"
exit
esac
. /tmp/.thinclient.sh
root@OpenWrt:/bin#
El kit de la cuestión radica en ésta linea:
echo "mode='start' wlmac='$WLMAC' mac='$ETMAC'
fonrev='$FONREV' firmware='$FIRMWARE' chillver='$CHILLVER'
thclver='$THCLVER' device='$DEVICE'"
| ssh -T ${PORT:+ -p $PORT}${KEY:+ -i $KEY} "${USER}@${SERVER}" >
/tmp/.thinclient.sh
En la cual, la fonera realiza una conexión con el ordenador download.fon.com mediante SSH, pasa unos cuántos datos, y el resultado de dicha conexión es grabado en un fichero llamado /tmp/.thinclient.sh que es ejecutado al término de éste mismo script.
Esto a mi me parece una pasada... a ver si me explico, tengo enchufado en mi red, un aparato, que ejecuta un linux totalmente funcional, que puede ser modificado a voluntad desde fon, para hacer lo que ellos estimen oportuno... desde snifar mi red, a obtener acceso total a la misma, pasando por... en fin.
Como la curiosidad me corroía, decidí ver que es lo que devuelve fon en cada ejecución de dicho script, así que modifiqué el script este /bin/thinclient de forma que hiciera una copia del fichero recibido, para poder estudiarlo.
es decir, añadí esta linea en el script original:
case "$1" in
cron)
exec_cron_mode
;;
start)
exec_start_mode
;;
*)
echo "Usage: `basename $0` {cron|start}"
exit
esac
cp /tmp/.thinclient.sh /tmp/copiathinclient
. /tmp/.thinclient.sh
De tal forma que siempre tendría el ultimo fichero recibido desde fon, para poder verlo :)
Esto es lo que se recibe normalmente, cada hora y cuando encendemos el aparato:
root@OpenWrt:~# cat /tmp/copiathinclient
rm -f /tmp/.thinclient.sh
exit
root@OpenWrt:~#
Es decir, en situación normal, lo único que hace es borrarse a si mismo.
Vamos a ver qué es lo que pasa si me da por cambiar, por ejemplo, la clave de la fonera desde la página de fon, para lo cual, cambio la clave y luego, reinicio la fonera.
Vuelvo a entrar por SSH y a ver que es lo que ha recibido esta vez:
root@OpenWrt:~# cd /tmp/
root@OpenWrt:~# ls -l
-rw-r--r-- 1 root root 1071 Jan 1 00:01 copiathinclient
-rw-r--r-- 1 root root 0 Jan 1 00:01 dhcp.leases
-rw-r--r-- 1 root root 141 Jan 1 00:01 hostapd.conf
drwxr-xr-x 2 root root 100 Jan 1 00:01 log
-rw-r--r-- 1 root root 68 Jan 1 00:01 network-config
-rw-r--r-- 1 root root 68 Jan 1 00:01 resolv.conf
drwxr-xr-x 2 root root 140 Jan 1 00:01 run
drwxr-xr-x 3 root root 60 Jan 1 00:01 spool
drwxr-xr-x 3 root root 60 Jan 1 00:01 usr
root@OpenWrt:~# cat copiathinclient
# begin # set root password
CPASS_ESC=$(echo '$1$$5lFJ9bVPPfRG1PZlf2X411')
rm -f /etc/passwd
echo "root:${CPASS_ESC}:0:0:root:/tmp:/bin/ash" > /etc/passwd
echo "nobody:*:65534:65534:nobody:/var:/bin/false" >> /etc/passwd
FIRMWARE=$( grep "(" /etc/banner )
FIRMWARE="${FIRMWARE%%) ---*}"
FIRMWARE="${FIRMWARE## * (Beta }"
if [ "$FIRMWARE" = "0.6.0" ];
then
echo '/cgi-bin/webif:root:$p$root' > /etc/httpd.conf
echo '/cgi-bin/webif:admin:$p$root' >> /etc/httpd.conf
killall -HUP httpd
fi
# end # set root password
# begin # set root password
CPASS_ESC=$(echo '$1$$x9KdSMW6T994JC2qznbiW1')
rm -f /etc/passwd
echo "root:${CPASS_ESC}:0:0:root:/tmp:/bin/ash" > /etc/passwd
echo "nobody:*:65534:65534:nobody:/var:/bin/false" >> /etc/passwd
FIRMWARE=$( grep "(" /etc/banner )
FIRMWARE="${FIRMWARE%%) ---*}"
FIRMWARE="${FIRMWARE## * (Beta }"
if [ "$FIRMWARE" = "0.6.0" ];
then
echo '/cgi-bin/webif:root:$p$root' > /etc/httpd.conf
echo '/cgi-bin/webif:admin:$p$root' >> /etc/httpd.conf
killall -HUP httpd
fi
# end # set root password
rm -f /tmp/.thinclient.sh
exit
root@OpenWrt:~#
Bien, premio... recibe todo un señor script, el cual recibe el hash de nuestra clave, la situa donde hay que situarla, etc, etc, y al final, se borra a sí mismo.
Hufff... ¿y debo yo confiar en fon para que no me meta nada por ahi?... hufff me parece que eso sería un gran acto de fé para un paranoico ateo como yo...
Resumen final:
El aparato tiene muy buena pinta, y, parece haber sido pensado en pro de la sencillez de uso, lo cual, limita mucho sus posibilidades para los que le buscamos 5 pies al gato...
La SSID privada me es inaccesible desde mi portátil... probaré con otros chismes, pero no me gusta que no sea seleccionable si queremos que esa red privada sea configurada en modo 'bridge' o en modo router (vista la sencillez para lograrlo, mediante el script que he puesto por ahi arriba).
Las opciones de personalización del portal público que ve cada uno que se conecte a tu SSID pública son ridículas. Se echa de menos un 'modo avanzado' o algo parecido, que te permita personalizarlo por completo.
Las señales SSID tanto pública como privada desaparecen y aparecen cuando les da la gana... creo que eso hay que afinarlo.
Es un asco que el SSH venga capado, a pesar de los miedos del señor Martin Varsavsky a que la gente los reflashee... el que quiera hacerlo lo hará de cualquier manera, y sino al tiempo. El que lo reflaseen o no, creo que depende del valor añadido que ellos ofrezcan, es decir, que el pertenecer a fon sea una buena idea, que sea algo que merezca la pena, y, si además se puede cacharrear y mejorar el aparatito, dándole nuevas 'features' pues mejor que mejor, ¿no?.
Estoy por montar una tiendita online para vender cables rs-232 para desprotegerla... oye, no te rias, igual es un buen negocio de 'emprendedor' ;)
No me gusta la puerta trasera, troyano o no se como llamarlo, del script thinclient... me parece muy arriesgado instalar la fonera en mi red en esas condiciones.
Yo ya lo he arreglado, haciendo que no ejecute el script que se baje.
Gano en seguridad y lo único que a simple vista parece que vaya a dejar de funcionar es la posibilidad de cambair de clave desde la página web de fon, y como esto, a mi modo de ver es elgo prescindible... pues asi se va a quedar...
Acerca del DNS ese de Interhost, aún no sé que pensar... pero tampoco me da buena espina, que quieres que te diga...
¡Seguiremos jugueteando! :)