Reading time: < 1 minute
A finals de maig vaig escriure un petit manual de com configurar un Mikrotik per fer de HotSpot amb diferents Linksys WRT54GL fent de bridge per ampliar la cobertura d’accés a internet. Doncs bé, el manual que vaig fer era en anglès i en Byteman l’ha traduït al català així doncs aquí teniu els l’enllaços:
La topologia de l’enginy és aquesta:
Reading time: 1 – 2 minutes
La setmana passada vaig posar en producció un hotel amb un HotSpot controlat per un Mikrotik RouterBoard 150 i amb diversos AP Linksys WRT54GL funcionant com a bridge. Bàsicament la idea és la d’aquest gràfic:
Doncs bé si voleu montar-ho al wiki ahir vaig fer aquest document per mirar d’ajudar als interessats: DIY HotSpot Wifi. Per cert, l’he fet en anglès perquè m’ho ha demanat gent que no enten el català. Si algú s’anima a fer la traducció que avisi que li dono accés al wiki i en un moment ho té arreglat. De totes formes ja veureu que he escrit ben poc i és molt entendor tot el que posa ja que el realment important és la configuració del Mikrotik.
Per altre banda, qualsevol dubte o consulta ja ho sabeu, podeu penjar comentari en aquest mateix article i faré el possible per ajudar-vos.
Reading time: < 1 minute
Ja he parlat algunes vegades sobre els aparells de Mikrotik. Doncs bé, avui m’ha fet il·lusió ensenyar-vos el professional que queda la routerboard 150 amb la caixa que venen la mateixa gent de Mikrotik.
El routerboard 150 amb la caixa desmontada tal com ve:
Aspecte final:
Reading time: < 1 minute
Resulta que el RouterBoard 150 de Mikrotik no té la mateixa configuració que la resta. Resulta que a aquest li hem de desactivar el control de fluxe per hardware i software:
Baud: 115200, Bits: 8, Parity: None, Stop: 1, Flux Control: none.
Reading time: < 1 minute
M’he fet un fart de buscar aquesta tonteria per poder accedir des de la consola serie amb el minicom així doncs, aquí va la configuració:
Baud: 115200, Bits: 8, Parity: None, Stop: 1, Flux Control: hardware.
Reading time: 2 – 3 minutes
Avui he descobert per casualitat a través del DD-WRT el servei d’AAA que ofereix l’empresa Sputnik a través d’internet, com a servei, venent el software i fins hi tot el
hardware si ens interessa. Realment el tema m’ha semblat molt bona idea. Ja que un WISP podria montar una infraestructura realment molt professional gràcies només a aquest software i a hardware tan econmòmic com el Linksys WRT54GL o d’altre una mica més professional com ara el de mikrotik.
A més ens permet unificar serveis de portal captiu de forma molt senzilla, ja que per exemple, a través de la última versió del firmware DD-WRT del WRT54GL i del client de Sputnik per routerOS de mikrotik. Podriem montar una solució completament integrada. Les avantatges són infinites val la pena donar un tomb per la web de l’empresa i fer volar la imaginació.
Resumint les solucions software d’Sputnik, tindriem això:
A continuació us recomano donar un cop d’ull al següent gràfic que us servirà per aclarir les idees, de com funciona tot plegat.
Realment de tan en tan, troves coses amb les que t’emportes grates sorpreses. Llàstima que no tinc mai prou temps per provar les coses a fons, perquè aquest s’ho val.
Reading time: < 1 minute
A l’article An overview of the IEEE 802.11 standard’s evolution (versió PDF) he trobat un quadre resum de les tecnologies 802.11a/b/g/n que m’ha sembla interessant tenir ben localitzat per això el penjo aquí.
Reading time: 2 – 2 minutes
Els artícles on explico com configurar EAP/TLS en català i en anglès tenen més de 8.000 visites el primer i més de 17.000 el segon. Doncs bé, degut a les preguntes d’algún d’aquests lectors de l’article acabo de fer un petit i ràpid cookbook de com afegir TTLS a la configuració TLS de l’article. De fet, si teniu clars els conceptes podeu montar-vos una autenticació EAP/TTLS amb PAP intern amb menys de 15min.
Bàsicament l’únic que afegim a la configuració del EAP/TLS és la capacitat d’afegir un nou sistema d’autenticació després d’establir el túnel segur entre el servidor radius i el client que es vol autenticar a la xarxa wifi. En aquest exemple per tal de simplificar les configuracions el protocol utilitzat per aquesta autenticació és el PAP. Amb aquest simple sistema he enmagatzemat el nom d’un usuari i una paraula de pas necessaris per autenticar el client després d’establir el túnel gràcies al seu certificat de client.
Obviament si no voleu usar PAP podeu modificar la configuració per usar CHAP, MsCHAP, o qualsevol altre sistema que volgueu. Si aquest article desperta tan interés com els altres ja l’aniré polint, però la veritat ara mateix no tinc ganes de posar-me a explicar tots els detalls de les configuracions que ja vaig explicar en el seu dia. Així doncs si ús cal ajuda la demaneu.
El cookbook el podeu trobar al wiki.
Reading time: 4 – 6 minutes
La setmana passada vaig agafar la furgo i en Lluis i camí cap a Manresa. On varem assistir a la SAX 2006, ara no recordo si és la segona o tercera edició. Aquesta cita anual és on ens reunim les comunitats lliures de comunicacions sense fils. Durant el matí hi varen haver algunes xerrades tècniques tot i que molt interessants diria que poc preparades, suposo que tots anem de cul. Tot i amb això el nivell tècnic en alguns temes era més que interessant. A veure si l’any que ve ara que ja sé de que va el tema em preparo alguna coseta i així hi aporto el meu granet d’arena.
Després del dinar, que va ser molt suau, tot s’ha de dir. Varem fer una taula rodona molt i molt interessant. On es varen parlar sobretot de temes referents a la inter-relació de totes aquestes comunitats entre elles. Per tal de sumar esforços, tan a nivell tècnic, com de documentació i organització. Jo diria que va ser la part que més s’hauria de descatar en aquestes jornades. Per tal de poder unificar encara més els esforços que com sempre acaben sent massa dispersos. Així doncs la meva proposta en aquest punt seria la de fer unes SAX dels cores de cada xarxa sense fils per tal de parlar de temes específics de col·laboracions entre nosaltres.
En aquest punt de la col·laboració entre xarxes sense fils es va acordar de publicar una especie de Planet RSS de les comunitats(*). Això consisteix en la idea de que cada web, weblog, portal o el que sigui de cada comunitat hauria de disposar de tres categories obligatories de contingut que es publicarien a través d’RSS. Això permetrà que es sindiqui des d’una web central, segurament www.guifi.net aquests continguts des de cada comunitat i que s’autopubliquin. El que es preten aconseguir amb aquesta iniciativa és:
Com que s’ha de predicar en l’exemple, podreu veure que en el meu bloc he creat una categoria que es diu Wireless dintre hi ha 3 subcategories, que són just les categories que varem acordar que cada comunitat ha de publicar via RSS:
Sota el meu punt de vista el nom de les 3 categories no és gaire important, sempre i quan sigui rellevant respecte el que contenen. A més s’ha de deixar ben clar aquests tres tipus de continguts perquè després es puguin recuperar des del lloc web central. En principi, el drupal que corre a www.guifi.net, el que no recordo és quin tipus d’RSS s’ha de publicar perquè el drupal el pugui importar automàticament a la categoria que toca. A l’espera de parlar aquest tema amb els administradors de guifi.net deixo pendent generar els meus 3 RSS.
Sobre el tema dels RSS als que no estigueu acostumants a treballar amb aquest tipus d’XML’s no us preocupeu ja que ús puc donar suport per tal de que us sigui més senzill fer-ho. A més la majoria d’aplicacions que s’usen avui en dia com a CMS ja suporten aquesta opció de serie. Així que només s’haurà de configurar convenienment el vostre aplicatiu web perquè publiqui els RSS.
Pels que durant la lectura d’aquest article us hagin sonat a japonés algunes de les sigles que he usat, us recomano que llegiu aquest article: ¿Què és RSS, sindicar, weblog, bitacora, etc?.
* Planet is a flexible feed aggregator. It downloads news feeds published by web sites and aggregates their content together into a single combined feed, latest news first.
Reading time: 6 – 9 minutes
Aquest agost vaig ‘postejar’ el nou mapa de la xarxa de Torrelavit. Doncs bé com haureu vist en el gràfic els APs tenen en molts casos múltiples interficies virtuals i rutes estàtiques. Ja que degut a la naturalesa de la nostre petita i modesta xarxa ciutadana no ens encaixa gaire el tema de l’enrutament dinàmic per OSPF i coses d’aquestes tan xules. Així doncs, vam trobar-nos en el dilema de com posar més d’una IP per cada interficie, cosa que la interficie web del router no permet. A més per afegir rutes estàtiques sense usar un adreçament dinàmic com RIP2 o OSPF la interficie gràfica tampoc ens ho permet.
Per tal de solucionar aquests problemes i de centralitzar el sistema de configuració dels APs en un punt. El que hem fet és montar un servidor TFTP al firewall. Amb accés només de les IPs dels APs. Un bon manual per configurar el atftp en gentoo: Gentoo Linux based Netboot HOWTO (cache)mireu-vos només la secció: The tftpd Daemon.
Una de les coses interessants que hem fet és usar només un fitxer de configuració per tots els APs de forma que aquest script sigui prou espavilat per poder configurar les particularitats diferents de cada AP. Després us explico com ho hem fet. Abans d’entrar en materia també us comento que tot el que explico només ho hem provat amb Alchemy. Imagino que amb altres firmwares també es deu poder fer però no ho hem provat.
La primera dificultat és com dir-li al Linksys que després d’arrencar s’ha de connectar al servidor TFTP s’ha de baixar el fitxer de configuració i l’ha d’executar després de baixar-lo. A més el que no voliem és que pas del TFTP pogués fallar i l’AP quedes desconfigurat a l’espera de que el tornessim a resetejar. O sigui, que el TFT s’ha de repetir fins que aconsegueixi connectar-se i agafar el fitxer. Tampoc cal una solució perfecte però si amb un mínim de control d’errors.
Com sabreu, si accedim per telnet al Linksys podem fer un nvram show per veure les variables que es guarden a la NVRAM (non-volatile RAM) on realment es guarda la configuració de l’AP. Doncs bé la variable que concretament ens interessa és la rc_startup podem consultar el seu valor: nvram get rc_startup. Doncs bé el que nosaltres volem és col·locar el següent codi dins la variable:
while sleep 30s; do if ping -c 1 172.25.0.2>/dev/null; then tftp -g -l /tmp/s.sh -r s.sh 172.25.0.2; sh /tmp/s.sh; break; fi; done
Com podeu veure el codi el que fa és que cada 30s intenta descarregar per TFTP el fitxer s.sh i el guarda a /tmp després l’executa. Això es repeteix fins que es pugui completar el cicle amb èxit. Ara només queda fixar aquest codi dins de la variable rc_startup i després guardar el codi a la NVRAM.
Ho podem fer així:
nvram set rc_startup="while sleep 30s;do if ping -c 1 172.25.0.2>/dev/null;then tftp -g -l /tmp/s.sh -r s.sh 172.25.0.2;sh /tmp/s.sh;break;fi;done" nvram commit
Ara ja ens podem centrar en l’script en qüestió. Per complicar la cosa, aquí només explicaré com creem els alias de les interficies i les rutes estàtiques no posaré cap opció de firewalling ni de filtratge de MACs. Com he comentat la gràcia de l’script és que és el mateix per tots els APs de la xarxa, així que en algún lloc s’han de guardar els paràmetres pròpis de cada AP. Doncs bé per fer això hem fet un petit ‘trick’. Es tracta d’usar la interficie de definició de rutes estàtiques que té la interficie web per entrar totes les direccions que ens interessen.
Aquesta interficie gràfica l’usen els protocols dinàmics RIP2 i OSPF per definir rutes estàtiques. Si marquem la opció d’enrutament dinàmic com a ‘disable’ llavors podem afegir rutes a la configuració del sistema qu no s’executaràn degut al que acabo de dir, però si que estan guardades en la configuració. Això és el que aprofiarem per després recollir la informació i segons la lògica següent les usarem en el nostre script:
La lògica és molt senzilla, penseu que quan volem definir l’alias d’una interficie de xarxa ecencialment només ens cal la IP de la mateixa i la màscara. Així doncs en la interficie de de rutes estàtiques només haurem de definir aquestes dues dades si volem que la informació serveixi per declarar l’alias.
Si pel contrari el que volem afegir a la interficie és una ruta estàtica aquesta haurà d’usar un gateway. O sigui, una direcció de xarxa, una màscara i un gateway això ho interpretarà l’script per definir una ruta estàtica.
Amb aquest petit ‘trick’ ja tenim una interficie que ens permet de forma molt senzilla en cada AP per guardar-hi la informació que el diferenciarà dels seus veins. Després el que fa el nostre script s.sh és mirar les variables d’NVRAM on es guarden i tractar aquesta informació segons la lògica que he comentat anteriorment. A continuació us enganxo un tros del contingut del s.sh on podeu veure com es fa això.
# Rutes i interficies virtuals
COMPTADOR=0
for AD in `nvram get static_route`;
do
IP=`echo $AD | cut -f 1 -d ":"`
MASK=`echo $AD | cut -f 2 -d ":"`
GW=`echo $AD | cut -f 3 -d ":"`
IF=`echo $AD | cut -f 4 -d ":"`
echo $IP $MASK $GW $IF
# es un enllas punt a punt
if [ $GW = "0.0.0.0" ];
then
# creem les ips virutals de la interficie lan/wlan
# trafic backbone
COMPTADOR=`dc $COMPTADOR 1 + p`
ifconfig br0:$COMPTADOR $IP netmask $MASK
else
# afegim rutes cap a trafic d'usuaris
route add -net $IP netmask $MASK gw $GW
fi
done
Encara que sembli mentida el que més va costar en aquest script és implementar el comptador, ja que la shell del Alchemy és molt reduida i no ens permet implementar comptadors de forma directa. Per fer això varem trobar un petit paquet que va instal·lat al sistema que es diu dc, és semblant al bc la famosa calculadora en format CLI que porten els linux, però la sintaxi és una mica diferent. Així que el tema ens va fer suar una bon estona.
La resta de l’script no té cap misteri com podeu comprovar. Obviament és molt millorable i es poden integrar moltes més funcions, però com a introducció a la idea crec que ja he donat prou dades sinó trobo que ho complicaria massa. Així que espero que us sigui útil i si en voleu més o teniu algún dubte ja sabeu on sóc.